To Constantine & Lockwood, Ltd., Home Page To Constantine & Lockwood, Ltd., Home Page
To Constantine & Lockwood, Ltd., Home Page Back to Previous Page          
forUse: The Electronic Newsletter of Usage-Centered Design
#15 | August 2001
  Subscribe! Prior IssueIndex by issue.Next Issue

|| Contents:
|| 1. Design: Interfaces in Small Increments. [TECHNIQUE]
|| 2. Implementation: Essential Objects. [TECHNIQUE]
|| 3. Analysis: Personas and User Roles. [MODELING]

= = = = =
* Over 100,000 downloads of a single paper: "Structure and Style in Use Cases!"
* Nearly 2000 leading professionals have subscribed to forUse.
Forward this issue to your colleagues. To join: <>.
Browse archives: <>.
= = = = =

1. Refactoring User Interfaces.
Refactoring is an important part of modern software development practice and one of the keys to the success of many of the emerging incremental development methods. Interest in this new generation of development methods continues to grow, particularly since they promise to reduce project overhead and speed delivery of better software and Web applications. We wrote about these "agile" or lightweight processes in the April Newsletter (see the archives at <>) and in a white paper on agile usage-centered design at <>.

Perhaps best known among the agile methods is XP or Extreme Programming. The XP approach bypasses up-front analysis and design to plunge ahead with description, programming, and testing in successive release cycles. Refactoring is one of the keys to making incremental construction succeed without a comprehensive advanced design. With each cycle, the structure of the software is reviewed again and reorganized as needed in response to emerging issues and in order to better support succeeding rounds of added features and functionality.

XP itself has no explicit user interface design process, and this is increasingly recognized as a limitation. We have been working closely with clients and colleagues on the problems of enhancing product usability in XP-style projects and integrating usage-centered design into XP and other agile methods. We have also been involved in an extended dialog with practitioners and advocates of Extreme Programming. (If you want to join in the discussion, check out the "extremeprogramming" group on Yahoo!)

On the surface of it, iteratively refactoring the user interface looks to be a good idea. The most commonly practiced alternative incremental approach is to keep cobbling on new features and components within an existing design. This practice leads to the clumsy and baroque user interfaces so typical of "highly evolved" but not redesigned software products.

A key question is whether iterative design in limited increments can work for user interfaces? Can user interface architecture be "refactored" into a different organization as the system evolves through successive design and implementation cycles? As we see it, there are two strong reasons why the user interface is one aspect of a system that must be designed in advance "of a piece." First, problematic early design choices and assumptions have a nasty tendency not to reveal their true nature until most of the user interface design is complete or at least sketched out in substantial detail. Second, user interfaces do not refactor easily or gracefully.

On the first point, the best choices for initially structuring the user interface become obvious only after much or all of the user interface design is complete. A sound, comprehensive task model helps as a guide, but tasks and the user interface features that support them must be associated with specific interaction contexts interconnected in well-planned ways. That's user interface architecture and requires considering the overall system in some detail. This dilemma is one of the reasons we favor abstract prototyping--because abstract prototypes let us quickly work through the complete design without committing to too much detail. After seeing the big picture, the best overall organization usually becomes clear.

Unfortunately, if you get the fundamentals of the user interface wrong on the first round, going back to change things on the next release can mean reorganizing large portions of the user interface. It is seldom sufficient merely to move a widget from here to there or rearrange the display of information in one view. After trying to introduce another batch of features, one development team discovered that information in several dialogs needed to be split in different ways across a couple of tabbed dialogs, which meant putting other information into tables, which meant adding new detail displays, which forced the moving of some operations to a separate screen, which... You get the picture. To make matters worse, refactoring the user interface is often tantamount to giving users a whole new system to understand and to learn. You can't do that on every release and expect to keep your user base or your job.

Avoiding these pitfalls through extensive up-front design not only goes against the philosophy of XP and other agile methods, but it poses practical problems as well by delaying the first release and leaving programmers twiddling their thumbs. A number of different compromises and combinations have been proposed and are being tried. We'll provide more reports as further feedback arrives, but one development already looks particularly promising. It concerns precisely what kinds of late-breaking news is most likely to cause a user interface design to crumble.

Looking back over a number of projects, we would have to conclude that not every aspect of the overall design is equally important to think through on the first pass. Some facets of the user interface design are much more likely than others to get the designer into trouble and are much more important to design carefully at the outset.

Of first importance is navigation architecture. The navigation architecture specifies how the overall user interface is organized into interaction contexts, collections, and groups, how these are presented to users, and how users navigate among these. At a minimum, the navigation architecture consists of a navigation map that identifies all the interaction contexts and how they are interconnected, but it is advantageous to have much more than that. For example, the navigation architecture might specify how parts of the user interface will be organized into tabbed notebooks accessed through a set of command buttons on a central dispatch dialog, with sections within notebook pages reached through shortcuts arrayed in a menu-like bar across the top of each notebook page. In a Web-based project, the navigation architecture might overlap with information architecture in mapping out the directory structure and describing how parts of the site or application will be connected, for example.

The second facet of overall design that we consider to be most crucial to detail in the beginning is what might be called the visual and interaction scheme. The visual and interaction scheme is a sort of abstract style guide. It briefly describes the basic recurrent visual elements that will be used throughout the user interface design as well as the common layouts or visual arrangements that apply to various interaction contexts. It might specify that all editable fields be highlighted in a distinct color and be editable in place by double clicking to open them. It might spell out how collections of controls that apply within limited or constrained context will be placed on slide-out tool panels that automatically open on mouseover and close after use. The scheme might outline how a modified tree-view in the left-most column will be used for primary navigation, with secondary navigation within views controlled by specially distinguished "view tools" across the top. In a Web application, it might specify the basic layout grid and the planned exceptions.

The navigation architecture and visual and interaction scheme are best based on a complete task model that includes all identified tasks, not just those to be tackled on the first or early iterations. Overall, the iterative process for usage-centered design proceeds like this:

1. Identify and rank all the user roles. Select the subset for initial support.
2. Identify and rank all the task cases. Select a subset for the first iteration.
3. Cluster all tasks into collections of closely related tasks and use this as a guide to a draft navigation map identifying all interaction contexts.
4. Based on the complete set of tasks, detail other aspects of a draft navigation architecture and specify a draft visual and interaction scheme.
5. Design the user interface to support the first selected subset of tasks.

The draft navigation architecture and visual and interaction scheme are not fixed but also evolve with the expanding and evolving software. On successive iterations, they are reexamined and revised if indicated, with completed portions of the user interface redesigned if needed before the design of the next part of the user interface begins.

2. Building It: Essential Use Cases for Programming
Just because you have a good user interface design doesn't mean you should throw away your task model. Our colleagues in New Zealand have been developing ways to carry the techniques of usage-centered design into object design and object-oriented programming. They use essential use cases in the form of simple index-card models to drive a comprehensive responsibility-driven design and development process. They have used the approach to good effect in their own consulting work with clients and have also been teaching it to students at Victoria University of Wellington. You'll find their elegant and eminently practicable process described in their paper linked at <>.

3. Personas.
Usage-centered design may be widely practiced but it is not the only model-driven approach to user interface design. Many students and practitioners have noted connections between usage-centered design and Alan Cooper's Goal-Directed(r) approach. (Yes, it's a trademark!) The closest ties are in how the salient characteristics of users are collected and modeled. We model the salient characteristics of users with abstractions in the form of user roles; Cooper uses the closely related concept of personas.

Personas are realistic and representative composites--Cooper has referred to them as stereotypes but the preferred term now seems to be archetypes--that include fictive details, such as concocted demographic and biographical information or even personality characteristics. Personas have names much like real people and may even be portrayed with a clipart photo to add to the apparent realism. Independent of the rest of Cooper's ideas, personas seem to have gained a following, particularly among Web designers.

Cooper's popular book, The Inmates Are Running the Asylum, is regrettably skimpy on details and practical guidance for devising and using personas. Fortunately, Kim Goodwin, director of design at Cooper Interaction Design, has just published a short paper ("Perfecting Your Personas" <>) that adds some depth and detail. Unfortunately, the article fails to mention user roles or to cite sources.

The intellectual ancestry of personas, like user roles, can be traced back to actors, the concept introduced by Ivar Jacobson and since enshrined in both UML and the Rational Unified Process. The parallels with the ideas and even the language of user roles are striking. For example, followers of usage-centered design will find a familiar ring in such nuggets as "personas represent behavior patterns, not job descriptions" and "[personas are] descriptions that include behavior patterns, goals, skills, attitudes, and environment." This is not to say that there are no differences between roles and personas.

Personas may actually have some distinct advantages. Over the course of a project personas can become almost like real people, which seems to encourage empathy with users, especially among technology-focused designers and developers. And personas can be great fun to construct and to talk about.

On the downside, the very realism of personas tends to encourage projection and overly concrete thinking. The descriptions are often complicated by superfluous detail that may contribute to verisimilitude but can also be distracting and misleading. For example, what does it matter if Melba--a persona developed for one application--lives in a suburb of Boston and received her first iMac from her son-in-law? In a fully-fleshed persona, how does the designer know what matters and what does not, what is important for user interface design and what is not? How does one validate a persona or determine how truly representative it is?

A user role, in contrast, does not look or sound like a real person and is not intended to; it's an abstraction--a relationship, not a person, title, job description or function. It is defined as a set of characteristic needs, interests, behaviors, and expectations. In its most compact form it is described by the three Cs of Context, Characteristics, and Criteria: (1) the overall responsibilities of the role and the larger context within which it is played; (2) characteristic patterns of interaction, behaviors, and attitudes within the role; and (3) special criteria or design objectives related to the effective support of the role. Checklists and templates have been developed to help designers cover all the issues and judge what is likely to be most relevant for user interface design. (See, for example, <>.)

In our experience, reinforced by that of numerous clients and the even more numerous practitioners we've trained, the disciplined abstraction of user roles make them the preferred model for driving usage-centered design. It is possible, however, to have the best of both worlds. Once a user role model covering the full range of user roles is available, it is possible to develop personas corresponding to selected roles, particularly the focal roles--those that are the most common and most important for the success of the design.

In fact, all three models--actors, roles, and personas--are useful and can have their place. For a simplified example, a business-to-business e-commerce application might be modeled with three actors: Customer, Fulfillment, and Credit Approval. The Customer might be differentiated into several roles: Regular Buying Role, Incidental Buying Role, and Casual Browsing Role. The latter might be described as: not necessarily in the industry and buying may not be sole or primary responsibility (CONTEXT), typically intermittent and unpredictable use, often merely for information regarding varied lines and products, driven by curiosity as much as need (CHARACTERISTICS); may need enticements to become customer, linkage to others from same account, access to retail sources and pricing (CRITERIA).

Were this role to be identified as a priority for support, we might create a persona to enrich and enliven it, something like: Brenda Browsefield is a 37-year-old administrative assistant to a manager at a small manufacturer. A New Englander who recently moved to the area, she styles herself as an outsider and independent thinker. A self-starter with a determined look permanently painted on her face, she often does research on her own initiative both to broaden her industry savvy and to be one step ahead of her boss. She has her own office and uses the Web a lot but spends relatively little time on any one site (except for Google and the portal of one industry e-zine). Ambitious and impatient, she's smart and likes to use industry jargon although she is not a geek.

Once you have them, portraits of your personas with capsule descriptions can be posted for ready reference. Your user role model will be more useful for setting or refining project scope and for developing an initial task model but your personas will literally become familiar faces to help inspire and focus the project team.

= = = =
forUse is published 9 times a year by Constantine & Lockwood, Ltd., trainers, consultants, and innovators in usage-centered design. On the Web at <>. Copyright 2001, Constantine & Lockwood, Ltd.

To unsubscribe, send email with the word "unsubscribe" (no quotes) in the subject and message to: <>

  Subscribe! Prior IssueIndex by issue.Next Issue