Interaction Design Process Overview

Interaction design creates a focus on (some of) the users

Interaction design, as described by Alan Cooper in The Inmates are Running the Asylum, is a process for designing software by focusing on the most important users. Unlike traditional requirements gathering and solution design processes, interaction design focuses on the goals of a specific class of users, represented as a persona. Those goals are considered when defining scenarios that represent how the primary persona will use the software. The combination of goals and scenarios leads to design artifacts and a functional specification. We will explore these steps in more detail in this post.

Persona selection

There are typically many users for an application. A persona is an imaginary user, who is representative of a class of users with common goals and roles. This is completely different from the user proxy (or surrogate) who we know to avoid when gathering requirements in Wiegers-esque fashion. The first thing an interaction designer does is create a detailed persona for each class of user. Users who share goals and roles will be represented by a common persona. The interaction designer will often include a picture that represents the persona – our picture for this post might represent Steve Marshall, 20-year veteran enterprise software salesman.

Goals for a persona are defined in two distinct areas – practical goals and personal goals. Practical goals are goals related to the role of the individual (meet sales quota, close at least one multi-million dollar deal each quarter). Personal goals are the tricky ones. Tricky for programmers anyway, because they appear to be completely irrelevant. Personal goals include things like don’t feel stupid, play 18 holes of golf every week, travel less, etc. However irrelevant they may seem, they are key to gaining insight to how the particular persona would interact with the software – expectations, prejudgements, tolerance level for bugs or confusing interfaces.

Once all the persona are defined, one or two primary persona are identified as the key users of the application. All requirements and feature development are done specifically for the primary persona. Other user’s needs are ignored. Programmers (homo-logicus, as Cooper calls them) will argue that “someone” will want feature X, and work to include it in the scope. If the persona doesn’t need it, the software doesn’t get it. Capabilities that optimize on selling the software, versus using the software, are also ignored.
Selection of the primary persona is a prioritization exercise. The persona with the combination of most-valuable corporate goals and most-frequent use of the system is the logical choice. There can be two primary personas – for example, the main person who enters information into a system and the main person who consumes the information from the system. Including any secondary or tertiary personas will result in dillution of the power of the software. The theory is that trying to be all things to all people results in sucky, bloated software that is difficult for all of the users to master.

Scenario definition

Scenarios describe what our primary persona needs to accomplish while using the software. The interaction designer first identifies all of the things that the persona needs to accomplish with the software. Each of those activities represents a scenario. The scenarios are categorized as daily use, necessary use, and edge case scenarios.

• The edge cases are immediately discarded by the interaction designer – these happen so infrequently that the penalty of enabling them outweighs the benefit. The penalties are not just measured in implementation costs, but costs to the user of having to understand, ignore, or otherwise work around the added capabilities needed to support the edge cases.
• Necessary use scenarios are scenarios that must happen, but happen very infrequently. The requirements specification will include the functional capabilities needed to support these scenarios. Interaction design effort will not be spent on optimizing these scenarios, however. The theory is that since they are so infrequent, users will tolerate whatever implementation exists to make them happen.
• Daily use scenarios are the ones that the primary persona performs most often. Most users will have one or two daily-use scenarios. More than three is rare according to Cooper. This is where new users must get up to speed the fastest, benefits from good design are reaped the most, and the lion’s share of interaction design effort is applied.

Designing the solution
Cooper doesn’t talk much about creating the requirements to support the daily use scenarios – he proposes moving directly into design of the solution. This differs from the more traditional technique of writing functional requirements to support use cases. Cooper also breaks down design into two components – program design and interaction design. Program design is everything you don’t see. Interaction design is everything you do see.

The interactions are designed to support the scenarios (which are built in the context of the practical goals). The design decisions are made to best support the persona in the context of his personal goals. This is the point in the post where design professionals are cheering and programmers are jeering. Programmers want to know how in the world knowledge of a persona’s hypothetical desires (play more golf) influence individual decisions about how to render a user interface or design an interaction. Draftsmen want to know what’s so special about Picaso’s paintings – the perspective lines are all messed up. This is simply a left-brain versus right-brain issue.

Usability helps to bridge the chasm between these two camps, and it definitely plays a role. Programmers can appreciate that testing, statistics, analysis and experience can drive decisions about how people should use a computer to achieve a (practical) goal. But the usability specialists tend to fall into one of two camps – data-driven, or insight-driven. [Ed: I apologize, I saw this idea presented on one of the blogs I read, but can’t find it anywhere] This leaves the gap unfilled.
Cooper argues that designing the interaction should happen before any code is written. He uses a construction analogy to drive home his perspective – you can’t pour the concrete before you build the forms. Kent Beck, founder of the XP programming philosophy disagrees with the premise. Beck believes that the cost of changing software is low, and the imagery Cooper uses is hyperbole. We touch on, and link to that debate in this post.

Conclusion

There are some fantastic ideas in this approach. The prioritization of the most important users, and their associated daily use scenarios is very much like the requirements prioritization techniques we talk about here and here. The focus on minimizing features to maximize the usefulness of the software resonates as well. The lack of discussion of creating a software requirements specification or functional specification is concerning.

The jury is still out on this issue for us:

Should this process supplant or augment more traditional requirements gathering processes? Is it better or worse? What do you think?