A couple of months ago, I was part of a panel discussion on “Real-World User-Centered Design.” The topic was the outgrowth of questions from a more introductory forum on user-centered design (UCD) principles. After the introductory forum there were still many burning questions—specifically, how do you adopt and adapt UCD principles to real-world organizational constraints? It’s a question we sometimes encounter in our consulting work. To get the ball rolling, we recommend three steps…
- Understand the basic principles in user-centered design
- Assess your organization’s starting point
- Use your starting point to strategize next steps
Step 1: Understand the basic principles in user-centered design
At Blink our user-centered design process includes three main elements:
- Conducting user research to drive creation of behavioral profiles and scenarios
- Using behavioral profiles and scenarios to guide our design work
- Prototyping and designing iteratively (testing early and often)
It’s important to understand the “pure” process before thinking about how it might best fit into your organization. Taking seminars and classes is one of the best ways to learn about user-centered design because you can often get a broader perspective from group discussion. There is a wide range in how organizations implement and practice user-centered design. There is no one-size-fits-all solution.
Step 2: Assess your organization’s starting point
To help organizations think about their starting point, I created a model with two dimensions, with the first being how well your product is currently meeting user needs. Is your service center swamped with complaints? Or are you having trouble keeping up with all the complimentary emails and phone calls? The state of your current product governs the urgency to act. A company with a clearly failing product needs to respond differently than one that is basically serviceable, but could be improved.
The second dimension is to what extent you have implemented user-centered design processes. This is at least a partial indicator of how ready your organization may be culturally to move forward in its adoption of UCD principles.
Step 3: Use your starting point to strategize next steps
In our work with clients, we encounter various organizational starting points. These are discussed in the following sections, along with some suggested next steps to move up the UCD curve.
Starting point: Product chaos
Occasionally in a client engagement, we step into product chaos. In one memorable case, the client had their product in a trial with a major customer; the trial was in jeopardy because people were not able to perform the system’s most basic tasks.
There was high urgency to act, but we felt it was critical to begin with baseline usability testing for two reasons: First, it was necessary to observe why problems were occurring first-hand. Problems reports were mostly second- and third-hand and everyone seemed to have their own ideas on the “silver bullet” that would solve the problems. Second, it was important for the people responsible for creating the user experience (in this case, the engineers) to watch how actual users approached the task.
For an organization that hasn’t historically tested their systems, observing a usability session can be enlightening. Sometimes people fear introducing real-users to engineers or other stakeholders: what if the observers rationalize and just think the participants are dumb? This can happen, but honestly in our experience it really is the exception rather than the rule. Two strategies can help forestall this reaction: first, is recruiting to match a profile that users agree is representative. Second, is encouraging viewing as many sessions as possible. It’s harder to argue that all the participants are simply incapable.
Conducting baseline usability testing can be an effective “foot-in-the-door” for UCD processes. Once this foothold is established it’s usually possible to pursue the next logical step: testing well before a product’s release to catch problems before they go out the door.
Starting point: Usability awareness
A situation we more commonly encounter is an organization that is conducting usability testing, but only at the very end of the product cycle, when it’s too late to incorporate much in the way of changes. Issued are identified—and may be eventually fixed—but known usability problems (sometimes major problems) go out with the release. The organization has some awareness that testing for usability is important but is otherwise not practicing methods that will fundamentally improve how their products are developed.
A next step in this situation is to move towards testing early-stage prototypes. It pushes the timeframe of testing earlier, when problems are easier and less expensive to fix. And while the benefits of prototyping testing are often (rightfully) promoted as a way to catch usability problems, in our experience it also helps prevent another type of problem that can lead to product delays: misunderstood requirements.
In our work with clients, we work from a variety of requirements sources. But regardless of the source, we frequently find that once we start creating a paper prototype based on the stated requirements, somebody has a moment when they realize that the requirements hadn’t really captured their intentions. Or, once they look at the prototype, they realize that what seemed like a good idea when described verbally is less so when seen visually. The key here again is catching the problem early, when changes are easier to make.
Starting point: Proto-UCD
Baseline usability testing, and, better yet, early prototype testing, are great first steps in moving towards user-centered design. But these methods are largely reactive—meaning they are really done after a substantial amount of design work is complete (rather than driving the design).
Organizations that have taken the next step towards user-centered design typically delve into creating personas and scenarios, which are designed to guide design at the very earliest stages in the process. What we sometimes encounter is that these efforts are not based on up-front user research, but instead are more speculative—introducing the risk that they do not represent true user goals and motivations. Often this occurs because the project budget and/or timeframe do not allow for user research. Still, the artifacts are produced, which can lead to a false confidence about how well the system design will meet users’ needs.
Doing research with user proxies is a way to get moving towards user research without the cost, time, and effort of field studies. Realistically, it’s not always possible to directly observe users for every project. When we are faced with this situation, we try to at least conduct research with user proxies (reasonable stand-ins for actual users). This includes people on the front-lines with customers such as sales people and customer service personnel. The key here is conducting research with people who have direct and frequent user contact (in general non-management personnel). Hopefully, proxy research leads into actual user research. But if not, proxy research can still lead to valuable insights that might not otherwise be uncovered.
Keeping realistic expectations
In improving your organization’s UCD processes, it’s helpful to think of your efforts as organizational change. In general, implementing organizational change is 20% technical (defining new processes) and 80% social (getting everyone on-board with the change, which may be viewed as threatening). It’s important to understand that depending on your organization, process change may take time—and require baby steps that are suited to your particular organizational culture and starting point.