kip/bot/blog

Two articles, once again from Todd Walker, highlight how research (or research-driven techniques) needs to be (re)-grounded in the needs of design.

The first, Design Meets Research from AIGA,  has a useful survey of leading testing techniques and provides some pros and cons about each of them.  In the middle of the piece is a paragraph that summarizes the key problem most designers have with research:

There is a group of brand consultants and cultural anthropologists alike that believe now that it is not the actual research itself that is the problem. It is rather about how research is often misused, what type of design concepts and stimulus are tested, and how data is analyzed that is most often at fault. When used correctly, research shouldn’t stifle creativity but rather offer designers stronger inspiration and focus.

They remind designers that there’s a critical interpretation phase that comes between research and design.  No one would disagree with that statement, but where it gets tricky is how people define interpretation and who participates in it.  In more than one work environment, interpretation meant a summary of major findings, was conducted by the strategy group or account lead, and somehow straight-lined to design recommendations.  (”Only 49% of respondents viewed element x favorably -> Replace element x or remove it.”)

The article hits some other high points:  know what you’re testing for; remember that testing is ultimately about better understanding a customer (heightening designer empathy with the audience) and not about having customers do design; ethnographic activities are still the best things for designers to do no matter what; research is an art not a science; interpretation is a joint activity between design and research.

The other article, Personas and the Role of Design Documentation has similar themes, but is more focused on personas.   Specifically, it focuses on the way in which most people go through personas as a deliverable that needs to be done, not as a tool with a purpose and communication goal.  Key point for the writer:

Personas are not documents, and they are not the result of a step-by-step method that automagically pops out convenient facsimiles of your users. Personas are actually the designer’s focused act of empathetic imagination, grounded in first-hand user knowledge.

The best part of the article is a distillation of lessons from Alan Cooper’s ‘origin of personas’ story (mythic in its grandeur, but true):

1. Cooper based his persona on a real person he’d actually met, talked with, and observed.
This was essential. He didn’t read about “Kathy” from a market survey, or from a persona document that a previous designer (or a separate “researcher” on a team) had written. He worked from primary experience, rather than re-using a some kind of user description from a different project.

2. Cooper didn’t start with a “method”—or especially not a “methodology”!
His approach was an intuitive act of design. It wasn’t a scientific gathering of requirements and coolly transposing them into a grid of capabilities. It came from the passionate need of a designer to really understand the user—putting on the skin of another person.

3. The persona wasn’t a document. Rather, it was the activity of empathetic role-play.
Cooper was telling himself a story, and embodying that story as he told it. The persona was in the designer, not on paper. If Cooper created a document, it would’ve been a description of the persona, not the persona itself. Most of us, however, tend to think of the document—the paper or slide with the smiling picture and smattering of personal detail—as the persona, as if creating the document is the whole point.

4. Cooper was doing this in his “spare time,” away from the system, away from the cubicle.
His slow computer was serendipitous—it unwittingly gave him the excuse to wander, breathe and ruminate. Hardly the model of corporate efficiency. Getting away from the office and the computer screen were essential to arriving at his design insights. Yet, how often do you see design methods that tell you to get away from the office, walk around outside and talk to yourself?

5. His persona gained clarity by focusing on a particular person—”Kathy”.
I wonder how much more effective our personas would be if we started with a single, actual person as the model, and were rigorous about adding other characteristics—sticking only to things we’d really observed from our users. Starting with a composite, it’s too easy to cherry-pick bits and pieces from them to make a Frankenstein Persona that better fits our preconceptions.

There are, of course, challenges embodied in these lessons.  Grounding a persona in one person could lead to endless ratholes about which one person, and number wonks will immediately jump all over the “method”/”methodology” point.  But the key point is that personas are ways of creating empathy with the user, of getting us (our team and clients and other stakeholders) out of our own heads and into someone else’s, of creating conversations with potential customers and users.