How I conduct UX research
Illustration from Alzea's Illustration Pack
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).
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?
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?
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.
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
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:
- Friendly welcome
- Context questions
- Introduction to the prototype
- Quick debrief
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.
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.