Fonz Morris answers your user research FAQs

When it comes to user research, most designers would agree: the more the merrier. “I think that it's hard for you to say you have empathy for your users if you don't talk to them,'' says Fonz Morris, Netflix’s Lead Product Designer. “And I pride myself on being an empathetic designer.” 

For designers with questions like, “how much research do we need?” and “how many people should we be talking to?” Fonz has all kinds of valuable tips. We captured a few of his insights — FAQ style — on everything from lo-fi research tactics to navigating enterprise-scale research projects. 

How do I decide what needs user research? 

There’s a thing the product design team at Netflix call “just dos.” According to Fonz, these are things that “we've decided as a team, we need to fix, so let's go ahead and fix that.” 

From there, you’re spoiled for choice. Depending on what it is you’re testing for — i.e. whether you’re wanting to validate an idea or looking to understand how someone would interact with your prototype — there are a few research methods you can employ, such as:

• User interviews
• Moderated usability testing 
• Surveys
  

There’s a bit of an arc between the three. User interviews are often used to gauge interest in an idea or get feedback to help you decide which direction to go in next. Usability testing is more likely to happen mid-build, when you have designs and functionality that you want users to test out. Throughout the product’s lifecycle, Fonz says you’re most likely to use a mix between user interviews and moderated usability testing. 

Surveys help close the loop and are used periodically as a quick touch base to check whether things are still on track and going as expected, or not.  

“Really, I think it's about understanding what you want to learn, and that varies depending on where you are in your process,” says Fonz.  

Who should I get product feedback from? 

Conducting user interviews is necessary because you shouldn’t design solely based on your own team’s opinions. In most cases, try to keep things as simple as possible. A convoluted process may lead to convoluted answers. 

If all you need is an objective set of eyes or a gut check, you can look to peers in other departments. A simple promise of a free pizza lunch in exchange for a few minutes of their time may be all you need. 

Another often untapped resource is your customer support department. Their log of tickets can offer a wealth of user insights on what’s working and which areas of the product commonly receive complaints or bug reports. Those tickets are also fertile ground for new ideas and innovations. 

How many people do you need to talk to or interview? 

“You don't have to have 1,000 people as your interview database. You can have five, you can have 10,” says Fonz. “I'm sure each of you may know two people, so it's also about being resourceful.” 

The number of people you speak to or survey will also depend on the size of your team or company and the complexity of the project. If you’re a smaller organization with fewer people, think about scaling research slowly. Start with a manageable number (like four or five) and then review the information and see if you have enough. Try not to take on too much too soon or you may muddy your results. 

“I think sometimes as a smaller company, you're very ambitious, so you may say, well, we're going to interview 20 people,” says Fonz. “And it's like, why'd you pick 20? That was a random number. It sounds good, but did you need 20?” 

What fidelity do my design prototypes need to be?

Another common question that product designers often wrestle with is how “pretty” or “complete” their prototypes need to be. Again, Fonz’s response is: it depends. 

“If you're trying to figure out information architecture, you don't need a hi-fi prototype to do that, you can get away with text and boxes,” he says. “If you're trying to get a sign off from the company on the overall visual design, then you're going to need hi-fidelity, because [the people you’re presenting to] are going to want to see how it all works, not just boxes on a screen.”

Fonz also offers a potent reminder that the fidelity of prototypes can also be an engineering-driven (or co-driven) decision. Remember: the higher in fidelity that your prototype gets, the likelier it is that it’s ready to start building. 

As Fonz says, the robustness of a prototype is usually a sign that “you’re happy with the design, you’re happy with the UX, now you’re trying to figure out the interaction and you want to touch it and experiment with it.”

Once engineering is involved in the build, there are fewer opportunities to go backwards in the process. Most organizations scope out their budget for the build itself; any changes thereafter costs money. 

If you have some outstanding questions about functionality, Fonz advises that you get your prototype to as final or robust a state as possible and then partner with engineering to design around any outstanding questions or unsolved issues. 

Not skipping that step means that engineers will be better poised to build confidently while minimizing (often expensive) hiccups and surprises down the road. 

How much research is enough research?

More product designers, Fonz included, believe that you can’t go too far with research; especially not if you’re always employing a learning mindset. But there is always the risk of focusing so much on research that you slow down the process, and that’s never the goal. 

How do you keep yourself from going overboard on research? Prioritize your questions strategically. 

“If you get those questions answered, you can stop,” says Fonz. “Now, if you want to have multiple answers to those questions, that's up to you and your team, you can keep going. But I'm a very simple designer. I don't ever want to do too much work just for the sake of doing it.”

A basic framework for good user research brief may look like this:

• Write down all the questions you have (or the information or answers you’re seeking)
• Once you’ve collected your responses, ask yourselves: is this enough to move forward with? Are our questions answered?
• If the answer is “yes,” you can likely pause or conclude your research and move on. But if your research yields more questions, by all means keep going. 

If you work at a large organization and find that research is taking up a lot of your time, you may be ready to scale.

How do you share your user research findings?

Once you’ve gathered your responses, how do you analyze the data and then share your findings effectively? 

“The debrief is huge,” says Fonz. Research is a team sport. As such, the debrief of the results should include the whole team. “Everybody observes different things,” he adds, “so you want to hear from your teammates so you can clarify any confusion or anything of that nature.” 

He also recommends putting together a final synopsis of your research results and signing off on that document as a team. 

User Research Synopsis Template

A well-structured one pager is all you need to pull together an informative and effective user research synopsis. Fonz emphasized that research findings are “probably useful to everyone in the company, not just the design team,” so it helps to present information in a super simple format that multiple team members and departments (e.g. sales, marketing) can use.

Elements of your one-pager can include:

• Research goals and objectives
• Summary of interview responses 
• Real life examples (interview quotes, relevant customer support tickets) 
• Clips of session recordings (audio or video) 
  

“Putting that document together with the mindset of, ‘I'm trying to get this information to my teammates who weren’t able to attend the sessions,’ is a good process,” he says. 

How do you balance (or validate) efficiency and effort with creativity and customer delight?

Compromise is something you have to get used to negotiating. Let’s say you send a design to engineering and — in the process of making the product the most functional it can be — they pare back the designs heavily in favor of technical efficiency. If something like that happens, which it usually will, that’s when the designer needs to step in as the user advocate. 

When faced with a similar situation, Fonz started by explaining why he’d made certain design decisions and was open to hearing about engineering limitations. “Now we're in the middle of trying to find that perfect harmony between: well, where was I being maybe extra creative and where could I find a smaller solution? And my partners in engineering are doing the same and considering where they might be able to push the bar more in terms of what we could build.” 

It’s precisely during these times that user research proves to be the most valuable. It sets the baseline for what the user wants and needs. When in doubt, you can go back to your notes and explain why a certain feature is a “must-have,” or to use one of Fonz’s terms, a “just do.” 

Usability and user satisfaction are not interchangeable, they’re inextricable. Fonz showed us that the only way to get there is through scaled, efficient, resourceful and reliable user research.

‍

This post is part of an ongoing series featuring snippets from Same Page — our event series that explores the design process. Explore In the Margin to see full-length recordings and more content on the design process.