Defining the Experience Design Process

I. EXECUTIVE SUMMARY
How we design new technologies has a profound effect on what these new technologies ultimately can become. Each time we make decisions about the design process, the final product or research can dramatically change. The design process of technology is as much a part of our research at C22 as the actual technologies we enable. Our research here is concerned with how we can bring users into the design process. We see the role of users as everything from active partners, to inspectors or testers, to research participants that are observed and/or interviewed. We will be exploring these roles with users as a way to better understand and shape the technology design process for the future.

The idea is, no matter what you’re doing, there’s a user-centered way of doing it.

Users should be considered throughout the design process. Usability should not be an afterthought. Testing and fixing after an Internet appliance has been built is inefficient and unlikely to produce good results. The best approach to take is to incorporate a model of “pervasive usability” into your design and production process.

The benefits of planning usability into your project are:
• Increased end-user satisfaction
• Increased end-user productivity, success, and completion
• Reduced long-term development costs (costs incurred from fixing
• poorly designed products)
• Reduced training and support costs
• Return business to improve your competitiveness

II. OVERVIEW
Pervasive Usability
Below is a model of “pervasive usability” in Internet application design:

1. Requirements Analysis
• Determine the goals for the product from the perspective of the user and the business.
• Determine the user needs and target usability requirements.
• Evaluate existing versions of the product.
• Perform a competitive analysis.
• Perform user interviews and surveys.

2. Conceptual Design
• Sketch out an interaction design and architecture at an abstract level.
• Conduct a task analysis to find critical features.

3. Mockups / Prototypes
• Rapidly create visual representations (mockups) or interactive
• representations (prototypes) of the product.
• Evaluate usability through focus groups, user tests, and walkthroughs.

4. Production
• Create the final product.
• Evaluate functionality through testing, quality assurance, usability testing,
• and field-testing.

5. Launch and Maintenance
• Launch Internet appliance.
• Maintain and refine with user feedback.

• Evaluation occurs at every stage of the process. Similar types of evaluation can
• occur at different stages of the design process to keep in mind the goals of the
• project and the users’ needs. And if it comes down to a choice, reduce the scope
• of the project rather than the usability.

III. INFORMATION ARCHITECTURE
Create a Solid Foundation
Users can feel lost even in a relatively small information space that is not well organized. The problem becomes even greater when you consider the possibility that people can arrive at any given location from any other location within the system.

Information architecture focuses on designing effective navigation, organization, labeling, and search systems. It is an interdisciplinary field that draws upon research and practices in information and library science, computer science, graphic design, and psychology. The role of the information architect is crucial to the planning and conceptual design/redesign stages of web development, as good information architecture lays the foundation upon which a successful Internet appliance is built.

The steps to take in coming up with architecture include:

1. Finding out what the mission or purpose of the Internet appliance is—why will
people come to your product?

2. Determining the immediate and long-range goals of the product—are they different?

3. Pinpointing the intended audiences and conducting a requirements analysis
for each group.

4. Collecting content and doing inventory.

5. Determining the organizational structure of the Internet appliance, which can include:

• hierarchical (typically preferred)
• narrow and deep
• broad and shallow (typically preferred)
• sequential
• grid
• web

6. Creating an outline of the product, which can include:

• product maps: maps that reflect navigation and main content areas. They
• are usually constructed to look like flowcharts and show how users will
• navigate from one section to another.
• content maps: detailed maps that show what exists on each page and how
• content on the pages is related to each other.

7. Creating a visual blueprint of the product, which can include:

• page schematics: black and white line drawings or block diagrams to
• hand off to a visual designer. These may or may not reflect layout and
• are used mostly to inform the designer and the client exactly what
• information, links, content, promotional space, and navigation will be
• on every page of the product. Schematics help illustrate priority.

8. Defining the navigation system.

• global
• local

Navigation should:

• Be easy to learn.
• Be consistent throughout the Internet appliance.
• Provide feedback.
• Use the minimum number of clicks to arrive at the next destination.
• Use clear and intuitive labels.
• Support user tasks.
• Have each link be distinct from other links.
• Group navigation into logical units.
• Avoid making the user scroll to get to important navigation or submit buttons.
• Not disable the browser’s back button.

IV. INTERACTION DESIGN
In order for a user interface to be coherent, it needs to establish a set of rules and interaction paradigms that a user can learn and subsequently master. Obviously, the fewer things a user must learn, the sooner they’ll become comfortable with the device...this is as close as we get to quantifying "ease of use". Our primary concern with the OS is to integrate disparate application functions into a whole, removing redundancy, consolidating the feature set, and thereby minimizing the user’s path to mastery. Hopefully, this is exactly what will distinguish us from our competition.

If functionality is added after a UI has been optimized for a particular feature set, the new elements either need to be shoehorned into a design that was never expected to accommodate them or grafted onto said design as an afterthought. Neither option contributes to performance, consistency, or elegance. In a perfect world, all features need to be enveloped from the beginning.

Designing these new features on the fly also introduces the precarious distinction between the “best way” and the “practical way” to execute a particular requirement. Our job is to design and present the best solution, but if we don't have time or software infrastructure available to support such, we’re forced to use an inferior implementation. This is obviously frustrating for us idealists, and worse still has an impact on our professional credibility.

We also need to remember that user testing is a critical part of our design workflow. Adding features after a round of testing has been completed invalidates the conclusions gleaned, in much the same way that adding code to a build after it’s been validated by QA invalidates our assurances of stability.

Fortunately, the parallels between UI design and software development mean that the same things that we’ve gradually put in place to streamline our development model will also help polish our design process. Some possible additions:

1. Input!
Start with copious documentation of the product’s technical specifications (the features that the UI will encompass), marketing requirements (which determine the flavor and complexity of the design), and use case scenarios (critical for anticipating user behavior).

2. The earlier the UX team is involved in the process, the better.
Since designers depend upon a complete product view to make informed decisions, we’ve grown particularly good at asking questions and anticipating potential inconsistencies in a product. Often, an early product specification is more brainstorms than resolved feature set, and we can jettison problematic or incongruous elements before development resources are wasted.

3. Distinguish product design from project management.
Again, this concerns the distinction between the “best way” and the “practical way” to solve design problems. We somehow need to establish parallel tracks that initially relieve product design from the practical considerations of scheduling and resources. This frees the designers to converse freely with the client without the fear of inadvertently correlating “suggestions” with “commitments”.

Of course, we can’t live in a bubble forever, and ultimately the spec and schedule necessarily govern our design and production. But it’s critical to allow designer/client brainstorming in the planning phases.

4. Test, refine, ship.
Often the major task of interface design is user interface design, especially for systems with complex graphical user interfaces. User interface design includes: specification of user inputs (from the mouse, keyboard, and so forth), user outputs (sounds, windows and their contents, and so on), valid sequences of user inputs and outputs, and how system features are controlled and monitored by user inputs and outputs.

The boundary between analysis and interface design is fuzzy—requirements documents may specify interfaces in great detail, or may leave them relatively vague. To the extent that detailed interface specifications are given as part of the design problem, they need not be included in the design solution, although they must be understood thoroughly and so are important aspects of analysis. Frequently, however, interfaces must be specified in greater detail than they are in the requirements specification, so interface design may be important phase of design as well.

Architectural Design is the specification of the major components of a system, their responsibilities, properties, interfaces, and the relationships and interactions between them. In architectural design the overall structure of the system is chosen, but the internal details of major components are ignored. Issues in architectural design include:

• gross decomposition of the system into major components;
• allocation of functional responsibilities to components;
• component interfaces;
• component scaling and performance properties, resource consumption
• properties, reliability properties, and so forth;
• communication and interaction between components.

Aspects of a system’s architecture may be specified in its requirements, but this is less often the case than with interface design.

Architectural design adds important details ignored during interface design: system internals left unspecified during interface design are blocked out, but only to the level of major system components and their interactions. Design of the internals of the major components is ignored until the last phase of design.

Detailed design spans a wide range of “detail” because there is usually quite a lot to fill in between the architecture and the code. This area between the architecture and the code is where the bulk of software design occurs; most of the material in this book falls within the scope of detailed design.

This software design process is a top-down problem solving approach because it begins
at a high level of abstraction and works down to lower levels of abstraction at each phase.
Design Review—When the design team has finally completed its work, an extensive review of the entire design should occur. The designers have presumably already done their best, so they are unlikely to catch many mistakes—outside reviewers are needed to bring fresh perspectives to the work. Good candidates for a review team include the master event database designers or administrators, park guests, developers responsible for implementing, testing, or maintaining the reservation system, managers in charge of the project, and design consultants.

This example demonstrates that designing even a very simple software system is demanding: many decisions must be made at all levels of abstraction, requiring the ability to generate, evaluate, and choose between many design alternatives. The design must also be documented and reviewed to ensure quality

No design process always works. Usually some sort of design is produced as the result of an organized design process, but the result may be inadequate in several ways.

Probably the most frequent software design process failure is a design for a system that does not meet customer or user needs, or does not conform to design constraints. Most often this failure stems from poor analysis: customers and users are not consulted, or they are misunderstood, or their needs, desires, and constraints are not documented correctly and completely. The analysis methods, tools, and quality assurance techniques presented later, along with design process management, help prevent this sort of failure.

The second most frequent kind of design failure is inadequate design documentation. Many systems have no design documentation at all, and many more have only the sketchiest outlines of the design, or worse, documentation that does not describe the actual design of the system.

The final sort of design failure is a design that is less efficient, or robust, or understandable than it could be—in other words, a workable but poor design. No design is ever perfect, but many designs are awful, incurring unnecessary costs in wasted computing resources and expensive implementation, testing, and maintenance. Poor designs are produced through poor design practice, whose main cause is poor designer training and education. Poorly prepared designers are unaware of many design problem-solving techniques, so they have difficulty attacking design problems at all. Poorly prepared designers tend not to consider many design alternatives, largely because they don't know that they should. When design alternatives are studied, their range tends to be narrow because of ignorance of the full variety of standard architectures, patterns, algorithms, and data structures. Ignorance of design principles may lead to poor choices of design alternatives. Finally, ignorance of design notations makes it difficult or impossible to envision, study, and document designs.

The obvious way to prevent this sort of design failure is to improve software design education and training.

A way in which our approach to the software design process is an idealization is its exclusion of hardware/software design trade-off issues. In reality, system capacity and performance requirements are most cheaply (and sometimes only) satisfied by using more powerful hardware. This topic is beyond the scope of this book’s focus on software design, but must be borne in mind by novice designers who will encounter hardware/software trade-off issues in practice.

Having discussed the software process, we are in a position to lie out how the other elements of software design fit into it:

• Tasks in the design process are scheduled, assigned to designers, monitored,
• and measured as part of design process management.
• Design notations are used to document all steps of the design process.
• Software design patterns are used to generate (and document) design
• alternatives.
• Design principles are the criteria used to evaluate designs and design
• alternatives.
• Design heuristics guide the steps of the design process, aid in the correct
• use of notations, and help in the selection of design patterns.

V. USABILITY PROCESSES
Cognitive Walkthroughs
Cognitive walkthroughs are performed in the early stages of design using a prototype or a conceptual design document.

Based on a user’s goals, a group of evaluators steps through tasks, evaluating at each step how difficult it is for the user to identify and operate the interface element most relevant to their current sub-goal and how clearly the system provides feedback to that action. Cognitive walkthroughs take into consideration the user’s thought processes that contribute to decision making.

For example, finding the Usability First web product can be broken down to several levels of tasks. At a general level, it requires opening up a browser, remembering the URL and typing it in the text box at the top of your browser. Or, if you do not remember the URL, you must choose a search engine, think of a search term, view the results, scroll through the results, and then click on the link. Each of these actions can be further decomposed.

This approach is intended especially to help understand the usability of a system for first-time or infrequent users, that is, for users in an exploratory learning mode.

Focus Groups
Using focus groups to evaluate a system is a very efficient way to get user feedback and gauge initial reactions to a design. Focus groups are also good at discovering how the system being tested differs from the user’s current expectations. As we see it, focus groups provide two major benefits. First, they are less expensive than conducting interviews with the same number of people. Second, they rely on group interaction to trigger memories that may not come up during interviews.

Where task analysis often discovers the standard way people interact with information systems, focus groups can bring out exceptions to the rules. These exceptions are often very important interactions that users simply do not think of in one-on-one sessions.
Conducting only a single focus group can be misleading, however, as some groups are affected by “group-think” or may simply have irregular views. For this reason, at least two groups should be evaluated for any one project.

The focus group leader writes up the impressions and comments of the groups and recommends areas for improvement.

GOMS
GOMS is a family of techniques proposed by Card, Moran, and Newell (1983), for modeling and describing human task performance. GOMS is an acronym that stands for Goals, Operators, Methods, and Selection Rules, the components of which are used as the building blocks for a GOMS model. Goals represent the goals that a user is trying to accomplish, usually specified in a hierarchical manner. Operators are the set of atomic-level operations with which a user composes a solution to a goal. Methods represent sequences of operators, grouped together to accomplish a single goal. Selection Rules are used to decide which method to use for solving a goal when several are applicable.

Prototyping
Prototyping techniques involve developing representations of a target system for evaluation and testing purposes.

Prototyping is an essential element of an iterative design approach, where designs are created, evaluated, and refined with the results of testing at each cycle feeding into the design focus of the next cycle.

Prototypes can range from extremely simple sketches (low-fidelity prototypes) to full systems that contain nearly all the functionality of the final system (high-fidelity prototypes).

Here is a list of some prototyping terms and techniques:

• thumbnail sketch
• rough
• comp / mockup
• paper prototype
• video prototype
• wizard of oz prototype
• functional prototype
• rapid-prototyping
• RAD tool (rapid application development)

Task Analysis
Task analysis is a method that evaluates how people actually accomplish things with software. Through observation and interviews with users, an analyst determines a set of goals belonging to the target user. Then, a set of tasks that support these goals is determined. These are prioritized based on criteria such as the importance of the goal to the organization and the frequency of task performance.

The highest priority tasks are decomposed into their individual steps. The level of decomposition varies with the budget and type of system evaluated. The analyst then suggests ways to make the task more efficient or suggests new tasks that more effectively support the goals. It is important to recognize that the analysis is done from the perspective of the end-user—not from the point of view of managers or executives who do not necessarily use the system.

Usability Inspection
A usability inspection is a review of a system based on a set of guidelines. The review is conducted by a group of experts who are deeply familiar with the concepts of usability in design. The experts focus on a list of areas in design that have been shown to be troublesome for users.

Usability guidelines are usually derived from studies in human-computer interaction, ergonomics, graphic design, information design, and cognitive psychology. Some areas that get evaluated are the language used in the system, the amount of recall required of the user at each step in a process, and how the system provides feedback to the user. In particular, issues such as clarity, consistency, navigation, and error minimization are analyzed. Once the problems are discovered, the experts make recommendations for resolving these issues.

User Testing
User testing is the mainstay method when it comes to finding usability problems. Nothing is more convincing than watching person after people encounter difficulties with the same part of a software or information system. The difficult areas that repeat themselves between multiple test participants reveal areas that should be studied and changed by the developers. User testing can often uncover very specific areas needing improvement, where focus groups and task analysis often find more general areas needing improvement.
A trained observer conducts user testing often with the assistance of software developers. People who are representative of the target audience are asked to perform representative tasks with the software. The observer writes a user testing report listing the problems and offering recommendations based on their findings.

Contextual Inquiry
Contextual inquiry is basically a structured field interviewing method, based on a few core principles that differentiate this method from plain, journalistic interviewing. Contextual inquiry is more a discovery process than an evaluative process; more like learning than testing.

Contextual inquiry is based on three core principles: that understanding the context in which a product is used (the work being performed) is essential for elegant design, that the user is a partner in the design process, and that the usability design process, including assessment methods like contextual inquiry and usability testing, must have a focus.
For example, suppose you need to assess the usability of a wrench for automotive repair. Using contextual inquiry, you’d visit mechanics at auto repair shops and see how they work. You’d take in not only physical arrangements such as the location of the tool chests, or cramped conditions inside engine compartments, but also environmental concerns, such as the level of cleanliness of their hands, or the noise level in the shop, or the tight schedules imposed by their bosses. All of these would help define a context for their work—and thus a context for the usage of your product, the wrench.

You’d also listen to their gripes about your product; how it slips out of their hands if they’ve been working on greasy stuff, how it gnaws the corners off stubborn bolts. You’d ask them what would make their jobs easier; what design changes would help them. Involve them as a partner in the design process.

Of course, you’d conduct all this research centering on the one thing you’re analyzing: the wrench. This focus is important—it sets the goals for the visit (“We need to know how they store their wrenches”). Once you’re done with your product visit, you can assess from your notes whether you found out what you needed to

Interviews and Focus Groups
Interviews and focus groups let you query users about their experiences and preferences with your product. Both are formal, structured events where you directly interact with users, asking them to voice their opinions and experiences regarding your product.

Surveys
Surveys are ad hoc interviews with users, where a set list of questions is asked and the users’ responses recorded. Surveys differ from questionnaires in that they are interactive interviews, although not structured like contextual inquiries nor formally scheduled and organized like focus groups.

Heuristic Evaluation
Heuristic evaluation is a variation of usability inspection where usability specialists judge whether each element of a user interface follows established usability principles. This method is the part of the so-called “discount usability engineering” method.
Basically, heuristic evaluation is a fancy name for having a bunch of experts scrutinize the interface and evaluate each element of the interface against a list of commonly accepted principles—heuristics. Early lists of heuristics were quite long, resulting in tedious evaluation sessions and tired experts. These long lists rather defeated the purpose of this method, which was to save time and money over testing. Nielsen distilled his list of heuristics down to ten that have served him and others well in evaluating designs.

Ten Usability Heuristics
1. Match between system and the real world
The system should speak the users’ language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.

2. User control and freedom
Users often choose system functions by mistake and will need a clearly marked “emergency exit” to leave the unwanted state without having to go through an extended dialogue. Support undoes and redo.

3. Consistency and standards
Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.

4. Error prevention
Even better than good error messages is a careful design that prevents a problem from occurring in the first place.

5. Recognition rather than recall
Make objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.

6. Flexibility and efficiency of use
Accelerators—unseen by the novice user—may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.

7. Aesthetic and minimalist design
Dialogues should not contain information that is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.

8. Help users recognize, diagnose, and recover from errors
Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.

9. Help and documentation
Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user’s task, list concrete steps to be carried out, and not be too large.

10. Visibility of system status
The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.

Formal Usability Inspections
Formal Usability Inspection takes the software inspection methodology and adapts it to usability evaluation. Software inspections, more commonly known as code inspections, started at IBM as a way to formalize the discovery and recording of software problems (“defects” in quality jargon, “bugs” in the vernacular). The technique also provided quantitative measurements that could be tracked using statistical process control methods. Code inspections were also adapted to check and track documentation defects, and usability defects were a logical next step.

Formal usability inspections include aspects of other inspection methods too. Heuristics are used to help non-usability professionals find usability defects. Inspectors’ walkthrough tasks with the user’s goals and purpose in mind are similar to cognitive walkthroughs, although the emphasis is less on cognitive theory and more on encountering defects.

Pluralistic Walkthroughs
Pluralistic walkthroughs are meetings where users, developers, and usability professionals step through a task scenario, discussing and evaluating each element of interaction. Group walkthroughs have the advantage of providing a diverse range of skills and perspectives to bear on usability problems. The more people looking for problems, the higher the probability of finding problems with any inspection. Also, the interaction between the team during the walkthrough helps to resolve usability issues faster.

Feature Inspection
Feature inspections analyze only the feature set of a product, usually given end user scenarios for the end result to be obtained from the use of the product. For example, a common user scenario for the use of a word processor is to produce a letter. The features that would be used include entering text, formatting text, spell checking, saving the text to a file, and printing the letter. Each set of features used to produce the required output (a letter) is analyzed for its availability, understandability, and general usefulness.

Consistency Inspections
Consistency inspections ensure consistency across multiple products from the same development effort. For example, in a suite of office productivity applications, common functions should look and work the same whether the user is using the word processor, spreadsheet, presentation, or database program.

Consistency inspections begin with a usability professional analyzing the interfaces to all of the products and noting the various ways that each product implements a particular user interaction or function. An evaluation team then meets, and using the usability analysis as a basis, negotiates and decides on the one golden implementation for the usability attributes of each product.

Standards Inspections
Standards inspections ensure compliance with industry standards. In such inspections, a usability professional with extensive knowledge of the standard analyzes the elements of the product for their use of the industry standard.

For example, software products designed for the Windows environment should have common elements, such as the same functions on the File menu, a Help menu, etc. Or, products designed to be marketed in a particular country may have to conform to that country’s ergonomic standards. Many monitors or keyboards are restricted from some uses in certain European countries due to occupational safety and health standards in those countries.

Guideline Checklists
Guidelines and checklists help ensure that usability principles will be considered in a design. Usually, checklists are used in conjunction with a usability inspection method—the checklist gives the inspectors a basis by which to compare the product.

Thinking Aloud Protocol
Thinking Aloud protocol is a popular technique used during usability testing. During the course of a test, where the participant is performing a task as part of a user scenario, you ask the participant to vocalize his or her thoughts, feelings, and opinions while interacting with the product.

Co-Discovery Method
Co-discovery is a type of usability testing where two participants attempt to perform tasks together while being observed. The advantage of this method over the thinking aloud protocol is two-fold:

• in the workplace, most people have someone else available for help
• the interaction between the two participants can bring out more insights
• than a single participant vocalizing his or her thoughts

Question-asking Protocol
The question-asking protocol simply takes thinking aloud one step further in that instead of waiting for users to vocalize their thoughts, you prompt them by asking direct questions about the product. Their ability (or lack of) to answer your questions can help you see what parts of the product interface were obvious, and which were obtuse.

Performance Measurement
Some usability tests are targeted at determining hard, quantitative data. Most of the time this data is in the form of performance metrics—how long does it take to select a block of text with a mouse, touch-pad, or trackball? How does the placement of the backspace key influence the error rate?

download the WORD .DOC (164k)