You should stop designing for the clients
A practical guide on how to conduct user research (with examples)
I tilted my head back and chewed on a pencil.
What should I do next?
I'm looking at my email where the client describes the changes to the design of his website. It's the fifth iteration, but we agreed on two. We're already out of scope.
I got involved in a project that I had no idea how to complete. The designs are the exact implementation of the client's product vision. But he always has new ideas. I don't want to lose a client, but I'm tired, angry, and worried.
What do I do to stop this endless revisions circle?
Implementing the client's vision of the product is excellent. He knows what he wants the most. But there's one massive issue with this approach to design: the client is often not a part of the target audience for the product.
So instead of juggling endless ideas from the client and trying to add more and more features to the product, get to know the potential users and learn what they want.
I introduced a client to this idea, and he liked it. I asked if he has a few potential customers who want to use his product. That is how the new journey began.
Here's what I learned about conducting a user research
Talking to potential users and understanding your market is the first and most important part of the process. It's about understanding your users to figure out what you should build or design and make money. User research looks like rocket science for some people, but it's pretty simple when you get started.
The process I'm gonna be talking about was messy, and most of the tasks happened in parallel, with frequent revisions. But I'm going to outline it relatively straightforward for the sake of simplicity.
Brainstorm user types
One of the most significant issues of clients who want to build a new product is focusing on a wide variety of users. But you can't design a product that meets specific needs without narrowing down your users.
It is a common problem, but it's easily surmountable. You brainstorm possible user types, add characteristics, and narrow them down. After that, you'll start having conversations with people who fit your "possible user avatar."
You can start with the typical characteristics such as:
Age
Gender
Technical ability
Language
Tools
And then add characteristics specific to your project. You don't want to be generic here, so try to develop a character that will reflect your potential customers.
Prepare data collection tools
Before doing any research, make sure you have the right tools and materials to collect the data. Templates, guides, and essential organization will always make your life easier.
Create a master interview notes template that you will copy for each interview title with the interviewer's name and the date of the interview. Here's what you can start with:
Name: First Last
Age: ##
Researcher: Name
Date: DD-MM-YYY
Is the user signed up for the beta: Y/N
What communication have we had with the user before the interview? Do we know them already? What do we know about their opinions of the product?
Interview location/setting description: Especially describe where the user usually works; understand their workflows and organizational processes. Pay attention to little things and anything that might look like a workaround. What communication type you're using: Zoom, Hangouts, etc.?
What technological solutions does the customer use in their process? If applicable to an in-person interview, technology description: Mac or PC? iPhone or Android? Tablet, smartwatch, whiteboard. The list goes on.
Interview notes: Insert notes here.
The other important document is the interview guide, where you'll keep all of your questions and topics you'd like to cover in your interviews. You'll have it open during interviews. It shouldn't be an exact script. Instead, it's a guideline for you to keep the right track of the conversation.
The best interviews are freeform conversations driven by the user. Ideally, it would be best to never look at the interview guide and simply ask follow-up questions based on what the person is already talking about.
Recruit users to interview
Recruiting the users for an interview is the most tedious part. This is why there are companies that find people to participate in studies.
It can be challenging to find the right people to talk to, especially if you're not a part of a target group and don't have anyone in your close circles.
But there are plenty of free ways to find people for your research. Social media is a powerful tool in this situation. You can also utilize the communities, such as Reddit or more industry-focused communities.
If you only have a few people to interview, at the end of each interview, ask something like: "Do you have anyone else who you think would like to talk to me about their experiences?" and then do the same in the thank you email that you send after the interview.
Synthesize information
I'm a nerd when it comes to organizing the notes. I usually do this daily: analyze new notes, catch up on previous notes, read old research, synthesize data. This is the most critical part of the process.
To make the most of your notes, I recommend having another person from your team present during the interviews. You will do the talk, and the other person will take notes.
After each call (that must be recorded), catch up for 5 minutes to go over critical notes and identify missed ones. The next day, I'll go into all the notes and add new details to the synthesized version.
When you're analyzing the notes, try to focus on extracting the users' pain points. You want to do this to become empathic and thoughtful. In a while, you'll start noticing common patterns in people's behaviors, decisions, or workflows. These are your starting points for the next step - ideating features to address needs.
Ideate features to address needs
When ideating on features, ensure that you're addressing the pain points identified in the previous step. You want to help your users, so it makes sense to build features that focus on those key pain points.
You'll start realizing that some features will build the core of the product, while others will be nice-to-haves that will have a smaller impact on people's workflows.
From here, you can dive deeper into the ideas and create the first MVPs to test your ideas with the users. Start with simple sketches, create low-fi designs and test your hypothesis.
Get feedback
You want to test if your ideas are worth building at this stage. By testing the solution you've designed with the users you interviewed, you get feedback and improve your features before making the product.
Conclusion
The project ended more extensively than I and the client expected, but the results were tremendous. We talked to the potential customers, identified their pain points and existing problems, designed and built an MVP with core features, and started testing.
The client was happy with the outcomes and left a great review:
"Sometimes you think you made an expensive choice, but trust me Alex is worth every cent. You will find few guys who go the extra mile to derive satisfaction from their own work and Alex is one such guy. You will get more than what you expect. Wonderful experience, beautiful designs."