Transforming User-Centered Analysis into Concrete Design

Print-friendly Version

This workshop position paper describes a personal approach to UI design based on a model of how people interact with the real world around them. The approach can be scaled and utilized appropriately for each project based on complexity and project scheduling. The activities both iterate and pipeline, i.e., as soon as the most important design element of a step is completed, the next step is begun. Details of each step are completed later as confidence is gained with respect to the central design elements. This workshop paper was expanded to chapter length in User Interface Design: Bridging the Gap, 1997, CRC press.

At various points during the design process, the author uses several sets of guidelines for guidance and evaluation: human information processing, human interaction with the physical world, human social interaction, visual and audio presentation styles, and platform/toolkit specific styleguides. While clearly relevant to the workshop, they are too numerous, and perhaps implicit, to be included below.

A portion of an application builder is used as an example throughout this paper. A developer builds an application using reusable chunks of software as building blocks. The example focuses on how the user locates and selects the software chunks to be used.

Necessary Background Information

Some background information must be collected before the design activity can be started. (The workshop description indicates that the means of collecting this information is beyond the scope of workshop.)

Goals of the application

The purpose of the application, i.e., what it us to be used for, in terms of the environment it will be used in

Environmental Description

A description of the computing and real world systems in which the application will function. What function does the system perform? What are the objects in the system? How does the application fit into the system, i.e., what are the tasks, in terms of the systems, that it will be used for? What are the inputs and outputs to the application?

People

A description of the various rolls that people assume with respect to the application. What is the range of their education, experience, and physical abilities. What other activities are they involved in, especially those that they perform concurrently with the proposed application.

Real-life scenarios

How are the tasks, identified in the environmental description, performed now. What frequencies/volumes associated with the tasks? What obstacles and errors occur while performing the tasks? Describe any artifacts used and their use within a scenario.

Constraints

What parts of the environment can be changed and which cannot?

Environmental Model

The first design step is to extract an environmental model from the background information. The purpose is to identify the environmental objects the application will interact with and the "essential tasks" that describe what a user will perform in terms of these objects.

This extraction is most easily begun by generalizing the real-life scenarios, focusing on the system provided objects, inputs and outputs, and recasting user actions in functional terms, i.e. free of interaction specifics such as "click on...". The resulting "essential scenarios" should include the problems that can be encountered and the information and techniques used to recover from them. They should also include frequency and volume information.

The environmental model, i.e. the essential tasks and the objects involved, can be easily extracted from the essential scenarios. (A task is defined as an action involving one or more objects.)

Write up these scenarios and discuss them with the person(s) responsible for establishing the functional requirements. Focus on the objects and the functionality and flow of the tasks. Listen carefully for phrases that indicate underlying confusion.

These scenarios are usually too abstract for good discussions with users that were interviewed during the "background" stage above. Too avoid confusion, it is best to go back to users with a more concrete design early in the "Look and Feel" stage below.

A simple environmental model for our application builder example would include the tasks:

• Access the collection of software chunks
• Get a chunk
• Add chunk to the application being built

The only objects in this environmental model are `software chunk' and `collection of chunks.' A chunk is a piece of a software program; it may have other as yet unknown aspects that will be defined by the needs of the app builder.

The collection of chunks is expected to contain from several hundred to a few thousand different kinds of chunks.

Metaphor Selection and Mapping

The author has a strong bias toward creating user interfaces based on people's experience in the real world. Over time, people develop relatively efficient methods for dealing with commonly occurring situations. Ideally these typical solutions are widely used and easily recognized, reducing the need for training, but even in those situations where a metaphor is not widely known, it can still provide provide the structure of a time-tested solution.

First we need to generate a list of candidate metaphors by matching up elements of the environmental model with things (potential) users already know about. The real-life scenarios may contain the metaphor, i.e., the metaphor is the way things are already done. In the case of replacing an existing computer-based application with a new one, the metaphor may be the manual methods that were originally used. Other metaphors may be discovered by focusing on the objects, tasks, and scenarios of the environmental model and looking for parallels.

The `assembly' and `collection' elements of the example's environmental model suggest several metaphors including:

• Assembly of an app from chunks suggests that a chunk is a `part'. A needed part can be picked from a `drawer' of a `parts cabinet'.
• Semiconductor manufactures provide `data handbooks' that list the various kinds of `components' they make. For each component there is a `data sheet' that describes it purpose and use, often with an example circuit that demonstrates its actual application.
• Companies distribute catalogs that describe their products and provide a means to order/obtain the products.

Pick a couple of metaphors that seem the best fit and generate some trial generic scenarios by recasting the essential scenarios in the metaphors. The scenarios should still be functionally oriented, free of interaction specifics. If you don't like the resulting scenarios, pick a couple of the remaining scenarios and generate some more trial generic scenarios.

A metaphor never fits exactly right. Parts of the metaphor may not be needed. If the parts are central, users will likely be confused by their absence. On the other hand, the unneeded parts may indicate missing functionality in the proposed application. From the example, a scenario using the `parts cabinet' doesn't contain any mechanism for evaluating a parts suitability, so it seems a poor fit. A scenario using the `data handbook' is strong on evaluation but doesn't include anything about obtaining a component.

More typically, parts of the scenarios cannot be mapped onto the metaphor. Perhaps the metaphor can be extended in plausible ways with functionality that people wish actually existed in the real environment from which the metaphor is drawn. In either case, a metaphor should be rejected if the essential scenarios can't be reasonably mapped to it. From the example, a scenario based on the catalog metaphor works well, but the `descriptions' typically aren't very technical. That aspect can be built up by using descriptions more like those found in a `data handbook'.

Begin drawing some simple sketches to illustrate some of the trial scenarios from the most promising metaphor using metaphor-based visuals and the styles of presentation and representation common to other applications in the current computing system. The intention is to get a feel for how the metaphor might be presented, not to define the user interface.

Describe the selected metaphor to the developers. Illustrate with selected sketches; a couple of clean line drawings or short storyboards are best. The intent is to keep the developers informed rather than surprising them later, but take time to consider their comments and proposed revisions.

Detailed, Metaphor-specific User Model

A user model consists of a description of necessary concepts, objects, parts of objects, relationships between the objects, and the tasks and subtasks, all in terms of the metaphor. The model is made more concrete with a set of generic scenarios that describe a user's activity in functional terms. The user model is a functional description so it should not include any references to specific types of user interaction, e.g., "double-click."

The basic user model is created by recasting the system-level objects and essential scenarios and tasks of the environmental model in terms of the metaphor, an activity that was begun during metaphor selection. The parts of each object are enumerated and relationships between objects and other object parts need to be described.

A basic user model for the example would be:

Tasks

Open the component catalog
Get a component
Add the component to the application being built.

Objects

Component - the basic building block
Catalog - a collection of components
Data Sheet - a description of a component.

A task tree is built from the tasks generated by recasting the essential tasks in terms of the metaphor. Each task is iteratively refined as a set of subtasks, using the metaphor and essential scenarios as a guide, until each task corresponds to an atomic action in the metaphor. The tasks should include the obstacles that can arise and the tasks performed to resolve them. Note that a subtask may be used to perform many different tasks.

The portion of the example's task tree might look like this:

...
Get a component -from the basic user model

Locate candidate components

Turn to `section' of catalog that contains similar components (or)
Locate in Index, if name is known (or)

Turn to Index
Scan names - May be more than one found.

Find by description.

Indicate attribute -enumerate set of attributes
Enter value
Query - May find more than one.

Find a suitable component among the candidates -a plausible extension

Select a component
Show its data sheet
If none found, Locate more candidate components until no more.

...

Generating the complete task tree is tedious and sometimes difficult because the lower levels may involve significant design effort that is best done using visualization tools. Typically it is sufficient to focus on the primary tasks, iterating on secondary tasks as the design for the primary tasks solidifies.

At this point it is a good idea to review the task tree and reduce the marginal functionality either by folding it into other tasks or by eliminating it. In our example, the `Locate in Index' could be folded into `Find by description' if one of the supported attributes is a component's name. This is a good choice since it eliminates an object, the Index, while only adding a simple attribute, the name. And it likely that a user would rather find-by-name by typing the name than by looking through a long list.

The user model identifies the set of operations supported by each object. Each task defines an operation involving one or more objects. As the task tree is refined, the operation of each atomic task, and its description, should be added to the list of operations for the appropriate object. The user model objects are the nouns that appear in the task tree, the operations are the verbs. From the example:

As mentioned above, it is likely that some of the objects and operations required by the application may not occur in the metaphor. When possible, these should be cast as plausible extensions (described above) to the metaphor. These extensions must be clearly delineated and defined.

Look and Feel

The look and feel design portion is begun by selecting the high- frequency, high-level tasks and grouping them based on the objects involved and "closeness," i.e., the likelihood that they will be used one after another. From the example, `Get a component' is the high- frequency task.

Sketching is the next step begining with the primary window(s). In the example application there are two primary windows, the catalog and application- under-construction. Since one of the frequent tasks is to add suitable components from the catalog to the application, the windows should not overlap if possible. Since the application build window will be large (trust me), the catalog window should have `portrait' dimensions, tall and narrow.

Review the subtasks of the primary (high-frequency) task. Divide the window it into views that correspond to objects needed by the subtasks. From the example, the subtask `Locate candidate components' generates a collection of candidate components so we need a view for that collection. One way to generate that set is to `Turn to a section' so we need a view that shows the set of sections. Another way to generate the candidates is to `Find by description' so we need a view for the description. Their lower level subtasks don't suggest any new views.

The second subtask is `Find a suitable component from the candidates.' There is already a view for the candidates. The next level subtasks are `Select a candidate' (from the candidates view) and `Show the data sheet', another new view.

The primary task from our example appears to require four views: candidates, sections, description, and data sheet.

The views are arranged top-down and/or left-to-right based on the subtask flow of the primary tasks or based on the flow of data if that is a part of the metaphor. From the example, the sections and description views are the beginning views, the candidates next, and the data sheet last. Since the catalog window is tall and narrow, the views would be approximately arranged top-down.

The sketches suggest that arranging four views vertically will make them `short' so that they won't be able to display very much. After reviewing the task flow, we note that the process always begins with either the sections view or the description view so we map them into the same space and add a means to switch between them, typically a button though Windows '95 would use `tabbed subviews.'

The type of each view depends on the objects and/or data it contains. The environment and metaphor are reviewed for existing representations which might be appropriate. From the example, the data sheet shows text maybe graphics. The candidates view is a collection of components, i.e. objects, and objects are generally rendered either iconically (spacial) or by name (list). The typical pattern of a discription view is a form, a collection of type-in fields and a query button. The sections view is the most interesting. The catalog metaphor suggests a set of `tabs' but the number of sections is likely to be large if the catalog contains thousands of components. Typically large numbers of catagories, the sections, are organized hierarchically, so some sort of hierachical view seems appropriate for the sections.

Widgets/menu items are added to the views to enable the actions of atomic tasks. Widget selection and menu organization are based on the platform/toolkit guidelines.

Arrows are added to the sketch to indicate the sequence of user actions necessary to perform the task. Storyboards, a sequence of sketches, are drawn for tasks involving more than a few steps.

As additional tasks are added, secondary windows are created for parts and tool palettes and non-modal dialogs if necessary. Modal dialogs are avoided if at all possible. If the designer is good at sketching, he/she can show them to potential users and members of the development team for feed back, perhaps running paper and pencil user studies.

The author strongly prefers to create highly realistic, tightly scripted interactive prototypes of a primary task sequence using Director, though platform specific GUI builder might be used if the latter is available and can be made to "fake" content. The Director approach has often been faster to produce and more realistic.

It has been the author's experience that the dynamics of an interactive prototype stress the design details and thus promote confidence in the quality of the finished design. The prototypes are repeatedly demo'd, run through "cheap" user studies, and shown to the developers. Needed revisions are incorporated and shown/tested again. It has been repeated demonstrated that such prototypes are the best way to convey the feel of the finshed product to others.

The graphics used in the prototypes are first approximations as the author is not trained in graphical arts. A graphics designer is contracted to produced production quality graphics with the direction to capture the essence of the objects/actions they represent. Again, platform guidelines set the style.

Specifications

A narrated, platform-independent QuickTime movie is then made from the prototype and distributed to the developers as the basic visual/interaction specification. The author has also created, and revised as needed, the actual application user interface using a GUI builder. Graphics from the prototype are used by the developers as placeholders until the production graphics are provided by the graphics designer.

A Graphics and Interaction Specification provides the full details, i.e. the full menus, a picture of each window, a description of all mouse actions on each receptive element of each window, a list of dialogs including a picture and description of each non-standard dialog, and a set of target response times for each type of interaction.