Chapter 12

Interaction design

Interaction design specifies the functionality of a web app through the definition of structures, behaviours and responses to user-app interactions. To paraphrase Robert Reimann, president of the Interaction Design Association1, it is the combined design of time + space + choice + respons2.

Interaction design is underpinned by our previous research into user goals, priorities and expectations.

Websites versus web apps

If you have heard of the term information architecture (IA), a discipline closely related to interaction design, you may wonder why card sorting3 and other IA techniques aren’t discussed in this section. The reason is that IA mostly concerns the design and organisation of content, which is more appropriate to websites than web apps.

Website Web App
User goal Find information Complete task
User journey Haphazard Linear
User interface Content and menus Forms
Primary concern Information space Application flows
Design Technique Information architecture Interaction design

Comparison table derived from Jesse James Garrett’s Elements of User Experience diagram4.

Fundamentals

Bruce ‘Tog’ Tognazzini5, a principal at the Nielsen Norman Group6, is seen by many as the father of modern interaction design. He was employee number 66 at Apple where he founded the Human Interface Group and acted as Human Interface Evangelist. In 1998 Tog derived a list of sixteen principles for effective interaction design7, which I’ve summarised into eight fundamental considerations.

  1. Efficiency

    This appears in Tog’s original list as Fitts’s Law.

    In 1954, Paul Fitts developed a model8 that successfully predicted the time required to move a pointer to a target area – in our case, the user moving a mouse pointer to an element of the web app interface.

    The model has several mathematical formulations, but all we need to remember is that the time taken to move to a target area is proportional to its distance from the current pointer position and its width along the axis of motion. Put simply, it takes longer to hit something further away and it takes longer to move to something that is shorter in the direction that the pointer is travelling.

    img-12_1

    Diagram illustrating the principles of Fitts’s Law

    In the diagram above, the pointer is equidistant from Button A and Button B. Fitts’s Law tells us that Button A is the easiest target, because it is just as close to the pointer but also has the greatest width along the axis of motion. Buttons B and C are the same length along the axis of motion so, of these two, B, being closer, is the easier to hit, and further away C the more difficult.

    In practice, what this theory boils down to is: use big buttons for frequently used features. Note that there are diminishing returns: an increase in button width from 100 pixels to 200 pixels has a much greater impact than an increase from 400 to 500.

    Fitts’s Law presents some special cases on a computer display. If you move your cursor to any edge of the screen you’ll notice that the cursor automatically stops, rather than continuing into virtual space around your monitor. This hard limit effectively means that the width of the edges is infinite: once your mouse pointer hits an edge, you can continue to move your mouse in the same direction and it will remain touching whatever target is on the edge of the screen.

    img-12_2

    The edges and corners of a computer display are easy targets to hit

    The corners are even more special: they are effectively infinite in height and width and are consequently the easiest targets to hit on screen. This is one of the main reasons why you can assign commonly used features to the corners in Mac OS X.

    Unfortunately, we are unable to make use of these efficient target areas. Web apps run inside browsers that surround the app with borders and other software interface artifacts, and they may also be located anywhere on screen, at any size – they cannot feature infinite hard edges.

    img-12_3

    A web app runs inside a resizable browser window and cannot make use of the easy- to-hit screen edges

    Another special location is that which is zero distance away: the current pixel position. This can be exploited via a right-click contextual menu: wherever the mouse is, right-click to pop up a menu or interface that is positioned directly next to the cursor.

    Be careful with this technique: some devices, such as those with touchscreen input, do not offer right-click functionality, so ensure that anything accessed with a right-click can be made available easily somewhere else.

  2. Productivity

    This appears in Tog’s original list as two principles: efficiency of the user and latency reduction.

    People are expensive and computers are cheap, so it’s important to prioritise the productivity of the user over the machine. Furthermore, if many people from the same organisation use an app, for collaboration or content workflow, for example, the productivity of the whole group should be prioritised over the productivity of individuals.


    Techniques for improving user productivity include:

  3. Ownership

    This appears in Tog’s original list as autonomy.

    The user is the owner of the interface and should be given the control to work comfortably and confidently. There must be enough freedom that they don’t feel unreasonably restricted, but with clear boundaries that instil the confidence to explore. As confidence stems from knowledge, the app should provide clear, current status information within easy view.

  4. Convenience

    This appears in Tog’s original list as two principles: anticipation and defaults.

    Don’t make the user do work when it isn’t necessary. Automatically initialise tools when the user has an immediate need for them and bring relevant information to the current screen – don’t make them search for it.

    Provide default values that the user can overwrite as easily as if the input field was empty. Make the default values as accurate as possible: the user’s IP address can be used to approximate their location9, for instance.

  5. Consistency

    This appears in Tog’s original list as consistency.

    Users will have expectations about how parts of your app work, even on first use, based on its appearance and their prior software experience.

    Icons, cursors, buttons and other visual language should not be reinvented. For example, don’t use a compass symbol for a search where the user would expect a magnifying glass. Similarly, adopt common conventions for keyboard shortcuts and other inherent behaviours of the app: if something can be dragged, the cursor should change to a drag cursor when the mouse is over it. If something looks like a window that can be resized, allow the user to resize it.

    Conversely, use inconsistency to highlight differences in behaviours: don’t style and position items alike if they perform dissimilar actions.

  6. Safety

    This appears in Tog’s original list as four principles: explorable interfaces, track state, protect users’ work and visible navigation.

    Provide a safe and trusted environment for the user that minimises the opportunity for mistakes, with simple orientation devices and protection against human and machine errors.

    All actions should be reversible, whether backtracking from an incorrect menu selection or reverting a significant change to data. The user’s work and environment should be frequently and automatically saved, and easily recoverable to safeguard against connection failure, browser crash, or the user changing their computer, say, to continue working from home.

    The app should provide a discernible home environment or starting point, with stable minimal navigation. Content and functionality for user tasks should be brought into the home environment rather than the user being relocated to an unfamiliar interface.

    Give users an obvious but peripheral way out. It should be clear how to leave the app but it should not be a predominant option that can be mistakenly selected. Similarly, for important or unfamiliar tasks, remove non-essential navigation so that the user can unambiguously identify the way forward and back.

  7. Learnability

    This appears in Tog’s original list as learnability.

    Even the simplest web apps have to be learned: a new user will have no experience of how many options exist, how long actions take or what valid responses are.

    Facilitate the user’s progression through predictable behaviour, consistency, familiarity and feedback. Provide simple guided interfaces and additional information for complex tasks but be mindful of advanced and regular users; offer a choice of interface sophistication and intelligently present the most suitable options to the user.

  8. Comprehension

    This appears in Tog’s original list as readability and colour-blindness.

    The user must be able to easily understand the app interface. Text must be of a high enough contrast and a large enough size to be clearly legible. If your target users include older people or those likely to have vision disabilities, design the text accordingly. Be aware of colour-blindness, which affects about one in ten males and less than one per cent of females10. Do not use colour alone to convey information: it should be secondary to a descriptive icon or label.

User task flows

In order to get a better feel for how various interfaces slot together and what variations are required, you might want to add some structure behind your minimum viable product’s features before you dive into the visual part of interface design. I say might because I don’t believe it’s always useful and it depends on your situation and experience.

If you’re an experienced web professional working on a straightforward app in a small self-contained team, then it’s probably a better use of your time to progress directly to the wireframe and prototype stage.

If you are less experienced, working in a larger team or you need to communicate app decisions to a wider audience, then a small amount of design documentation about the proposed features will be valuable. It doesn’t take much time, isn’t complicated and may highlight hidden needs and interfaces that you can take into account sooner rather than later.

Many of the app features should be translatable into distinct user tasks, such as:

For each task, map out the discrete steps that the user encounters as they flow through the task. Don’t include specific details about the interface components or internal algorithms, just a simple description of each step. Most importantly, think about and include all exceptions to the correct flow: errors and alternative outcomes that could occur.

For the sake of practicality, trivial tasks may be documented in list format.

Task: Log in
Main Flow 1. Login interface
2. User dashboard
Exceptions 1a. Invalid login details. Return to [1]
1b. First-time user: tutorial option

Even in this simple example, you can begin to see how difficult it is to communicate decision points, branches and loops using a linear list.

Flow diagrams are almost as easy to create as a list. If you’re in a small autonomous team, you can use a whiteboard. Otherwise, desktop tools like Visio11 (Windows) and OmniGraffle12 (Mac) are straightforward for beginners, and web apps like Gliffy13 provide a remarkable amount of sophistication, more than enough for our needs.

Use whatever shape and style of diagram you find easiest to represent the flows, but if your diagrams are likely to be seen outside your team, you should adopt a widely recognised standard. Jesse James Garrett provides one such visual vocabulary, together with stencil files for many software packages, at http://www.jjg.net/ia/visvocab/

img-12_5

An example flow diagram that uses Jesse James Garrett’s visual vocabulary

Notes
(1a) If device details previously entered and stored, go (1b) otherwise return enter device details
(1b) If device details are valid return confirmation otherwise return enter device details

Form design

Forms are an essential element of most web apps, and deserve specific attention. As with other parts of the interface, good form design observes the fundamental principles of interaction design discussed earlier.

Remove unnecessary forms

Web forms are inherently cumbersome, no matter how well designed. If you can avoid a form, do so. Does the user really need to sign up before they use your service? If you need to personalise the app based on location, can you guess from their IP address and only require the form if your guess is inaccurate?

Remove unnecessary form fields

Likewise, remove form fields unless they are critical. Do you really need the user’s postal address for an online collaboration tool? Do you need them to specify their type of credit card when you can determine it from the card number? Be bold in the elimination of form fields.

Keep text concise but precise

The language should be as succinct as possible. The user should be able to easily scan and complete the form, and fully understand what is required of them for each field.

Set expectations

Let the user know upfront if they need to provide information that they might not have on hand, such as a passport number or account number, for a later part of the form. For multipage forms, display a progress bar that clearly discloses the structure and length of the process.

Optional field behaviour

If you really must have optional fields (are you sure they can’t be removed?) consider putting them after the main form submission, on the confirmation screen. Users may be more willing to complete optional fields once they are confident that their important details have been successfully submitted. If you do mix optional and required fields, and most fields are required, identify the optional fields rather than crowding the screen with required labels.

Remove distractions

Important forms (such as those with financial details) should be the focus of the page, with surrounding distractions removed.

Use field lengths as hints

If the format of a text field submission has a specific number of letters or digits, adjust the length of the field to provide a visible hint to the user. However, for all other fields that could have a range of response lengths, maintain a consistent field size.

img-12_6

Part of the Facebook Create a Group form. What does Office mean? Address? Telephone?

Be flexible

If users are likely to enter an answer in a variety of formats (telephone numbers, credit card numbers, and so on) be flexible about what you accept. The app should be responsible for converting the entered value into the proper format, not the user.

Validate problematic fields on the client-side

Where answers are more likely to have errors, such as choosing a unique username or password confirmation, validate the field inline, with immediate feedback.

img-12_7

eBay uses field length hints for postcode and telephone number, and keeps all other field lengths consistent

Label positions

Top-aligned labels have several benefits. If the form fields are aligned vertically on a grid, top-aligned labels are easiest to scan14. They tend to have greater breathing space to the right of the label, which eases translation into potentially longer foreign languages. They also make it simpler to horizontally arrange form fields, which can be useful if the user is expected to input several closely related answers.

img-12_8

Twitter validates important fields inline

Left-aligned labels may be slower to read, but that’s not always a bad thing. If your form asks unfamiliar questions, it can help to slow down the user and aid comprehension.

Inline labels, where the description of the field appears inside the text box and disappears as the user clicks into it, can be tricky. They are useful for very small, confined spaces, but should not be used for any more than one or two fields: any more, and it’s easy for the user to lose the context of the information they’ve entered.

The default inline label values must be styled so that they can be easily distinguished from the user’s answers, and the code that removes the default text must load quickly and robustly15.

img-12_9

Expedia arranges form fields with top-aligned labels

Don’t prioritise secondary actions

Forms normally have a single primary action (Submit, Next or Register) accompanied by one or more secondary actions (Cancel, Previous or Clear).

Secondary actions should always be more difficult to select than the primary action. They should also be less prominent in colour, smaller and offset from the more important fields –remember Fitts’s Law.

Links often make good alternatives to buttons for secondary actions16.

img-12_10

Hulu uses inline label in a confined space

Confirm success

When the user submits a form, never leave them at a dead end and always clearly confirm the success of their action.

Many web apps redirect the user to the app home page after a successful form submission to eliminate the need for an otherwise redundant confirmation page. The success of their action is momentarily reported on the home page, either as a notification bar along the top of the interface or as a highlighted area of the screen that contains the relevant updated data17.

In these situations, when the user is redirected to a familiar screen, it can be useful to draw attention to the notification through subtle animation, such as scrolling down bars or fading out highlights.

img-12_11

Wufoo uses a less prominent link for the Cancel secondary action

Summary

An analytical approach to interface design improves the user experience.

Web App Success book coverAlso available to buy in a beautiful limited edition paperback and eBook.

This work is licensed under a Creative Commons Attribution 4.0 International License.