Extreme User Research
What is the biggest problem I face almost every time a client hires me to do something about a web project going awry? They don’t know a thing about their users. They don’t have a clue, whatsoever. Unbelievable but true!
Good designers will certainly argue that THEY don’t need user data to do proper design. That if THEY like it, EVERYBODY will… sure! This probably explains why so many web projects fail in so many levels: Usability, aesthetics, emotions, and profitability.
What’s the remedy to this world-wide infection? User research… but not in the typical version, meaning lengthy ethnographic studies that seem to take forever before obtaining some data. I’m talking about a simpler way, a faster way of doing it. I call it “extreme user research.” What’s so extreme about it? Well, it can be done in 30 minutes per interviewee, and it generates loads of useful data that will have a real impact on design, thus making your website more profitable.
Getting information from surrogate users
Doing user research doesn’t have to be tedious and cost lots of money. In many cases, you should be able to do it in a few days, even a few hours, depending of the scope your project. The main idea behind extreme user research is that instead of going for the real users, we go for surrogate users. Those are the ones within a company who talk directly to the customers. We want to talk to the people who talk to the people.
For instance, let’s say we do an e-commerce project for a cable company. The surrogate users would be those in the call centers—the first-line personnel who provide information about products and the second-line personnel who provide customer support for billing issues and technical problems. Talking to those people means having access to tens, hundreds, or even thousands of clients. Not bad at all!
Doing extreme user research is simple. We simply perform individual semi-structured interviews that last no longer than 30 minutes. This time limit is a profitable constraint. It adds a stress that forces the interviewee to focus on the core, on the essentials. During those 30 minutes, we want to know as much as possible about the customers:
- What triggered the call? For example, was it a problem, advertisement, word of mouth, season, news in the media, life event like a birth, the first job, moving to another place?
- What is the whole purpose of the call?
- What are the callers’ main concerns? Are there any misconceptions or incomprehensions about the company’s products or services?
- What words do the callers use to express their needs?
Do what people do during speed-dating sessions: Focus on the essence. Ask for the top ten questions from customers. Ask for the five things you should know if you’d have to replace a surrogate user for an afternoon. You’ll see, it works!
Go for the individuals. Don’t, I repeat don’t go for group interviews, the infamous focus groups. Otherwise, you’ll have to deal with strong-minded individuals whose influence biases the group and thus the whole process.
How many surrogate users should you interview? About five per job description. You want a certain degree of repetition among the interviewees to avoid anecdotes or personal perceptions. Because of the speed factor, you can interview up to 12-14 people in a single day, which means more than 60 interviews in a week! Yes, these will be long days. Yes, at a certain point, it will be tedious to hear the same thing over and over again. But that’s the whole point. We want to make sure we have solid data based on facts, not perceptions.
Okay. Now, you have done your 40 interviews. You’re swamped with data. What’s next? Well, all you have to do is:
- Extract all the facts that you’ve found.
- Write them on sticky notes.
- Tag each note appropriately using a word or a symbol. I usually use words like user, goal, trigger, concern, FAQ, love factor, hate factor, and incomprehension. These tags will really help you later on for documentation. You can also use different colored sticky notes for this purpose.
- Find patterns and create groups around types of users.
- Create some first-version personas and then refine them.
- Show and tell everyone about your findings.
Designing using facts, not opinions
During the Québec city website redesign (which is not yet online), we interviewed five call-center employees and discovered that citizens interact mostly with city hall for:
- their home (garbage collection and recycling, permits, taxes)
- their street (parking, lighting, pavement and road works, snow removal)
- public services schedules (library, swimming pools, skating rinks, etc.)
Knowing these interactions really helped us focus on what citizens really need. Garbage collection by definition is not very sexy, but when 30% of the calls are about this topic (based on interviews and call log analysis), it becomes clear that the city website has to address this subject before anything else!
Call-center personnel also told us that citizens always ask the same four questions about a topic:
- How to get a service from the city? They want to know the procedure (for example, how to get rid of an old sofa).
- When is it going be done? What is the schedule?
- How much does it cost?
- Who’s in charge?
Having this information helped us design page templates with placeholders answering those four questions. It’s that simple and straightforward.
Knowing, I mean really knowing your users has great benefits. Your design will be based on facts, not on suppositions or false perceptions.
Knowing your users means that you’ll spend money on what users really need, NOT on what you suppose they would need or like. It usually leads to simpler solutions. Having facts reduces those never-ending discussions where everybody has his own solution based on his own personal needs and preferences. It has been said before but I’ll say it again: We, the designer and the client, are NOT the users.
Get out of your cubicle. Get out of your meeting room. Go and get those surrogate users and know as much as you can about your users. You’ll see: Your users are not who you think they are.