| back to the List |
What I’m really asking is, “So what?” That is, observations made about a product’s users or domain or stakeholders isn’t helpful until you can extrapolate it into a principle or guideline for the design team. An observation on its own is not a design tool. An observation paired with an implication, on the other hand, is very powerful.
This question goes to the person conducting the research, which is sometimes myself and sometimes someone else. Occasionally, it’s the person doing analysis on data collected by a researcher. If these are all different people, it gets directed to the group. It’s not always a researcher’s responsibility to know how something impacts the design of the product, but it is the responsibility of the product team. The product team isn’t fulfilling their charter if they let research hang in the air without drawing a line between insights from the research and the design effort.
In my practice, research generally yields a set of design principles: guidelines that challenge our thinking as we press forward with the design. When I ask “so what?” what I want to hear that users expect certain features or information to be prioritized in the product, or that the product cannot assume that users arrive with one task in mind, for example. Responses to this question should give designers direction on the solution for the problem, asserting an interpretation of the observation.
This question occurs specifically in reviewing observations from research, potentially during a debrief from a recent interview or set of interviews. Alternatively it comes up when compiling the results of a research effort. Research reports that don’t answer this question look incomplete to me, like a joke without a punchline.
After mining observations for design direction, what you can ask next is whether that direction is meaningful. The purpose of design is not to merely react to every observation but instead consider the impact in context. There are numerous forces exerting pressure on the design, incluing the business needs of the product, the needs of other users, not to mention technical constraints. So the next thing to ask is how to reconcile the direction from these observations with the other inputs in the design process.
What does this observation tell us about what users needs out of the product?
It may be difficult to go right from the observation to an insight about the product’s design direction. Instead, you can tease out the direction by building toward it incrementally. Betwen an observation and a design principle is some brainstorming about product requirements, constraints, or expectations.
How does this observation impact the product’s information architecture? How does this observation impact the product’s feature priorities? How does this observation impact the product’s flow?
As a prompt, the breadth of the original question doesn’t offer people a comfortable starting point. Too open-ended, they might not know what direction to go in, or how detailed to be. Narrow the scope by asking about a specific aspect of the product, or tease out an insight about the observation that’s difficult to see by applying it too broadly.