Nokia Developer - Interaction design and prototyping

Designing through iteration

With your initial concepts and scenarios in place, it’s time to further iterate your product’s overall user experience and interaction design. Design iteration ideally should be combined with prototyping, which will enable you to validate and test the design. Your test results will in turn help you determine which of the product’s features, interactions, or elements require further exploration.

Interaction design

Interaction design is the act of defining the touch points, behaviours, and interactions involved with a product or a service. It can include specification of:

Hardware controls and their impact on the user interface.
Software controls and affordances.
System logic, background processes, and states.
System feedback (such as progress bars, notifications, and alerts).
Manipulation models (such as touch, gestures, and indirect manipulation).
Animation, sound, and vibration.

But how do these diverse specifications combine, and what constitutes good interaction design?

Elements of good interaction design

while you used it? Maybe it presented you with incomprehensible jargon, made you type the same information over and over, or treated you like a child by making you reconfirm each of your actions — even ones you perform all the time.

Good interaction design is more than simply specifying how your users can accomplish tasks. Your design should embody characteristics that will enable your users to relax and feel in control of their actions:

Consistency: Inconsistent interactions increase users’ cognitive load, forcing them to think and remember more than necessary and to differentiate between expected behaviours and the exceptions they experience.
Trustworthiness: If your product disappoints users with inconsistent or confusing interactions, content, or behaviour, it risks losing their trust. Erosion of trust not only would affect whether they would continue to use the product, but it could prevent them from trying your other products or services.
Cleverness: A clever application doesn’t force users to configure things that it could configure itself, based on contextual data (such as location) or analysis of previous user actions. A clever application notes and learns from user behaviour — and then it provides users with ways to tweak settings when exceptions arise.
Responsiveness: Lack of responsiveness (especially combined with lack of feedback) creates doubt in users’ minds. ‘Is the application broken?’ ‘Have I done something wrong?’ ‘Will this happen again, at a time when I really need the app to work?’
Playfulness and pleasure: Play is an important part of our lives, at any age. Applications that are purely functional or usable may lose out on opportunities to engage users on a positive emotional level. Play and pleasure are even more important with mobile devices, which users may carry 24 hours a day. Paying attention to the design characteristics mentioned above will ensure

(Sources: Designing for Interaction: Creating Innovative Applications and Devices and The Inmates are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity)

‘We have long known that when people are anxious they tend to narrow their thought processes, concentrating upon aspects directly relevant to a problem. This is a useful strategy in escaping from danger, but not in thinking of imaginative new approaches to a problem. ... Results show that when people are relaxed and happy, their thought processes expand, becoming more creative, more imaginative.
— Emotional Design: Why We Love [or Hate] Everyday Things

The role of documentation in interaction design

Documentation is an important part of the interaction-design process. It helps communicate ideas, but more important, it specifies clearly how your application will work.

Your documentation should include the following categories and details:

Application architecture: The hierarchical structure of the application and the interconnections between application views.
Flows: The steps the user or the system must undertake to complete a given task.
States: Changes in behaviour, content, or interaction related to application states (for example, whether the user is logged in or out).
Views: The key views within the application and how these relate to data and state.
Data structures and bindings: The data represented on the screen, where this data comes from, and the rules governing data formats (for example, truncation, date formats, and sort order).
Components: The application building blocks, which typically include UI elements such as lists, grids, selection menus, modal windows, and input fields.
Content: Unique identifiers for text strings (for example, notifications, ToolTips, alerts, and component labels) and graphics (for example, UI icons and interface default colours).

Documentation will be useful, however, only if people read it and can easily understand it. To ensure that they do, use the most appropriate type of documentation for the information you’re trying to represent. Common types of documentation are described below.

Navigation maps (or architecture diagrams)

A navigation map represents the hierarchical structure of an application and the interconnections between views.

Figure: A portion of a navigation map.

Task-flow diagrams

A task-flow diagram represents the specific flow of a given task, including entry points, conditions, constraints, user or system decisions, and data or state dependencies. These flows are often elaborated through the creation of wireframes that correlate the logical flow with specific application views and with manipulation of controls, such as keystrokes and touchscreen actions.

Figure: A portion of a task-flow diagram for a mapping client

Wireframes

Wireframes are visual representations of the structural and functional elements of a product. Wireframes do not specify visual or industrial design; instead, they:

Reflect the functional and structural elements of each view.
Communicate key user flows.
Specify the direct user actions required to perform a task (for example, keystrokes or gestures).
Define content areas and sometimes display relevant placeholder content.
Communicate the overall design to promote stakeholder discussion at a phase when it’s still easy to make radical changes through iteration.
Provide input for subsequent process phases, such as user testing, visual design, and implementation.

Figure: A series of wireframe views.

Download the wireframing toolkit for Symbian. The toolkit is ideal for creating technical sketches or documenting application flows and structure.

Technical sketches or diagrams

These types of visuals are most useful to describe UI components. They can simply describe a component‘s structure or can contain far more detail, including dimensions, data bindings, and stylistic documentation (such as colours, unique ID for tiled background, and opacity values).

Figure: A design for a flexible-status-update component

Prototypes

For design of an interactive product or service, a prototype can serve as both an important form of documentation and a means of exploration.

Figure: A prototype by Nokia Research for the Family Story Play project

Why prototype before you code?

It’s common for a company to create only one prototype per project. With this lone prototype, the company attempts to accomplish a great deal — namely, to illustrate and validate the visual design, effects, interactions, and use of data. Such a prototype often is nice to look at and contains fancy effects, but it can suffer from critical flaws:

If the prototype is complex, it probably took a long time to make. During that time, the design may already have changed.
If the prototype took a long time to make, it will often take a long time to update. That means it may never be updated.
If it’s never updated, it will forever be out of date and may never be used again.

Prototypes such as these may look great, but they may prevent you from doing the most important thing — learning from the prototype and further iterating on the basis of the insights you gained.

Ways to prototype

Instead of one big prototype, consider creating several small ones to test or validate specific aspects of the design. The following table lists various design aspects and prototyping methods.

Design aspect	Suggested method
Interaction design	Interaction design can be prototyped in several ways. Paper prototypes are useful in the early stages or when you want to quickly determine if an interaction or flow is intuitive and usable. To clarify interactions further, you can create functional prototypes, which are physical or software models that include some level of actual functionality and, in the case of mobile development, often are installed on real devices.
User behaviour and service design	Because mobile applications are used in many contexts, it can be useful to test or model the accompanying user behaviour. By installing even a rudimentary prototype on a device and trying to use it in real situations, you can both uncover design oversights and suggest interesting new usage patterns.
Animation and effects	Prototyping animation can be tricky, because capabilities and performance often are directly linked to the platform you will be building on. An effect that looks amazing in a graphics program may not be possible on your chosen platform. Similarly, a transition that performs smoothly on an emulator may behave quite differently on a sluggish network or a device running multiple applications. Whenever possible, consult a developer who understands animation and effects capabilities before you begin, then work with that developer to design effects that best match your capabilities and constraints. If the platform has an animation-specific integrated development environment (IDE) or toolset, use it to create functional prototypes and test them on a device.
Data	Functional or even paper prototypes can be used to test how data behaves within the application. These prototypes are most useful to troubleshoot the design for real-world use and for internationalisation — especially in cases where the application contains unpredictable, user-generated content.

Don’t worry if your initial scenarios change as you prototype or expand the interaction design. Each time a scenario changes, it’s probably because you’ve made a worthwhile decision or solved an important problem. Remember, that all the stages outlined in this series of articles are flexible. If you think that you could benefit from additional research or additional conceptual design, go ahead and do it.

Reality check

With all the exciting technologies available to experiment with, chances are anyone can decide to build a product. It can also be tempting to add as many features as possible. After all, consumers want products that can do many things — don’t they?

A recent study found that users don’t always truly know what they want.

‘Although consumers find overloaded gadgets unmanageable, they also find them attractive. It turns out that when we look at a new product in a store we tend to think that the more features there are, the better. It’s only once we get the product home and try to use it that we realize the virtues of simplicity.’
Feature Presentation, The New Yorker

Links and resources

Design, prototyping, and documentation

Bring your design sketches to life with Flowella. Using PNG or JPG files, Flowella enables you to define application flow and export a prototype to an Adobe Flash Lite application or WRT widget, which can then be run on one of over seventy compatible Nokia devices. Find out more from the Flowella page and then download Flowella.

Family Story Play, developed by Nokia Research Center, is a system that supports grandparents’ reading books with their grandchildren over the internet. This article and the accompanying video explain the research behind the project and the development of a rich, interactive prototype deployed in user trials.

Interaction-design patterns and guidelines

The Design and User Experience Library area contains an in-depth outline of interaction design for mobile devices. The section discusses interaction-design tools, deliverables, and best practices.

Symbian design guidelines contain interaction patterns as well as common UI component descriptions to guide design and development.

The Nokia N9 UX Guidelines discusses the interaction patterns and UI components of MeeGo 1.2 Harmattan

Nokia’s Series 40 UI Style Guide provides a general overview of UI design principles, along with guidelines for the design of well-integrated, consistent, and usable Series 40 services and applications. For Web apps, see the Series 40 Web App UX Guidelines and the Series 40 Web App UI Graphics Toolkit.