I was wondering, how do you adapt your (or is there a specific) process when you are designing something for a new device or platform?

For example let's take the Apple Watch recently, many applications were published before anyone could even access the Watch.

In this case, how do you think for this device?

And how do you use User Centered Design, when no user has tested it ?

When you think from a 3rd party developper without access to the tests Apple did with their watch, how can you have feedbacks regarding the experience you are planning on giving to people ?

Thank you for your answers.

  • Welcome to UX.stackexchange. There is precious little user testing for a brand new product. In that case you're talking about edge cases.
    – Mayo
    Commented May 6, 2015 at 15:51
  • I'm sure lots of people tested lots of different iterations of the Apple Watch before the general public saw the finished design.
    – Matt Obee
    Commented May 6, 2015 at 15:54
  • Yes, I'm sure as well that they tested it, but let say as an app developper, how do deal with that since you don't have access to those feedbacks ?
    – Seylar
    Commented May 6, 2015 at 15:56

2 Answers 2


Experience Bias (I don't know the technical term)

Despite having 3000+ apps available at launch, many from reputable developers and big-name companies, one of the main criticisms of 3rd-party Watch apps has been that they're slow, clunky, and buggy. Aside from the difficulties of not having access to the actual hardware, developers sharing their Watch app mistakes have attributed some missteps to making too many assumptions based on prior experience with iOS development for phones & tablets. They failed to alter their workflow or to really take into account many significant differences.

So designing for a "new" product or category can be hampered by habits and assumptions about how you'd design for an existing one. Just because something has been "the right way to do things" up until now, do not assume this will remain true. [Insert apocryphal/requisite Henry Ford or Steve Jobs quote here.]

Rumsfeldian Problem Domain Analysis

Even with new products there are known knowns, known unknowns, etc. There are assumptions, restrictions, and initial use cases that provide some boundaries and criteria to aid in design and testing. A critical requirement seems to be to clearly understand and force yourself to work within those boundaries, at least at first.

With WatchKit, developers have known for months that they would only have access to a limited subset of functionality and hardware; what the screen sizes, resolution, basic interaction patterns and storage restrictions would be, etc. All of this knowledge could be used to inform design and testing decisions. Be deliberate about asking and keeping track of what you know, what you assume, what you're clueless about, and use this information to refine and restrict what you can design and test.

Fake it until they make it

Try to reproduce conditions as accurately as possible. Work at scale, test prototypes at scale and in realistic environments. Sure, you can't really test a Bluetooth delay with paper, but you can at least take the time to tape UI sticky notes to a Timex and wander around (the 1st Apple Watch was allegedly an iPhone + a velcro strap). Despite wide availability of DIY UI mockups even before Apple released official ones, many devs still probably relied on iOS habits and the software simulator, which is too large, too fast, and too powerful to get accurate usability feedback.

Keeping focus on realistic use cases instead of relying on available tools can help you to at least build and prioritize a list of things to test more fully once the actual hardware becomes available. That way at least you're not starting from scratch & already have a head start.


You test it, just as you would anything else.

You give it to employees who can test it at many levels. Some employees will be very familiar with the product already and can behave as expert users, while others will have little-to-no experience with the product and can provide user testing feedback as a novice user.

Hopefully employees who are field testing the devices are vigilant enough not to leave your unannounced phone at a bar.

You also use real people; real users. There's nothing special about it, really. Recruiting the user base works much a released product, in that a company will find individuals that match their target user base. They then bring them in and have them use the product and provide feedback.

This all works perfectly through the power of a really well written NDA. One that, as a test participant, if you violate it you'll wish you never heard of the company you're now sitting next to in court.

  • This is in the case you can access the device, but what if you can't ?
    – Seylar
    Commented May 6, 2015 at 16:25
  • 1
    How do you not have access to the device, or application, that you yourself (personal or corporate) are developing? Commented May 6, 2015 at 16:26
  • You have access to the App on the simulator, but you can't test it "in the field" because you don't have access to the watch yet. I'm not sure I'm clear here, does it make sense?
    – Seylar
    Commented May 6, 2015 at 16:29
  • AHH! I got it now, I think. You're a 3rd party app developer w/o access to the real hardware yet? Commented May 6, 2015 at 16:30
  • 1
    @plainclothes - it's certainly easier to wait, but not if you want to be the first to market and have a shot at a winning app. There are already 100s of similar Apple Watch apps competing to rise to the top & many are buggy due to lack of hardware access, but those are far better odds than being 1 in literally millions in the App Store.
    – mc01
    Commented May 6, 2015 at 19:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.