Don’t Be a User Research Robot: 2 Tips for Better Research Deliverables
Do you know what to do with this sort of user research data?
Inviting Team Members: 7 out of 9 users failed the task with a median attempt time of 15 seconds before asking for help or expressing they did not know how.
Sending a Message: 8 out of 9 users succeeded the task with a median completion time of 5 seconds.
Functionality: 66.66% of users felt that the product did not meet basic expectations.
Usability: Out of 9 user tests conducted, the SUS Scale question, “I found the system unnecessarily complex,” received a median score of 4.25 (Agree).
Most user research reports and presentations usually do provide this data, but leave it at that.
While researchers should report data objectively, that doesn’t mean they can’t provide recommendations that enable a team to move forward. It’s dated for researchers to remain on the sideline delivering reports and making presentations as their deliverable.
What really matters is if research has impact for a decision that a team has to make. What really matters is if you can provide recommendations and prioritized items that the team should focus on.
One of my first design research projects in my career was a comprehensive user study on onboarding. I interviewed over 15 users across various industry verticals and expertise levels. I setup a meeting between product managers, engineers, and designers. It was a very expensive meeting. I learned later that the new onboarding experience that was being released to customers barely incorporated any of the insights I had learned because the team had no time to go through my findings and apply it to the product development sprints. What a disaster.
What should you do instead?
Tip #1: Give recommendations
Do you think your team is really going to review a 50+ page slide deck and hours worth of compiled video and audio recordings?
The researchers I’ve loved working with take all the data and help show how the learnings can be applied to either a product spec or a design comp. While researchers may not always have the same level of technical know-how of a product, it’s important that we, as researchers, can communicate how a product manager, engineer, or a designer can make their spec, functionality, or design better based on what we found out.
We find out and tell them the biggest problem they should focus on. We are translators of data and interviews into actionable insights.
Instead of:
Inviting Team Members: 7 out of 9 users failed the task with a median attempt time of 15 seconds before asking for help or expressing they did not know how.
Try:
Most of the users I talked to (all except 2) had difficulty inviting a team member with the current design. Since this is a major way of getting users into the app, I recommend that we re-visit the design to include a more obvious call to action or interaction. Users tried to click around their accounts and settings area before asking for help so we could also look at points of entrance for this feature.
Tip #2: Give recommendations. And be personal, like a friend.
Our teammates don’t gain much when we copy and paste what we just heard from our user interviews or log data. The best way for us to get through to them is by starting a conversation.
Imagine that you were trying to suggest something or give a recommendation to a friend. Check your tone and voice.
Instead of:
Functionality: 66.66% of users felt that the product did not meet basic expectations.
Usability: Out of 9 user tests conducted, the SUS Scale question, “I found the system unnecessarily complex,” received a median score of 4.25 (Agree).
Try:
2/3rds of the users I talked to felt that the current iteration still doesn’t do what they expect on a basic level for a messaging app. Most of them also felt that the flow from app start to sending a message was really complex. For the product team, I recommend we take a look at what we have in the product spec first prior to further user testing as people felt that what we tested was too basic to meet their needs right now. For the design team, I recommend we take look at the task flows as people felt that the app was really complex for a simple messaging app.
The difference is that we can provide all the data we want in the world to show the numbers and the due diligence we went through, but the way we communicate it to our peers really matters. We can do both: report the results AND be good storytellers of data.
Also, by being personal and caring about your coworkers, you can include them in the research process. This makes the insights you bring back more meaningful to the work they are doing. If you take interest in what your coworkers are trying to do, you can help them question their own assumptions and help them do great work. If you’re interested in learning more about getting personal with people for research, check out Tomer Sharon’s book, It’s Our Research.
Originally published at www.hichuck.com on December 8, 2015.
