Commentary

May 7, 2009

Architecture and User Experience (Part 7b: Getting to Know the Problem)

In last month’s article on this topic, I raise the specter of user research: how much is necessary and how much is enough? Different organizations have different thresholds for the amount of research they can tolerate. Lightweight research methods are often sufficient to capture the “low hanging” fruit, not because they are incredibly efficient but because many of the products and services we are called upon to fix are riddled with easily discoverable problems.

I continue last month’s questions: What is the right amount of time to spend researching versus “getting it done?” How can we know when to turn our attention to the solution and stop collecting “just a little more data?”

Is Ethnography the Answer?

Ethnography has been bantered about as a form of design research quite a bit lately. While many ethnographers are pleased at the uptick in business, an equal number express uneasiness about the casual use of the term. Ethnography is as much a process of investigating the culture of a target population as it is a framework for compiling and reporting the results. It is about telling individuals’ stories from their perspective within their framework. In highlighting how people inter-relate within an ecology, ethnographers help reveal the joys, delights and attractions of the ecology as well as its gaps, problems and opportunities for improvement.

A Simple Case Study

When observing a telephone technician struggling to identify the source of an alarm in the network operations center (NOC), seeing the adrenaline rush, and realizing, with him, that every second lost is lost revenue, unhappy customers and a possible investigation by a federal oversight agency, we feel first hand the real issues at stake. Prior to that moment, I had no experience with operating a NOC, and had only heard second-hand from others in my company what challenges these people faced. Nothing my cohort had said could inform me of the reality of that moment and the design constraints it implied.

When the moment passed, and calm had returned, I could ask simple questions about what I had just observed. The technician’s words were important to hear first-hand, but equally important was to read his face and gestures, to capture the continuing echoes of that event. Suddenly I understood the aftermath of the event was as important a moment as the “heat of battle”—there were things to be done after the crisis with impacts nearly as disruptive as the crisis itself. Here again, my office mates couldn’t have provided me with the key insights I acquired merely by being present and observing.

Most businesses don’t invest heavily in ethnographic techniques and for good reason. To do ethnography justice takes time: from several weeks up to a year. Instead, a form of applied ethnography, contextual inquiry, has been proposed as a much more efficient, cost-effective means of capturing similar data.  In fact, contextual inquiry can be an excellent quick-and-dirty approach to identifying low-hanging fruit and relatively obvious opportunities for improvement. Since most business environments are fairly inhuman, and the tools used in business are mostly not designed with their users in mind, quick-and-dirty techniques can easily reveal potentially profitable opportunities. In other words, we don’t have to be incredibly precise or gather longitudinal data to identify gaps sufficiently large enough for the business to profit from.

Simply observing, listening, and asking open ended questions reveals far more about a new ecology with far less cost than any other method I’ve encountered. When questions are framed not by the preconceptions of the product developers or business owners but by the users themselves, we have a far clearer idea of the real challenges they face. When I am asked to talk about the process of observation and the kind of data it generates, I like to pose a thought experiment to my listeners:

Imagine you’ve been asked to improve the experience of getting to your work from your home. (Imagine for the moment your place of work is outside the home). Imagine you’ve been asked by the marketing department to help them craft a survey of 100 people.  Now try to imagine the questions:

  1. If you drive to work, where is your car parked?
  2. Do you take the keys off a hook, out of a bowl, or do you keep them in your coat or purse?
  3. When you open the door, do you slip your briefcase in the back, on the passenger seat, or do you use a backpack?

Silly as that seems, most of the surveys I’ve seen attempting to isolate key factors for improving an offering are about as ridiculous. Okay, now imagine an alternative: I will identify a handful of key individuals and I will accompany them on their way to work for several days in a row.  I am confident the amount of data I gather in that short time frame with those few individuals will be far more actionable, reveal far more opportunities for improving the experience, and most importantly will narrow the field of inquiry far more efficiently than any statistically significant survey tool.

This isn’t your ride to work—it’s theirs. It isn’t your experience you’re trying to improve, it’s theirs. To be able to improve your audience’s experience, you have to first discover what (if anything) is wrong with it from their perspective.

Framing the Results

Observing a new ecology with a fresh mind is crucial, but that doesn’t mean we can completely erase our prior experience or deny our motivations and intentions. In fact, it is crucial to keep those goals and objectives “in mind” as the observation proceeds. Consider the above thought experiment in the following contexts:

  • You’ve been asked to design a mapping system for commuters
  • You’ve been asked to design a car entertainment system
  • You’ve been asked to design rain protection gear
  • You’ve been asked to design a new community

We would be foolish to ignore these design intentions even as we are observing the ecology. Random bits of data we might ignore or discount may catch our eye in the context of one of these design problems. Similarly, the same observation might have very different implications for one design problem over another.

The key is to engage the experience with a beginner’s mind influenced by the project’s design intention.

If we expect to create User Experience Architectures, we must expect to take an appropriate amount of time to do our research. If we are breaking new ground and truly investigating new ecologies of use, we can expect to spend more time up front in research than for ecologies with which we are familiar.  We are obliged to educate our clients about the importance of this up-front time, the deliverables we expect to come out of it, and most importantly, the profitable impact those deliverables will have on reducing our costs of development and improving customer satisfaction.

UX Architecture as the Vision Statement

At the time I was asked to get moving along on the solution and stop the research, I had already completed the research phase several years prior. As it turns out, this organization was not only unfamiliar with the methods I had used for research, they were fundamentally unfamiliar with the process of design. Without a proper understanding of the vocabulary of design, without experience with the deliverables of design and without a fundamental belief in the transformational power of design, they couldn’t bridge between the deliverables and a course of action. 

As in any profession, Architecture and design use specific tools for communication. In many cases these tools are not meant to communicate with non-designers at all, but to facilitate collaboration among designers. It would be facile to say my audience “just can’t understand” if they aren’t designers, but that would only underscore my failure of communication. I should understand my audience in such a way I can tell a story they will appreciate and internalize. How do we communicate the results of our work in ways that others can understand? 

I learned a fundamental lesson in all of this: if nothing else, UX Architecture is a vision statement of the problem and potential solutions wrapped up into a comprehensive and comprehensible package. The vision must be framed in the context of the audience for whom it is intended, describing an ecology of use as recognizable as it is innovative.

Over the next installments I describe the parts and pieces of a User Experience Architecture as they relate to our stakeholders. In addition, I provide a UX Architecture meta-model to help categorize the various deliverables we create.

Comments

Add a Comment

Please log in to leave comments.

Not a CHIFOO member? Taking part in our online discussions is a benefit of membership.
Join us!