Our UX research and design process for concept-proofing a new feature in 3 weeks
A deep dive into remote design & research at a startup
Background
Our startup recently pivoted the product focus and my team was tasked with ideating and concept-proofing a new feature. The feature will allow property buyers to compare projects based on their purchase requirements. Our team of three (PM, designer & research intern) had three weeks to ideate, design, plan a research study, conduct user testing, and validate the concept idea.
Our robust user research and design processes allowed us to quickly prototype and validate whether the feature would solve user needs. Despite time and resource limitations, here’s how we did it.
Process and team structure
Team and tooling setup
Our team consisted of a project manager, user research intern, and myself, the product designer. When our team was without a research intern, product designers handled user research recruitment (this could take up to 4 days) and had to “borrow” a designer from another team to help transcribe usability tests. Being able to split the workload with our user resarch intern allowed me to focus more time on designing and prototyping.
As for tools, we use Google Suite and Figma for everything from recruiting to design, prototyping, documentation and insight sharing. More on that later!
Timeline and limitations
For a quick concept validation, we did not need to run a full-scale usability test with multiple rounds and users, and neither did we have the time to do so. As such, we referenced past research, re-interviewed participants that fit our user personas, and recruited 4 participants for two rounds of usability testing. Our timeframe was as follows:
- Planning and ideation: Looking through past research, studying user needs and opportunities, workshopping the idea (2 days)
- Design and prototyping: Concept sketches and high fidelity designs, preparing prototypes (4 days)
- Recruitment and usability testing: User interviews, usability tests and rapid prototype iteration (4 days)
- Consolidating insights: Affinity mapping, identifying research themes, concept validation and final report (3 days)
Planning and ideation
Going through past research
Before building this feature, I combed through past research and conducted new user interviews to learn more about user needs. Previous resarch done with similar user groups helped us know what kind of people are using our products and what their goals are. With this, gaps were identified in our product where user needs weren’t met. These were used as the base to come up with new concepts.
We were able to do this in record time because our user research documentation foundation was easily accessible across Figjam and Google Drive.
Ideation workshop
Together, my product manager, dev lead on the team and I workshopped our ideas and mapped them to our known user needs and goals. As our team was working remotely, we used Figjam to facilitate the session.
Past user research was also documented in Figjam, so it allowed me to cross-reference and drag in sticky notes of pain points and user needs from other studies that correlated with what we were discussing.
Choosing an idea
From this workshop, we identified one idea that matched our criteria. The idea had to:
- Answer to the user needs we identified from past research
- Be easy to design and build with limited team members (1 product designer and researcher, 1 web dev, 1 backend, 1 iOS dev, 1 Android dev)
- Fit in easily into our existing products. It will be too much effort for a feature that we haven’t tested to be one that is completely new and stand-alone
- Approved by stakeholders and can be taken forward for rapid prototyping and testing
Design and prototyping
After stakeholders agreed on the idea, I needed to quickly design and prototype it to validate the concept. I started with sketches, then created high fidelity designs to show my product manager. I was able to do a high-fidelity design at this stage because we have a robust design system with reusable widgets and components.
If I had to create low fidelity wireframes, I would actually be spending more time making those than just using pre-existing components to mock up a new design!
After design changes from my PM, I connected the prototype and prepared it for testing. It was fast to make it directly on Figma without having to move to another tool like InVision. Other tools may have more prototyping functionality, but Figma’s basic transitions were fine for a quick concept test.
Recruitment and testing preparation
Recruiting users
- We engaged the data team to get a report of users who matched our criteria. We needed to test with users who are looking to buy a specific property type. As these were our current users, we could easily reach out and ask if they were open to testing a new feature.
- Then, we set up a recruitment spreadsheet to track who we contact and when they’re scheduled to interview with us. The spreadsheet is also useful when we need to dispense monetary user research rewards.
- Finally, we booked video call sessions with users. Calls were set up via Calendly so that users can easily amend or cancel if need be. We have a central user research team calendar on Google Calendar so that everyone is aware of current studies. This helps reduces no-shows and ensures everyone is on time.
A note on our user research values
As our UX research team grows, strive for shared empathy. This is our value of a shared understanding of our users within our product teams. By setting up robust research practices, we move towards product development grounded in accurate user research and insights rather than personal opinion or debate.
In keeping with this, we have a strict folder setup on Google Drive where we keep past research studies and plan new ones. After a study is done, we share an insights deck with wider teams so that our company grows a deeper collective understanding of our users.
Documentation
For this study, we made a research folder containing the following:
- A main research document. This contains objectives of the research study, the timeline and participant information, a link to the prototypes we’re testing, and a script for the interview and usability test. In this document, we also defined our study goals, logistics, and specific items that we wanted to validate in the user interviews and tests.
- Transcription documents for each interviewee. These contain more detailed participant information and personas, e.g. the reasons they might use the feature and what their user needs are. These documents are where our user research intern transcribes the interview. I included pre-set up questions and usability testing tasks here so that it’s easy to take notes within specific sections.
Usability testing
As a user researcher it made me a little sad that our sample size was so small, but such is the nature of a remote-working startup needing to validate a concept quickly during a pandemic! Usually we make sure to test at least with 5 to 10 users, depending on the size of the feature.
Logistics
The session was run remotely on Google Meets with participants sharing their screen as they clicked through a mobile view of the prototype.
At the end of each session, we asked users if they were comfortable with us reaching out for further research sessions. We then added those that agreed to a list of participants to start building a database of users that we can test with often.
Testing and interviews
We tested version 1 of the prototype with 2 users, then made some quick changes to it and tested a second version with another 2 users. I made design changes this quickly because…
- we had already been studying this subset of users and were familiar with their needs and goals
- both users in the first round had exactly the same feedback on specific areas of the prototype
- with only a few days to test with a limited sample size, I wanted to see whether a second version would elicit vastly different responses from users
If we needed additional information to understand user journeys more thoroughly, we made time for regular interview questions at the end of the session. This is usually where we get answers to exploratory questions that help identify new user needs and product opportunities.
Consolidating research insights
Usually after a research session, we go through our transcripts on Google Docs and highlight content that falls in the following categories:
This makes it faster for us to move content over from transcripts to come up with findings and insights on Figjam or Miro (tools we use for consolidating our findings and doing affinity maps). Because we had limited, I instead went straight to Figjam. I scanned through each document to for additional information to understand user journeys, goals and feedback on the prototypes more thoroughly.
Text transcripts to findings on Figjam
I assigned a color to each user we tested with. Figjam has limited colors, so luckily I just had 4 users in this case. I used red for pain points, green for delights, and gray for user suggestions. This way, project managers or stakeholders can easily scan through the findings if they’re looking for a particular nugget of information.
It took me around 45 minutes per participant document to consolidate the findings and group them into categories. Wherever necessary, I rewatched interview recordings to make sure the findings and user quotes were accurately documented.
Documenting prototype feedback
After putting general content and basic user journeys on the Figjam board, I made a section specific to usability test feedback. On screenshots of the feature, I put sticky notes on each section where users made comments and suggestions. This helps future designers on the project to have areas of focus to work on.
Identifying problem themes
After theming content and prototype feedback, I came up with 5 overarching insights that help us define whether the feature is one to go ahead with. These will be the points of consideration and evaluating factors for further iteration.
Since my team might not be the one working on this feature (🥲) I made sure to include useful information for whoever will be. The final part was to include How Might We’s and ideas for feature updates based on user suggestions.
These themes are the most important aspects of concept proofing. From here, our team can create how might we’s and jobs to be done. If our users are lacking trust in a specific feature, how might we help them build that? Knowing items like these helps us narrow down research studies to ask questions and do further research on a more narrow field.
Concept validation & report
After each research study, we usually create an insights deck to share learnings with the company. Stakeholders naturally don’t have time to go through a Figjam board full of sticky notes, so the deck is a summary that contains the following:
- Research goal and background
- What we wanted to validate
- Summary of whether the product is viable to build or not
- Value propositions identified by users
- Gaps and opportunities based on feedback
- Opportunities for further research studies and product development
Future considerations and learnings
Given more time, our team would be able to extract more insights from a larger sample size, and test multiple iterations of the feature. Even though this was just a concept proof and not a full-scale usability test, we were still able to get information that allowed the team and stakeholders to make a decision about feature implementation.
💡 Key takeaways
- A robust component library makes ideation and iteration faster. I didn’t need to create low-fidelity wireframes because our design system already contained components that I could reuse and edit across designs.
- Clear documentation and processes speed things up. I didn’t need to spend any extra time briefing our user research intern on how to recruit users or set up our testing documents because we have a standardized, defined process of doing so that doesn’t change for each study.
- There’s a lot that can still be learned without a full-scale research study. Taking comprehensive notes and recordings and sifting through these a few times to get insights brought many new ideas to the surface.
- Past user research should be accessible. It helps to have access to other research studies that have been done on similar user groups, as the insights that come from there can be used to quickly validate ideas at a brainstorming stage.
Many thanks to Charlotte Lee and Jason Chan for helping run this project.
Follow me for content about product design and language learning.
