I’ve spent a good part of the last five years learning, teaching, and practicing design research. I’ve slipped it into every project I can. I’ve preached its virtues, sometimes publicly. I wrote a whole chapter about it in my book. So why, after all this, do I find myself lately wondering whether or not design research has any value, and if so, how much? I find myself asking, How useful is design research really?
Many of my colleagues won’t do a project unless it includes some research, but more and more I’m finding myself tilting away from research, or at least to a less dogmatic view of it. On projects, I’ve found myself not doing design research or very little of it, and the projects seem to have turned out fine. Luck? I dunno. But I know I’m not alone; Apple doesn’t do any research that I know of.
I also keep thinking back to Jesse James Garrett’s seminal essay ia/recon (which is probably long overdue for a re-reading) and Jesse’s admitting that, in the end, he has hunches: “[G]uesswork is an inescapable part of our work. More importantly, the quality of guesswork is what differentiates a good architect from a bad one.” Michael Bierut reveals the same in a recent essay as well: “Somewhere along the way an idea for the design pops into my head from out of the blue. I can’t really explain that part; it’s like magic.”
One of the reasons designers are hired is for their expertise–those good guesses–part of which is knowing what works and what doesn’t in most situations (more on this in a minute). One could argue that that expertise (intuition, experience, understanding, taste) is more important than an understanding of users. I’m not sure I want to go that far, but I have decided a more reasonable approach to design research is required than the dogma that it has to be included on every project. I’m convinced that for many projects, the 80/20 rule applies: without research, I can get 80% of the way there, and sometimes that 80% is enough. Research can be an effective tool, but it can also be a time waster and ineffective. You can follow users (and time and money) down some serious rabbit holes, never to return. Here’s some guidelines I’m putting around research for myself.
Use design research when
- You don’t know the subject area well. I am no expert in investment banking. Designing a product for investment bankers might require learning about what they do and why they do it.
- The project is in a different culture than your own. China is a very different culture than the US. So is India. So is Western Europe. Cultural differences can be cause differences in behavior and expectations for a product.
- The product is one you’d never use yourself. Luckily, as an affluent white male in my 30s, I have a lot of products directed at me. But I’m not a doctor or nurse, and I’m not likely to use medical devices, so I’d have to use research to find out how they would use them.
- The product contains features and functionality that are for specific types of users doing a specific type of work you wouldn’t do yourself. MS Office contains a bunch of features I would never use, but if they were removed, some power users would scream bloody murder. Sometimes you have to understand the nuances of a specific feature or, often, a specific group of power users that use a product.
- The designer needs inspiration. Sometimes you get stuck and an afternoon away from your computer screen can spark ideas.
- The designer needs empathy. Some types of people and groups are harder to identify with than others. Illinois Neo-Nazis for example. Not that I’d ever do a project for them.
Of course, it could be argued that I just outlined every design project. Which is true, to a degree. (Who doesn’t need inspiration?) But I want to think about research differently, namely that research should be a tool, not a methodology. As Jesse pointed out, “Research can help us improve our hunches. But research should inform our professional judgment, not substitute for it.” Like other tools in the designer’s toolbox, it should be used when and as necessary, not applied to every project unthinkingly.
Very interesting and good point.
I agree with you that there comes a time when you no longer feel the need to do research for any design decision you happen to make.
> One could argue that that expertise (intuition, experience,
> understanding, taste) is more important than an
> understanding of users…
Hmmm… Isn’t that expertise coming from some research we have been doing in the past? This reminds me of the statement Gladwell makes at Blink: sometimes intuition is no more than a fast judgement that’s unconciously based on our own experience.
I think you can only refuse research if you’ve done it in the past. It’s like The A Team: their success-without-discipline is based on the fact that they were soldiers in the past.
Dan – I can totally see where you’re coming from and I’ve pondered over this myself on several ocassions. For old-hand designers the solution can be obvious – why reinvent the wheel? BUT… in my experience design research is not just for the designer! It extends out to other members of the project including managers, developers and clients – they also need an understanding of the user community which can lead to impacts beyond the software itself. Frequently research will identify problems (such as workflow, rules and other contexural info) which impact on the user experience – I think Jared Spool calls this the “Domain”. So while the design solution might appear obvious – you still need to gather the context or domain knowledge. Anyway – I agree with your conclusion – research is there to validate our hunches – and is just one tool to inform the design…
I really like zef’s point – to remember that the design research we do isn’t just for us but also for the stakeholders, managers, developers, clients. They may not need to see any of the research, but can damn well serve our needs and those of the clients to make sure we have some (i.e. if we don’t make users happy don’t be surprised when they leave). Nothing wrong with hunches, but even artists do rough sketches before they paint a final version of a painting to flesh out those ‘hunches’.
I’m sort of reminded of my Jewish education, where they talked to us about “the Earth being created in 7 days (including rest) vs. the Earth being created over many million/billion years.” When we asked about it, they told us “Why does it have to be one idea versus the idea? Let’s reconsider what those ‘days’ actually refer to…” In other words, things set up in opposition to each other don’t need to be that way.
Research doesn’t identify solutions. Design doesn’t identify needs. (someone can attack both of those, no doubt.) If you learn about some group, and then start to ideate solutions for them, when are you designing? When are you researching?
I disagree with zef, I guess, because research is there for an awful lot more than validating stuff we already think we know. I think the value in research is when it brings up information/insights that we didn’t know that we didn’t know, sometimes juicy stuff that goes beyond our brief.
Research can be very divergent, and when you are delivering research (as opposed to using research to deliver design) it seems very useful, indeed necessary, to get beyond the question you were initially asked.
I’ve been pondering lately if user research is a requirement for UCD. More specifically, do you have to do user research in order to build a usable and engaging site OR can you rely on best practices, convention, expertise, and experience to design user centric sites. It sounds like you are having the same struggle.
Do you consider usability testing part of user research or are you referring to focus groups, interviews, and surveys? I’ve questioned how outcomes and findings from surveys and interviews, and focus groups have really impacted design on recent projects and where we’d be if we hadn’t done them. Usability testing is different to me and I think its essential. Do you agree?
Interesting article!
The value of doing design research has been a topic of discussion at my workplace recently. Some of our product owners complaint that doing research is time consuming and usually does not lead to very insightful findings. A few of them have been in the domain for several years so they sometimes have very good idea of what their users want.
Danny, perhaps you could give us more guidance on when to do design research by pointing out the non-design factors that will also determine the outcome of the research too. That is, project/people/business-related factors, such as the urgency of the project, the attitude of the client or product owner towards user-centered design, and the competitive landscape of the product. I suspect that understanding these variables, on top of those design-related factors that you have pointed out, may help us to make decisions about how to optimize our resources.
Thank you!
I’m tempted to agree that you can go 80% the way without research, most of the time. But I’m also sure that it helps to spend a few immersive moments in user contexts, to inform or to inspire you. For some reason they call this as ‘research’ when it is no more than ‘study’. Worse, many confuse ‘testing’ with ‘research’ too.
As an urban product designer in India, I’m constantly confronted with designing for situations that are NOT second nature to me – devices for rural markets (though I would of course know this better than a western designer), or for extreme/rugged environments, etc, or for different age groups (kids in school, elderly). A fair amount of study IS necessary firstly to avoid any monumental design disasters, and secondly to inform you of the task better. I normally insist that the designer do or be part of the research and carry this little book of ideas with them.
Ethnographers record people related stuff. Designers record useful design related stuff.