Task type · App testing

Watch apps are used at arm's length for two seconds

Every design decision on a wearable is governed by a fact no simulator reproduces: the screen is looked at briefly, often while doing something else, sometimes in the rain.

Wearables are the only platform where the interaction budget is measured in seconds and the user is usually doing something else. Testing at a desk removes both constraints and therefore removes the test.

What to put in the public brief

Keep the app identity and build private.

What to put in the private instructions

  1. Ask them to use it while occupied

    Walking, carrying something, cooking. A wearable tested while sitting still has been tested as a very small phone.

  2. Ask whether they had to look twice

    The single most useful question. A glance that fails and needs a second look is the difference between a useful complication and a deleted app.

  3. Ask about outdoors and sunlight

    Contrast that passes indoors regularly fails at brightness, and it is the environment wearables are most used in.

  4. Ask about the notification, not just the app

    Most wearable interaction is a notification arriving. Whether it is readable without opening anything is usually the whole product.

Proof worth requiring

Ask for

Video of the wrist during use, the exact device and OS version, whether any glance needed repeating, and one line on outdoor legibility.

Do not ask for

Screenshots. A two-second glance is a temporal event and a still frame cannot represent whether it succeeded.

When this task type is the wrong tool

If the phone app is the product and the watch app is an accessory, test the phone app first — an onboarding test will find more for less.

If the build cannot be installed on retail hardware, nothing here can run. The constraint is the device, and it is not negotiable.

Test your watch app

Set the reward and the platform you need. Workers with the hardware reserve a spot; your build stays private until they do.

Post this task