Notes
Designing symptom logging for Apple Watch
My thinking behind short Watch interactions, nearby actions and deciding what should stay on the iPhone.
Give the wrist a smaller job
When I think about SymptomTap on Apple Watch, I start with the interaction I want to finish, not the iPhone screen I could shrink. The useful question is: what would make recording a symptom possible without reaching for the phone? That gives the Watch a clear role before I start deciding how much information to show.
My preference is for an interaction that is brief and easy to leave. Raise a wrist, find the relevant action, record something, move on. That is a design aim, not a measured promise about how fast every person will use the app. It helps me judge a screen by the task it supports rather than the number of things it contains.
Keep frequent actions close
A frequently used action loses some of its value if it sits behind a series of menus. For symptom logging, I want the path to the relevant symptom to be short and understandable. This is why the idea of quick logging matters more to me than presenting every available setting at the same time.
Close does not have to mean crowded. A screen full of equally important-looking controls can make a simple choice harder. I would rather decide what the screen is for and make that job clear. If everything is presented as the main action, I have not really done the work of choosing a priority.
Naming is part of that work. I want a label to say what an action does, without requiring someone to remember how the app is organized. Saving a little space is not a win if the resulting abbreviation makes the person pause. Short text needs to remain understandable, not just fit inside a button.
Do not move the whole phone onto the Watch
It is tempting to treat matching features as the goal of a companion app. I do not think that is the right default for SymptomTap. The iPhone offers more room to look at details and make choices. The Watch earns its place by letting a small action happen where it would otherwise be easy to put off.
I use that difference as a filter. Does an idea help finish a short interaction from the wrist, or does it turn that interaction into a longer session? If it is the second, I would rather consider the phone first. Leaving something off the Watch can be a deliberate product decision, not an unfinished copy of the iPhone app.
Keep the task understandable
Instant entries and timed episodes are different intentions. One records a moment; the other concerns a stretch of time. Wherever those choices are offered, the wording should make the difference clear. I do not want speed to depend on guessing which action will do what, especially when the whole point is to spend less attention on the interface.
I also try to consider the end of an interaction, not only the first tap. A short task should have a clear stopping point in the design. If I have to keep checking the interface to work out what to do next, it has taken more attention than the action itself should need.
A constraint I want to keep
These are my product decisions and questions, not conclusions from scientific UX research. I am describing the direction I use to decide what belongs in the app. The small screen is helpful in that sense: it makes me ask what is essential before I find another place to put an extra option.
The goal is not to spend more time with SymptomTap on the wrist. It is to make a useful record without turning logging into another task. The product page holds the current screenshots and availability. As the app develops, this is the constraint I want to keep: the phone can do more, while the Watch can ask less.