The user researchers and UX designers are arguing, again, all because someone had the ridiculous idea that maybe UX designers should be doing user research. Quelle horreur!
Just once I want the classical, highly trained researchers to take a deep breath and realize that a run-of-the-mill, generalist designer doing basic user research processes is no threat to them.
At least, the ones that value research aren’t.
My house is starting to have things break left and right. I’m spending a lot of time triaging my problems: Should I fix the retaining wall this year? Will it hold up long enough for me to get the plumbing issues resolved — and get the deck re-stained? And when am I going to get air conditioning installed again?
One major factor in these decisions is whether I’m going to hire an expert to do the work or I’m going to do it myself. That isn’t an easy question for me — I am a klutz, and I come from a long line of klutzes. (We consider it a minor miracle that my father wasn’t electrocuted given how many times he tried to repair things while they were still plugged in.) I’ll probably employ a contractor for most household things, sometimes because I don’t have the skills, sometimes because I don’t have the energy or time.
I know some pretty hard-core DIYers who scoff at the idea of hiring someone to install a new toilet or a porch light. (You should have heard them when I talked about how much it took to fix the sewer.)
The important thing is that I understand the limits of my skills and when to get an expert. I understand what deep knowledge of one area can bring to my problems (e.g. the deep knowledge to unplug the clothes dryer before replacing the heating element, DAD.)
We hear a lot on design Twitter about UX orgs doing zero research. They’re just winging it—doing whatever product leadership says. It’s McDonald’s Design: Fast, cheap, and not very good. This design-without-research is corroding our ability to push the quality of the design process in orgs. In a world where UI designers just design without any user input or understanding, research-based design processes look heavy and unwieldy. Its strategic benefits of solving real problems for the business and people get occluded by the tactical results “just doing it” provide.
We need young UX designers to know it’s not just ridiculous to design in a vacuum, it’s detrimental.
Now, we could yell at them over and over to do research with Highly Trained Top Shelf Certified(TM) user research… and watch, again, as they can’t make a convincing argument to the people holding the purse strings to fund those initiatives.
Or, we could teach designers a few research tricks and tactics. We could show them how to position what they do in short bursts as business-changing. And we can show them when and how to use that as a lever to get dedicated research into the business.
I helped a design team prep for user interviews. They were meeting with a customer, something they rarely had done before. I was astonished how little they knew about completing user interviews, from the initial prep and goal setting, to writing the questions, to just the basic nuts and bolts of getting the subject to talk.
They had never interviewed users before. Their employers either wanted “design right now” and eschewed research, or relied heavily on user research groups, internal and/or external, who just handed over results.
This company couldn’t afford a researcher, and the design team was trying to move from “just paint our solution we came up with” to a plausibly-researched solution.
I taught them what I knew—the importance of planning, how to give the subject room to speak, the art of digesting the findings into useful actions. I’m not a genius at user interviews; far from it. I know enough to know how to get the answers the team needs, even if they aren’t the answers they weren’t expecting.
I’m not a “user researcher.” I’m a designer who worked on improving my research skills.
My experience in UX, though far more experienced and confident than my experience with home ownership, is still very similar. I have run small research projects, analyzed site stats, done my own user interviews. I can need to do basic user research. At the same time, I would never pretend to be able to run a massive research project, staff it up, and consolidate all the data from all the researchers into findings. That’s well beyond my ability. I understand the limits of my skills and when to get an expert in design.
Michael Hinnant, a Seattle design guru (and my former boss), proposed a gradient for designer skills that extended from ignorance to the unconscious competence of a highly experienced, program level leader. I adapted his (simpler) system into seven levels of knowledge:
- I don’t know what you’re talking about.
- I know what it is and the fundamentals.
- I can perform (and have performed) the skill.
- I can perform (and have performed) the skill repeatedly with quality.
- I can teach someone else to do it.
- I can set up a practice where it can be done, repeatedly.
- I can run multiple programs and practices — an entire division — where it’s done, repeatedly, with quality.
In this view of the world, UX is skill-centered. It’s a useful framework for teasing out the “hows” of what designers do. These are the blue-collar “doing” skills that get design work done.
This view it shortchanges the conceptual, intellectual parts of design — the “whats,” the principles of interaction design, of user research, of information architecture. It’s a lens through which you view the UX as a bunch of activities, not as a body of knowledge.
It’s at the collision of “whats” vs “hows” that we see fights breaking out over user research, over IA, over “accreditation” of UX. Ultimately, it’s a battle fought over specialists and generalists.
There is no question that as an industry and in many of our companies, we need the specialized knowledge that comes from an interaction design degree, or a Master’s in User Research. These are the fundamentals we miss when we focus on the “hows” of design: Fitts’ Law, the principles of gestalt, how bias works in research.
Do the “hows” absolutely require a deep knowledge of the “whats?”
Consider medicine: A General Practitioner doesn’t need deep knowledge of gastric issues; they need to know when they need to refer a patient to to a gastroenterologist.
Consider electrical engineering: the average person does not need deep knowledge of resistance and amperage to replace a light switch; they need to know enough to replace it safely, and the cues that tell them when to hire to a licensed electrician.
Now consider UX: what we should be doing is helping designers work better. We should be guiding them on when to ask for help from the experts. We should be taking opportunities to teach designers best practices. “Of course you can DIY some of your research, but there is a point when you should hire a researcher — or someone to set up a research practice, and here’s what that point looks like.”
When we throw up gates instead of inviting designers in, we turn away potentially good designers while inadvertently building up the bad ones. The ones who want to get better feel inadequate and feel blocked by the stigma that designers shouldn’t be doing research. The ones who don’t care just ignore the criticism and keep right on going with their sophomoric work.
The battle for the soul of UX is a battle between specialists and generalists, between leaning on the “whats” vs the “hows.” Organizations want to spend as little as possible on design, so they’ll hire generalists, who often serve multiple roles. But you need specialists on design teams to be truly effective — specialists that handle things best served by specialists, surrounded by generalists who can handle the big-picture, cross-cutting work that is needed to deliver great design.
Consider some of the research work I’ve done as a generalist.
At one employer I set up a research project for a new product they wanted to launch, one I refused to move forward on design for until we had actual user research in hand. We recruited 20 small and medium business owners, interviewed them, transcribed the interviews, and with the help of the dev and product teams analyzed and summarized the data. (Some researcher is grinding their teeth reading this. Untrained person I am, I did everything wrong. Everything.)
But the research we did changed the direction of the product. The end product pushed speed, clarity, and opportunity over pinpoint accuracy and high detail. Suddenly it wasn’t a bespoke client ask; it was a real product we could sell to dozens of utilities.
It was 80% perfect, but 80% was good enough. As Yvon Chouinard wrote, “I like to throw myself passionately into a sport or activity until I reach about an 80 percent proficiency level. To go beyond that requires an obsession that doesn’t appeal to me.”
A generalist’s view is about handling that 80%. It says you don’t have to be perfect at one thing, and instead can think about a process holistically.
User research only works when it catalyzes new ideas within a design team. A team invested in the value that research creates and catalyzes will make better choices and take the product to new levels of user-friendliness. That happens when generalists understand the skills and actions needed to make great research happen — and specialist researchers understand how to make their work not just useful but transformative for the generalist designers.
Sometimes that means interaction designers will have to perform interviews or deep-dives into analytics. Sometimes it means information architects doing competitive analysis. Maybe it means that user researchers get handed a pen and asked to sketch. Maybe that isn’t so bad.
How good does design work have to be to get to great design? Not every part of a site has to be custom-made and bespoke. Is it delivering more than the customer expected? The only way it can deliver is by anticipating needs through research, providing for them through smart interactions, and surrounding them with appropriate and targeted content. It doesn’t matter if it’s ordering a smart light or asking a smart light to turn off, we anticipate, provide, and surround.
These opportunities only arise when a team can think holistically. Some of that thinking requires specialization. Some of it requires generalists to bind everything together.
We have to get beyond fiefdoms and territorial attitudes. No, we don’t expect designers to do research. But we damn well expect them to understand how it works and the basics just as we expect researchers to know the basics of how things get designed.
Let’s stop squashing designers doing basic research practices. Let’s start showing inexperienced designers and researchers the difference between performing the actions and creating programs and processes that deliver great research results and great design together.