Select a theme. Inspired by Breath of the Wild and Max's awesome color switcher
An error occured

How I conduct UX research

February 28, 2021
How I conduct UX research

Illustration from Alzea's Illustration Pack


Abdul Salam created a series of UX questions.

I collected them in Airtable as well and threw it on this site - find it here.

It's a bit difficult to find space for the planning, validating, and testing of new designs — especially when you're the solo designer or on very lean teams.

Finding time to gather answers from stakeholders, interview users, roadmap concepts can already be somewhat timestaking - inbetween actually keeping your head down and prototyping ideas. Figuring out how to build a process or framework for user research inside a rapid, agile, and lean team has been a goal of mine within my current team.

Early on, I came across GV's guide for a lean UX framework and begin incrementally adding in portions into our process - hoping to validate what works for us and build a bridge towards a formal UX framework for our team (and in the long-term, our entire organization).

Abdul Salam collected a ton of great questions to ask throughout a research process. I collected them in Airtable and threw it on this site - find it here

Before designing

Tip: keep a running doc of issues + feedback snippets from a users (past feedback, Twitter, App Store, etc.) and see which ones bubble up most often to help build priority.

To help find and prioritize what we need to design:

  • What data are we currently collecting (e.g. analytics, A/B, customer support, surveys, usability)?
  • What research is already available to us?
  • Who do we need to speak with to gather feedback on the current status of our product?

Past research 🕵️‍♂️

Most probably, you know a few things before you're going off into desigining something new:

  • Who are our users?
  • What is the general product roadmap? (maybe even company roadmap)
  • What are the short-term goals of the product?
  • What are competitors doing to answer the problem we're trying to solve? What could they be doing better?

Aligning with stakeholders 👯‍♀️

At this point, we've probably bubbled up a few friction points from our users — now we can start to think about solutions to these problems with a few methods. A few exercises we can try to figure out how to best answer a problem we're solving:

  • Customer journey mapping to gauge and redesign product touchpoints
  • Mind mapping to help align user and business goals with stakeholders
  • Building user scenarios with PM's to pragmatically outline the new feature

There are a ton of tools to help share/build these docs, but a few popular ones are: Figma, Miro, Mural, Whimsical, Coda, or a good old-fashioned whiteboard.

Designing and prepping 👨‍💻

This is the stage where we can finally begin building wireframes/prototypes 🎉 based on the requirements, research, and assumptions we've gathered - we can put our heads down, open up Figma, Sketch, or whatever design tool of your choosing and begin designing a few iterations of this feature/product.

Before moving a feature into a development sprint, we try to frame what we need:

  • Questions and assumptions of what we're designing
  • A clickable prototype (Figma, InVision, Sketch Cloud, Framer, scrappy code)
  • Qualitative research: 1-on-1 interviews (at least n=4)
  • A way to measure the success of this feature

Conducting new research 👩‍🔬

Now that we have our new designs, scheduled participants, and questions to ask, we can begin conducting user interviews to quickly test our assumptions.

Through these user interviews, we can find where friction points may exist, if the new feature makes sense, and any other questions we may want to ask the participant. Just like in the GV guide and Jake Knapp's book, Sprint, we outline our interviews as such:

  1. Friendly welcome
  2. Context questions
  3. Introduction to the prototype
  4. Tasks
  5. Quick debrief

After the interviews 🤠

After we gather the data we received from the user interviews, we find what changes we have to make and either go back to the drawing board or begin handing off to the development team. A few things to note: in my current process, there's typically a bit of overlap within these phases, but your team and process could very well function differently.

That's it! 😩

Hopefully this helps your team, but I'd love to hear about how you manage working between researching and desigining - let me know through email or the form below.

Have feedback?

I'd love to see if this was helpful or if there was anything I should look to update - let me know below!

Hey, I'm Ryan.👋

I'm a designer and .

More about me