The Smartwatch Method
A magic trick for UX design, using an artificial bottleneck to create a focused user interface architecture & master the complexity of information
Introduction
Call-to-action buttons are common interface elements. This pattern is the primary, attention-catching interaction element e.g. of many websites. Hence, they are designed to be visual magnets on the page, mostly by using bold, flat colors that create a high contrast with the rest of the page (fig. 1). This simple pattern takes into account that, especially when scanning websites, users have a very short attention span of ~10 seconds (Nielsen, 2011, Haile, 2014).
Simply by analyzing these 3 examples, it’s obvious that it’s not easy to settle on one main action during conception. The websites in fig. 1 are designed to deliver content (or sell products), for which some special rules apply (like optimization for commercial use). For regular interfaces, either on hardware products or in software apps, a certain complexity mostly lies in the information architecture: how shall the system be structured so that the users can easily find all relevant information and navigate through it with ease? It is not trivial to design such an interface with a proper interface architecture — it’s a process that takes several iterations. The same issue applies for the structuring of data when creating an information pattern, like a diagram, a dashboard, or an infographic.
The basic rule of making the interface easy to use sounds ordinary and has representations in different domains: the KISS principle (“keep it simple, stupid”), the quote “Don’t Make Me Think” (from the book of Krug, 2013), the rules of clarity and conciseness (industry standard, ISO 9211–210, 2019), the heuristic of “aesthetic and minimalist design” (Nielsen, 1994), the career advice of “one first priority” (Mell, 2013), the proverb “less is more” and so on. The hard part is to realize this rule in design projects. One approach to do so is the Smartwatch Method.
Complexity of interfaces and information: This discourse on complexity has to be short, though it could easily fill another article or even a book. Complexity is caused by two factors: the number of elements containing data and the chaos of its order. The famous rule of 7±2 single information chunks is exceeded very quickly in an interface. Both the number and chaos of possible interface elements increase easily in every research task at the beginning of the project. This is intensified if no clear system borders are set at the beginning. Furthermore, the selection or prioritization of elements is often influenced by several stakeholders, which results in many interface parts and thus a complex interface. To master this complexity, a process of sorting, simplification, and automatization must be done during the project, to turn “complicated” into “complex”, or even into “easy to use”. The Smartwatch Method supports this mastering of complexity, as it reduces the solution space and thereby limits the number of decisions available. In addition, the method reduces mental stress during development, as every solved wireframe or screen increases the completion tendency and pays on the need for closure.
Information and interface architecture in the product design process: Designing a product - whether it’s hardware, software, or the two in combination - is done in a structured process, starting with a problem and finishing with a solution. In the field of design this is often associated with the design thinking process or the user-centered design process, but also other approaches like waterfall, lean UX, or agile methods can be used as a blueprint. Complexity comes from user needs, which are translated into features, as well as the data used in the information architecture, which is translated into an interface architecture. The Smartwatch Method provides a way to master this complex architecture, especially in the planning and architecture phases (fig. 2). It helps to focus and highlight selected features and supports their grouping or automatization. In those crucial project stages, the core and key elements of the interface are carved out, and the whole product design can build upon these elements.
The Smartwatch Method
The magic trick of the Smartwatch Method is to take the interface design out of its original device, typically a monitor, a (mobile) browser, an embedded system or similar, and create a set of concept sketches, wireframes or screens for a smartwatch. This will reveal the structure of the interface with a main pattern, the prioritization of other elements, and a hint for touch gestures. It also demonstrates the necessity of minimized UX writing.
Limiting an interface concept to a smartwatch device generates a focused, naturally structured, well-sorted, clarified approach
The standard procedure for designing a product with an interface is to make a list of features, structure this list into an information architecture, divide that into logical units (pages or screens), draw wireframes for manifesting the selected features and discussing different implementations, and finally translate the wireframe into a screen design (with iterations and jumps forth and back, of course). This is done in sequential or linear approaches, as well as in agile projects. For most interfaces, the requirement list is long, the information architecture huge and the list of ideas from the client, stakeholders, or design team fills walls. This means that engineers and designers often start with a quite huge set of patterns as they head into the concept phase, by drawing sketches, creating digital wireframes, or prototyping the first screens.
Instructions for the Smartwatch Method (fig. 3):
1. Transfer the interface architecture, the feature list, and the collected ideas to a smartwatch device.
2. Create main wireframes, sketches, or screens for this smartwatch device. This is the main effect of the method and will naturally produce the core architecture for the interface.
3. Re-transfer the results to the actual device.
The Smartwatch Method creates an intentional bottleneck. A smartwatch, with its screen size of 2 inches and requirements for minimum font sizes, button sizes and touch target sizes (supported by very few hardware elements) results in a design space which is a fraction of that available on a laptop, tablet, monitor or any comparable embedded screen size. The need to squeeze those first ideas into a smartwatch framework forces people to prioritize one and only one interface element as the key one, to reduce information elements to a minimum (like removing all chartjunk or as in “ornament and crime”). Adding more smartwatch pages besides the first, which can be reached via different touch gestures, adds secondary and tertiary layers. This creates a nucleus for an interface and reveals the core architecture of the project. Finally, transferring the design back to the actual device provides room to add more elements or leave whitespace instead.
The Smartwatch Method will lead to three effects, one obvious main one and two reasonable side effects:
(1) The method will reveal the core architecture of the interface, with one main element, the prioritization of other elements, and key wireframes. The Smartwatch Method was created to achieve this objective. The need to squeeze any complex interface into the size of a smartwatch prevents the natural intent to consider more than one thing to be important. When designing software, a website or an embedded interface, the display space and calculation power available is sufficient for including many elements in the concepts. This often goes along with the unconscious feeling of forgetting important stuff, the aforementioned completion tendency. In contrast, with a smartwatch, the interface measures ~3cm x 4cm with a resolution of ~300px x 500px. Given these restraints, a concept must be limited to one pattern or a few interface elements. The restrictions that the smartwatch creates has an interesting way of clearing thoughts of incompleteness and gives confidence in doing one thing correctly.
(2) The method provides hints for touch gestures and interactions to navigate through the system. Creating wireframes, screens or concept sketches is quite static. By always assembling one page after another, the expertise of a designer must be quite high to anticipate animations, transitions, and dynamic elements. These often are only visible later, when a prototype is created based on the wireframes or screens. In contrast, the Smartwatch Method requires a dynamic interface from the start, as it forces to navigate between different screens. Some smartwatches have hardware controls, but most interactions can be done with touch gestures. And as the display is so small, there are more interactions by nature. Hence, when the design is transferred back to the actual device, one option is to arrange elements side by side on the bigger screen, and another option is to keep existing transitions in the bigger device. A third possibility is to make things dynamic in the actual device by using different patterns, like expanding elements, popups, accordions, callouts, or other metaphors to show the elements on demand.
(3) The method assists in the creation of a minimized, focused UX writing style. The small space, especially for text, on a smartwatch screen creates the need for short, meaningful text, for using icons instead of text, and for reducing text elements overall. This emphasizes better microcopy for UX writing. The button text “cancel and restart data input” might simply be too long — this can be fixed by dividing the button into two actions, by rethinking the need for this explanation and combining the sub-actions into one “restart”, or by redesigning for a short text and an icon button.
The Smartwatch Method is a magic trick in user-centered design to master interface and information complexity.
The method can be even more powerful if it’s executed in co-creation with the client. If the product owner and the client project team both experience the aha effect of this method, that understanding will support the rest of the project.
Example Cases using the Smartwatch Method
As the Smartwatch Method is so simple, the power of its application becomes visible with examples. In the following sections, several applications of the method are shown. The examples include an embedded device (Car Interface), web-based software (Vacation Tool), and a mobile application (Weather App), which highlights that the method is versatile in terms of domain and original device. All examples are neutralized regarding clients and brands.
Case: Car Interface
What was the question? In my work track I came across car interfaces in numerous projects. One basic concern from users that I was confronted with several times, is the request for a very minimalistic, reduced interface. A lot of manufacturers seem to move in the opposite direction, packing more functions into the interfaces with every new model. So the question was: how minimal can a car interface be? Yes, there are a lot of regulations about what must be shown, but in this project the approach was to start with minimal elements from a user perspective and add the essential things later.
What was done? Research into different existing interfaces was the starting point for this project. With this, a list of possible data and content was created for the cluster and the center display. Next, the transfer to the smartwatch device was done, accounting for a basic driver persona. The created wireframes (fig. 4) show the main information in the middle of the watch (speed as the primary element, followed by radio station, fuel/battery, and mileage) and two secondary information sources on the top and bottom of the display.
What was the outcome? The transfer back to the cluster and center displays shows a very minimalistic, clean wireframe with a lot of whitespace. Another effect here was the increase of situation-adaptive dynamics in the displayed elements. Quite often the driver only needs to see one particular piece of information at a time. The selection of this info either must be done automatically or through manual selection by the user. It is assumed that the advantage of a clean interface is worth the additional interaction which is needed to show more content and features. Whether this is satisfactory can only be clarified in user tests (which were not done in this project stage).
Case: Vacation Tool
What was the question? Every employer needs a process for their employees to take their vacation time. Today this should mostly be supported by a software tool. This tool should show the employee’s vacation time balance, provide details about submitted requests, and allow the employee to add such a request. The problem sounds simple, but some of the existing solutions show that you can do a lot of things wrong when developing the concept. So the objective here was to redesign such a tool with good usability.
What was done? As a current version of the software existed, the collection of data points, functions and other requirements was quite easy. Additional data points were considered as well. Starting with the data to display, wireframes for the smartwatch were created (fig. 5) with the personal vacation summary numbers, a calendar, and submitted requests. Wireframe 4 shows the app menu, and wireframe 5 shows the start of a new vacation request.
What was the outcome? When this design was returned to a mobile app, explanatory elements were added and several smartwatch wireframes were combined on one screen. The same thing was done for the transfer to a desktop wireframe: the bigger screen allows the display of more information in one screen (e.g. 12 months instead of just one). The insight of the smartwatch wireframe design is still there in the desktop version: the “11 days remaining vacation” is the primary element and is therefore highlighted.
Case: Weather App
What was the question? Every owner of a smartphone is familiar with some sort of weather app. It is a very nice example of usability, design and UX, as there are tons of apps available, which are used by specific audiences and are successful for very different reasons. In this case the task was to focus on different personas (three are shown here) and create user-centric solutions for them.
What was done? A collection of data points and functionalities shows the initial information architecture (fig. 6, left). Beside this, the three personas have different needs, condensed here into a short sentence (of course, these needs were described in more detail in the original).
(avatars designed by macrovector_official / Freepik, smartwatch template by Jessie Farris for IBM Cloud Experience Lab)
What was the outcome? The result from these concepts are persona-specific screen layout maps, showing how the information should be arranged. Those were translated into wireframes to give an impression of how the app should work. The Smartwatch Method reveals some interesting details: the first wireframe for the office worker is almost identical with the one for the grandmother, except the added location, which is needed for the latter to distinguish it from the next frames in the grandmother’s profile. The Smartwatch Method helps in this case to focus on the most important data for each persona. Transferring those wireframes back to a smartphone and tablet screen afterwards was easy because the information structure was clear.
Summary and Outlook
The Smartwatch Method is a tool for interface design. At a first glance it seems like additional work, but by generating the positive psychological effect of mastering complexity and taking the first few small steps toward the final interface, it pays out at the end. And the elements created for the smartwatch are used later in the actual device concepts, so it is not as much additional work as it may appear at first. The examples provided here show that the method is versatile and can help in a variety of domains. Of course, it has its limits when it comes to extremely small interfaces or multi-device arrangements. But it’s very useful for certain problems, so it could be part of every designer’s toolbox. As stated, the method can be used by a single person or a group, but the best effect is from integrating the client team into the execution, e.g. by performing a 5-hour design sprint. Further ideas for making use of the Smartwatch Method could be executing it with more data-focused cases, where the displayed data, not the interface, is object of the design.
The 5-Hour Design Sprint
One way to utilize the complexity reduction of the Smartwatch Method can be done with a design sprint. Although the most common approach uses a 5-day procedure, when time is limited, it is also possible to run a 5-hour design sprint. Therefore, the use case and the design space must be very small, wich is achievable by using a smartwatch app as example. It is recommended to use an example app from the domain of the group attending this exercise.
In the first hour of the sprint (understand), a user interview is done in the participant group. In the second hour (plan), how-might-we questions and the answers are collected. In the third hour (ideate), first ideas are sketched by each participant. In the fourth hour (prototype), a paper prototype is created by the group (fig. 7). In the fifth hour (test) the results are discussed by another group. With the Smartwatch Method, sketching and prototyping are done with smartwatch mockups - this keeps the required time to a minimum and maintains the spirit of the design sprint. Nonetheless, it is an implicit usage of the Smartwatch Method. It might not have the intense effects of a 5-day sprint, but can give people a very good impression of what UX is all about.
