Illustration by Tracy Dai
When it comes to design research projects, most UX designers already have the key knowledge base required. That’s because an effective research process follows the same steps as the product design process: Discovery > Design > Development.
In this guide, you will find step-by-step instructions to take your UX design from concept through development. Throughout this post is a mix of checklists, outcomes to meet, templates, as well links to additional resources created by our Adobe research team as well as resources from other UX research professionals.
At Adobe we have the luxury of working alongside some very talented UX Researchers that guide us through this process. I’ve included their presence as a “nice to have” in many steps because they are very nice to have throughout this process; however, all UX designers should be doing user research regardless if this role exists at your company. I hope this guide will help you build your confidence in order to do so. We’ll go through all of the product design phases focusing on 4 key methods of user research:
- Discovery interviews
- Concept testing
- Usability testing
- Prototype testing
Below, we’ll explore each of these methods and the best ways to go through them effectively.
The discovery phase of UX research
The first thing you’ll want to do, before you begin the actual research, is identify your key goals you’re hoping your UX research will achieve.
1. Host a research kick off meeting
Goal: Define the problem you want to test.
To have a kick off meeting, all you need is a concept or idea you want to explore and an understanding of the team members that should be involved. Whether this idea comes from Design, PM, ENG, or your customers, it’s great to have a meeting to start understanding the problem you’re looking to solve further. During this meeting you will discuss the problem space and map any assumptions or biases you have upfront. During the meeting, you’ll want to answer these questions:
- What do you know about the problem?
- What don’t you know about the problem?
- How are users solving the problem today?
- Who are the people you are expecting to talk to in this research study?
- And what are you expecting them to think about the problem?
Write out the things your teammates say during this meeting on sticky notes. Use those sticky notes to form your problem hypothesis (you may end up with more than one). You will use that problem hypothesis to formulate a research question that you want to pursue.
Key resources:
Deliverables to complete:
- Hold an hour long kick-off meeting
- Align on knowledge gaps and discuss biases
- Identify key stakeholders
- Write out a problem hypothesis (for example: “Customers have a hard time organizing their files in the current interface”)
2. Define your research plan
Goal: Prep for your discovery interview.
Consult with your design research team (if you have one) to decide which modes of research will best solve the problem. Depending on what phase of research you are in, decide if you need to follow generative/formative/strategic research (learning) or evaluative/tactical research (testing) methods:
- Discovery Interviews (learning) – Having conversations with participants to understand if they even have the problem you are hypothesizing around and what might be contributing factors. These are more general conversations around workflows, pain-points, etc. No designs shown.
- Concept Exploration (learning) – Having conversations with participants to better understand the problem space and refine the problem hypothesis into a problem statement. Showing a couple of designed concepts you want feedback on.
- Prototype test (testing) – Understanding how this design works. Live interactive prototypes shown.
- Usability test (learning/testing) – Discovering if you have designed the correct thing for the user, can it be understood by the user, did you miss anything? Designs shown.
Key resources:
Deliverables to complete:
- Select a research outcome (e.g. we will create personas/identify use cases/get feedback to create a design, or drive a decision around some approach).
- Work with stakeholders to define how the success of this research will be measured.
- Decide with team members on selection criteria for participants: what qualifies or disqualifies them from participating? Ask if they should have previous experience or knowledge about the subject. Where will you recruit them from?
- Decide who is responsible for the recruitment of users, along with the organization and scheduling of tests.
- Set clear expectations set to everyone’s involvement with the plan.
- (Optional) Document all of these decisions in a Research Plan.
3. Execute your research plan
Goal: Prepare for discovery interviews.
In the previous step, make sure to discuss who is responsible for recruitment, who is setting up tests, and who is the main point of contact for communicating with users. Also, discuss all the logistics of conducting the call. Who is doing introductions, who is leading the call, who is taking notes, and where are you taking notes and in what format? Set up 4-5 discovery interviews with actual users.
You should also work to develop a discussion guide you will use during these interviews. It’s good to get all of the questions your cross-functional team wants answered out in the open right up front, and then work with UX research partners to refine the script to make sure it flows and poses questions in a non-leading way.
Key resources:
Deliverables to complete:
- Schedule interviews
- Develop a interview script or discussion guide
- Prep your team
- Run a pilot test with a sample participant (friend or colleague) to make sure that the test materials, script, etc make sense when someone unfamiliar with the project encounters them..
4. What to do on the day of your research calls
Goal: Have the call.
During your research calls, you will be validating or disproving your problem hypothesis while exploring users’ pain points and needs around that problem. If at all possible, after each call, share main takeaways and key findings that stood out to you; this makes it easy to ensure no one is missing anything. You could set aside five minutes after each call that you and your colleagues all stay on the line, or have a slack conversation/email.
Key resources:
Deliverables to complete:
- Have the discovery interviews
- Immediately following call debrief for 5 minutes
5. Debrief and analyze
Goal: Make sure everyone is hearing the same thing and that your test is working.
As mentioned above, it’s great to debrief for just five minutes after every call; however, it’s even more important to have a meeting once the first round of interviews are finished to discuss your findings as a whole. You should take this chance to reflect on whether you feel like you are getting the right data with the research method that you chose.
Read back through all your notes and use methods like affinity mapping to analyze the findings. If at all possible, it’s great to do a post-it note affinity mapping exercise with PM and ENG so everyone can be a part of the discovery of any key insights. Then, take those findings and turn them into requirements you can design off of.
For each of the below types of tests, here are the guiding questions for your debrief after:
- Discovery interview: Is this a problem we should be fixing, what are the problems in this space?
- Concept testing: Are our ideas on how to solve the problem meeting the user’s needs?
- Usability test: What do users want to be able to do with this tool?
- Prototype test: How does this design work to meet their needs?
After answering these questions decide how confident you are about the findings and the conclusions on what the next steps should be. There may need to be additional testing at this stage to the testing materials, participant type, protocol or mock-ups?
Key resources:
Deliverables to complete:
- Debrief on results of tests so far
- Debrief on interview style
- Create rough design requirements from research
- Create summaries of research
- Share out with other designers/researchers
The design phase of UX research
6. Design mocks
Goal: Take your recommendations and turn them into researched design decisions.
In this phase, the mock-ups you create should help align all stakeholders on what you learned from research and a direction for your design. The fidelity of these mocks is not so important as long as the concepts in the workflow are clearly communicated. Once you have a set of mocks, you can do another round of testing with users.
Key resources:
Output:
- Designed mocks in the appropriate level of fidelity
- Create a persuasive data narrative that sets up your design changes for non-design stakeholders, so that you can clearly communicate your design decisions
8. Test concepts
Goal: Put those mocks in front of stakeholders and users.
In this round of testing you might still be doing some concept validation; occasionally, something may sound good to a customer until they see it. This could be a result of your misinterpreting their feedback, or it could be a sign that your concept isn’t solving the right problems for the user. If you feel like your concept is pretty validated, move on and begin testing the usability of the experience you have designed.
As your design research becomes less exploratory and more directed toward testing your design, give fewer specific instructions/directions to the participants and watch them more. When given a general goal to achieve, what routes do they try? Do they follow your intended path through the mockup or prototype without being told exactly what steps to follow? Can your design accommodate those alternative paths? Can your design steer the user to the goal more effectively? Does your design unintentionally make other tasks more difficult? What other tasks might be typical for a user in this part of your experience? Are they also supported by your design and easily achievable?
Resources:
Deliverables to complete:
- See section 3 for recruiting users and prepping for testing
- Conduct a second round of calls with a mix of the new and past users you tested with
9. Debrief and iterate
Goal: Debrief from concept testing and decide if you are ready to move to usability testing.
Don’t dwell too much on a couple of people’s feedback. Make sure you get at least three concept tests under your belt before you think of pushing your mock-ups in any one direction. Once all tests are conducted, do a design iteration based on this round of feedback. You may find out that you need to totally pivot your designs…or you may be right on the money.
These edited mock-ups are either for additional concept testing or to move on to usability testing. If you are moving onto usability testing, decide what fidelity of design you can build out for the usability tests.
Key resources:
Deliverables to complete:
- Make refinements on your concept based on testing results
- Decide if you need to do more concept testing or if you’re ready to move onto usability testing
The development phase of UX research
10. Prototype or retest new mocks
Goal: Iterate off of your designs to produce a more informed set of mock-ups.
In this phase of the process, you will have hopefully gotten enough viable feedback on your mock-ups that you can hand them over to ENG to prototype, or work on an interactive prototype yourself using a website prototyping tool. If you have complex interactions and new UI patterns you will definitely benefit from a clickable prototype. Prototypes often help users view a new feature in the context of their own workspace, so that they can better hypothesize how they would use it in their regular workflow. This is the first step in the development phase of UX research because everything you just learned in the previous prototyping phase can greatly impact how quickly and smoothly development can be done.
Prototyping can also help you “sell” concepts and features to key stakeholders. By demoing live prototypes, they can easily see the value of the changes you are pursuing.
Key resources
Deliverables to complete:
- Explore prototype creation tools
- Spend time illustrating to stakeholders the value of prototyping
- Hand off mocks to engineers to prototype
- Support ENG so that they understand the most important features of the prototype to test
- Cycle back through another round of research using the prototype
11. Release your design and listen for feedback
Goal: Decide how you’ll be measuring success and listen for feedback.
Before releasing your experience to the world, outside of a testing environment, you should work with your PM and ENG teams to decide what metrics you will use to measure success of the feature. Schedule a review with your development team to go over the design and make sure that it is implemented correctly. Also, if this is an option available to you, work with ENG to define exactly what you need tagged in the UI to get the data to support your success metrics.
Once released, find out what customers are saying about your new feature or experience. Consider setting up a couple of calls with users to better understand how they are using the new feature. This may inform a V2 of your design.
Key resources
Deliverables to complete:
- Review designs with ENG to make sure your designs were implemented correctly
- Read forums about your features
- Check analytics on how a feature is performing
- Set up feedback release calls
- CELEBRATE!
If you made it through this whole guide, congratulations! If you skimmed it and clicked on a couple of links, thank you kindly. If you merely looked at a couple of visuals and then scrolled down here, I hope you walk away with two key things:
1. Having your cross functional team involved in this process is very important.
a. By bringing your key stakeholders (PM, ENG, etc.) along for the ride you are making it immensely easier to defend your design decisions. By having them hear user feedback alongside you, you are helping them develop more empathy for the user and eliminating the need to create huge cases for why you want to completely change a workflow, because now they’ve heard straight from the user why a UI is not meeting their needs.By bringing your key stakeholders (PM, ENG, etc.) along for the ride you are making it immensely easier to defend your design decisions. By having them hear user feedback alongside you, you are helping them develop more empathy for the user and eliminating the need to create huge cases for why you want to completely change a workflow, because now they’ve heard straight from the user why a UI is not meeting their needs.
2. Time is relatively hard to measure.
a. I can not tell you how long exactly this process will take. There are many articles on the web around how to schedule user testing into a sprint or how to create a research schedule. I have found that no matter how hard you try and stick to those schedules there are always cases in which you find out half way through the discovery phase that you are designing the wrong thing. The important thing is that your cross-functional team is seeing the value of user testing. Time spent user testing is time saved in developing the code and money saved because you eliminate the risk of having to roll back a feature that wasn’t properly vetted.
There are so many more complexities of user research that I haven’t outlined here, but I hope this guide will inspire you to advocate for more user research in every step of the product design process. Or, at the least, I hope it gives you a tangible place to start when thinking about adding even just one of these steps to your process. Without user feedback we cannot properly evaluate how our designs are impacting our customers. I guarantee if you take even one step from this guide and implement it in your process you will be more intune with your customer’s needs and be able to design more thoughtful experiences because of it.
Special thanks to Eric Jensen, from Adobe Design Research and Strategy, for his help with this article.