As all research you conduct you need to make sure you do something with what you found. That means sharing what you discovered with key team members. Not only do you want to have something to share with the people you're collaborating with, it will provide a record for what you are building and testing. You never know if you want to revisit parts of it later.
Anyalyze your data
When analyzing your data you want to consider things like severity and frequency. Severity refers to how serious an issue is to a user. For instance, is it something that is annoying, but still works, or is it a glaring issue that multiple users struggled with? In the case of the later, that issue should be given priority in terms of what happens next. Additionally, what implications do these issues have on other aspects of the site or product? Usability.gov recommends reporting results based on severity classified as critical, serious, or minor.
Frequency looks at how often something happens. Users are looking for tools to make their lives easier. If they're continually having to find an alternative way to do something to make your product function for their needs, they may be likely to abandon it. Lots of little things can add up, so frequency is something to keep in mind, no matter how minor the issue may seem at first glance.
Csaba Házi reimagined Peter Morville's honeycomb of User Experience we explored in chapter 1 as a "UX staircase" [note: it is missing 'value']. Your analysis should also reflect on each of these elements of UX as you consider next steps.
Share discoveries with your team
Usability tests are something that you should be conducting regularly. Because of this, it's also something you want to be able to do quickly and efficiently. Putting together your key findings will not be as involved as putting together a formal presentation. The biggest challenge is being clear and succinct.
Sometimes a simple email with bullet points can be the most effective way to communicate what you learned in usability tests. You also include your annotated screenshots, or can link to the highlights video reel that you compiled (you need to learn to do this quickly, as it should not be something that takes up a lot of time). It's always interesting to share discoveries with the rest of the team. Another option is to create a poster (think of it as an editorial page from a magazine) to hang around the office, or create a monthly newsletter to share what the research team learned. You can include quotes, charts, and other interesting insights you uncovered. It's a great way to help everyone you work with build empathy for the people you're designing for!
In the case of meetings, attendees do not need to see or hear a play by play of every person you talked to. You should create an agenda and focus on the key points or take aways, show video footage if necessary, and ask the team any questions you need answered in order to keep moving the project forward.
Don't forget to keep the tech team or developer in the loop. Developers tend to respond well to video (if they haven't observed the test for themselves) where they can see users interacting with the product. A few responses you may expect to hear from developers may include:
I wish I would have seen this earlier, it's very complicated to change now.
We're not going to be able to implement X with this timeline, but I can propose Y instead.
Did you consider?
Oh sure, no problem, that's an easy fix!
Remember, you want to make usability testing a regular part of your product cycle. Involve as many people outside of the design and research team as you can for observation. Tests may be once a week, or once a month, but build in the time to do it! (This is how you help keep users at the center of USER experience design.) Also, every time you implement new changes you should plan to test again. Never assume that because the engineers built what you asked, that users will find it as valuable as they thought they would...
Your job as a UX designer is never done. 😉
