Being User-Centered When
Implementing a UCD Process

by Whitney Quesenbery

With ‘usability’ gaining greater visibility, this is a good time to implement a user-centered design process. This article looks at ways that the approach and techniques of such a process can be applied to the task of introducing a new process.

In the life of a character actor there are four stages in a rise from obscurity to the end of a career: "Who is that guy?" "Get me that guy," "Get me someone like that guy," and finally, either "Who is that guy?" or ‘that guy’ becomes synonymous with the kinds of characters he played. Business ideas have a similar life-cycle, starting with a small group of evangelists, moving into the mainstream and finally either achieving true acceptance or fading once again into obscurity.

Usability is emerging from the first stage to the second. A few years ago, most people in product development had never heard of usability. They were focused on creating application development processes, understanding and serving the customer, quality, time-to-market and a host of other business imperatives. But in the last year or so, the word "usability" has begun sneaking into the business press. Executives have started to talk about usability as a critical success factor.

For those who are interested in usability – whether long-time advocates or newly introduced – this is a good time to introduce a user-centered design process. But introducing a new process, even on a small scale, can be a challenge. The goal of user-centered design focuses on the actual users of the product, but the users of a process are the members of the product development group itself. It is too easy to see them as the ‘enemy’ – the people who have failed to serve the needs of users. The problem is that such a combative attitude rarely succeeds in the long run. A more positive approach is to treat the implementation of a user-centered design process as a user-centered design problem, applying its approach and techniques.

A USER-CENTERED DESIGN PROCESS

A typical user-centered design process has three major phases of the work – analysis, design and evaluation - with iterations that cycle between each phase. Cognetics Corporation defined a framework for user-centered design called LUCID, for Logical User-Centered Interaction Design. This framework allows specific methodologies to be formulated to meet different product development or organizational needs.

The six stages in LUCID are:

• Envision
• Analyze
• Design
• Evaluate and Refine
• Implement
• Support

Each of these stages, fits together into a project plan that covers the complete life-cycle of a project. The stages may iterate, but both within an iteration and for the overall project, the deliverables from one stage are the input for the next. In addition, assumptions about users and usability requirements are continually tested during the entire life-cycle.

Envision

The work of envisioning the product to be created may be the single most important activity for the success of the product. It is often overlooked, or done incompletely, leaving gaps in the understanding of the scope, concept and function.

Ideally, this work is done with all of the stakeholders, including marketing, product development, design, support, training and product management. As each team begins to work, it is critical that there be a clearly enunciated, shared vision.

The envision activities end with the creation and approval of a Vision Statement which defines the product concept, target users, usability goals and early requirements as well as any technical or market constraints and key functionality.

Analyze

Analysis activities include all user and task analysis as well as coordination with business requirements analysis.

In some projects, the analysis activities are completed before any design is begun. However, in projects using a phased or iterative application development methodology, the analysis, design and evaluate activities are repeated for each phase. Typically, the first round of analysis covers high-level issues such as building an interaction model that matches the user’s mental model, while later rounds focus on detailed task analysis for specific functions.

Design

The design phase is one of the most iterative. It begins with a simple key screen prototype and continues until all critical design decisions are made.

Typically, this progression of prototypes builds from a main menu or home page and sample work pages to include the design outline or style guide for all screens to support the product functionality.

User feedback is collected through rapid, informal usability techniques on each iteration of the design. This ensures that the design matches users’ mental models and meets usability goals before complete detailed design is begun.

Evaluate and Refine

At key milestones, user evaluation is critical to ensure that the product will meet user needs. These evaluations give the design team an opportunity to test their assumptions and the emerging design.

It can be difficult to create a project plan that includes a final revision phase at the end of each activity, but leaving time for refining the design based on the results of evaluations is critical.

Implement

The implementation activities include the creation of detailed designs and accompanying specifications for the developers as well as monitoring the development process to solve any problems which are found.

The degree of formality during these activities depends on the structure of the team and, in part, the scope of the project. Without clear communications during implementation, the process can become chaotic, wasting time and energy.

Support

During the design process, users have supported the activities with their participation and input. Successful rollout of the product requires attention to how users will be supported. Planning the release, installation, awareness or training programs and initial support should be part of the project from the beginning.

In some cases, the designers may work with the technical support group to anticipate problems, or to plan ways of collecting usability information during support calls. Other ways of collecting information about the success of the rollout include user satisfaction surveys some time after release, follow-up site visits and focus groups.

All of these activities help the designers learn what techniques worked well, and which should be changed or improved in a future project.

IMPLEMENTING USABILITY IN YOUR PROCESS

New usability practitioners are often surprised to find that the rest of their development team does not share their enthusiasm. They can be met with outright rejection or more subtle resistance. One solution is to apply user-centered design to the process of introducing usability.

Looking at the entire product development and support group as the "users" of a new process provides some useful guidelines and insight. The LUCID framework can be applied to designing a process as well as designing a user interface.

Envision the End Result

Rather than simply diving into usability activities that sound interesting, take the time to create a shared vision of the result of implementing a new process. This includes a lot of "homework" but is an opportunity to explore the development process in some detail.

• Document the business benefits of usability and how it can support the company’s strategic objectives.
  Take the time to learn what those objectives are and think carefully about how user-centered design can help meet corporate goals. A company in the midst of a cost-cutting effort will be more responsive to plans for site visits if they are shown how a better understanding of users and their requirements can avoid costly rework late in the development cycle.
• Determine who must approve usability activities.
  In some companies, access to customers is carefully guarded by a marketing or field service department. In others, all requirements analysis is done by a central group. Depending on the structure of the organization, usability activities may all fall under a single department or may impact many groups, each of which must approve them.
• Explore how usability will change the development process.
  If there is a well-established application development process in place, any usability activities must fit into it. In some situations, there may be no formal methodology or new activities will have little impact on the existing process for developers. It is important to identify who will be affected by any changes in the process which are proposed.
• Identify the most important problems usability can solve.
  Sometimes the problems which are currently bedeviling a product group are exactly the ones which usability can help solve. In cases like this, it is easier to make a case for a process which offers a systematic solution.

In other cases, learning what problems need solutions might change ideas about the first activities to be introduced. In either case, the goals for the user-centered design process become part of the general goals of the company or product group.

Analyze Your Environment

Any user-centered design process requires user analysis and the process of implementing a process is no exception. Whether the change will be a momentous one, or a small refinement of a mature process, it will force people to change how they work. It is important to know who will be affected, and what their goals and requirements are.

• Identify the stakeholders in the current process.
  No matter how informal the current development process, there are stakeholders in the status quo. They may be the product managers, business analysts, individual developers or even another department such as the marketing, training or quality group. Find out who they are. Spend the time to learn how they will be affected by any new process.
• Observe and interview people who will be part of the new process.
  This may be done informally, or may be as formal as any site visits or subject matter expert interviews. Along with the basic fact finding, there are three questions which can be very helpful in deciding how to design and implement a user-centered process:
  • How do people on development teams interact and communicate? They may work in tight, cross-functional teams or primarily interact with their skills peers. Large projects may use formal (and long) documents to communicate between groups, while smaller rapid-iteration teams may have little written documentation, relying on information communicated in shared meetings.
  • What needs are not currently being met? Look for information which is not communicated well, or is missing entirely. In an environment which is not user-focused, this may be exactly the information which user analysis can provide.
  • What works well that can be leveraged? There may be informal procedures or techniques that can be borrowed, with the benefit of having already been ‘tested.’

Design (and Prototype) the Process

Rarely can a process or methodology be imported wholesale into a new environment. Take the time to design it to take advantage of the user analysis, making the connections explicit. Making decisions traceable to identified user requirements is just as powerful in a process design as in an interface design.

• Plan the process
  The plan must answer questions about both immediate and long term impact: what will the process look like when completely implemented; and how will it be introduced. In defining the usability activities which will be introduced first, the plan should include an assessment of how they will affect the current process. Can they, for example, be done in parallel with other work or will they add days to the schedule.
• What usability activities will help solve problems and meet goals.
  For each activity selected for initial implementation, the deliverables must be defined and there must be a clear statement of how they will help solve problems in the current process. If others will have to act on the information provided by an activity, the nature and scope of that response must be outlined.
• Select a few key activities to pilot.
  Don’t be too ambitious. Look for clearly defined problems with medium visibility and use them to test the effectiveness of user-centered design activities. The problems should be clearly defined so that success in solving them can be measured easily. Many products have intractable and difficult problems. Leave them for later, and take on something more manageable at first. If a problem has too little visibility in the company, no one may care if it is solved; too high visibility and the new process is forced into the spotlight too early.

Evaluate and Refine the Process

Few things are done perfectly on the first try. Plan for feedback and refinement as part of the normal course of action. That way, any problems or setbacks are not disasters that can derail the process, but part of an expected period of adjustment. Although much of the focus may be on the success of the activities themselves, use this evaluation period to make sure the process is working as you envisioned.

• Are usability activities meeting expectations?
  This is a good opportunity to be sure that the expectations of the rest of the product team, and management, are being met or exceeded. They may have seen usability as a ‘magic bullet’ which would solve all design problems with one site visit. Or, the activities may not have produced the results you expected. If this is the case, the plan may need to be changed or expectations adjusted.
• Are you successful in communicating results?
  Find out if the information is reaching the right people. Are user analysis materials being read? Are insights being shared? Communicating learning is as important as the learning itself.

Is new information about users having an impact on design?
The ultimate test of a user-centered design process is the effect it has on the product. Have there been any design changes – or even breakthroughs – as a result of this work? If so, think about how to expand these results. If not, why not?

Build on Successes

Moving from a pilot to full implementation can be difficult. The emphasis of the process shifts from the isolated tactical projects which needs only one sponsor to winning company-wide sponsorships. One of the biggest mistakes is to assume that one successful pilot can be automatically turned into a new approach. Even if the success of the initial project is obvious and universally acknowledged, it takes work to build it into a standard procedure.

• Expand successful activities to include more projects and more people.
  It is not enough to simply repeat the activities with the same group. Expand in two directions: train more people to use successfully piloted activities in their process; and pilot more activities, broadening the repertoire.
• Find ways to make usability a "way of life."
  This is the time to build the processes and procedures officially. If there is already an application development process or quality cycle in place, the political work of adding usability to that process begins. No matter how formal the process, be sure that usability activities are part of every project plan – from the beginning.
• Solicit feedback from users of the process.
  Continue evaluations with users looking for places for improvement. Spend the time to respond to their feedback, whether it is positive or negative. Ignoring any difficulties simply sweeps the problem out of sight, so take the time to work with anyone having problems to understand the issues, find solutions and create an ally.

Support Usability During the Rollout

Designers and technical communicators can be too modest. Accustomed to working quietly on their projects, they fail to share their successes. Be sure to:

• Evangelize shamelessly.
  Share techniques and success stories. Write articles in corporate publications. Present at conferences and publish in industry journals.
• Share information from usability deliverables.
  Be specific about what was learned and how it helped. Show how usability activities brought new insights, changed designs, sped up the development process. Good stories about users can become part of the corporate lore, building a customer-focus. Simple, quotable facts or anecdotes help people remember usability and its impact.
• Look for evidence of success.
  The real test of usability’s success is in improved customer satisfaction, increased sales, better performance numbers and other tangible metrics. Find out who tracks these elements, and work with them to find cases where usability played an important role.
• Find allies.
  Build relationships with other departments such as marketing, field service, training and technical support. They are the eyes and ears of the company, in touch with users on a regular basis. Work with them to find improvements (and help them get credit for finding any problems that usability can fix).

PLAN WISELY

Each company, each product development environment, each collaboration is subtly different from all the others, so each methodology also has its unique characteristics. LUCID is a framework rather than a methodology in acknowledgement of this fact. The framework provides an approach, milestones, goals and some activities, but the work of creating a methodology for each company must be a user-centered one, taking into account the specifics of each circumstance.

Choose the Right Problems To Work On

In choosing the first usability problems to work on, look in two areas: business impact and customer satisfaction. Business impact issues are those that cost the company time or money. They include technical support problems, inefficient functions, delayed time to market. Satisfaction issues to consider are things that users dislike enough to cause them to abandon the product, not recommend it, or return it.

Look for problems with:

• Medium visibility – Too much attention and any hiccups in the process are so visible they might derail the idea of usability entirely. Too little, and any successes may be ignored.
• High impact – Make sure that any success has an effect on the company, helping meet corporate goals or improve the bottom line. Sometimes solving an annoying collection of little problems can have as much impact as one big one.
• High probability of success - Don’t waste time on problems which are so intractable that there is little chance of solving them.

REFERENCES

• Cognetics Corporation, The LUCID Framework
• Quesenbery, W. "UPA 99 Workshop Report: Crossing the Chasm - Promoting Usability in the Software Development Community." UPA Common Ground, Vol 10 No 1, March 2000

This paper was published in the Proceedings of the 48th Annual Conference, Society for Technical Communication, 2001 as "Applying a UCD Process to Implementing a UCD Process"

The URL for this article is: http://www.wqusability.com/articles/ucd-on-ucd.html