The real question, though, is whether you can identify with your users in this regard. How complex is your website, or your app, or your software? Does your system simply add to that information? Are you part of the problem? Or have you made an effort to be part of the solution?
Now, as usability engineers, we have no shortage of opportunities to help out our company’s users in this regard. We also, however, need to remember our own users – the project teams we run tests for. In particular, there are a number of things we can do to make our primary deliverable to them – our reports – more effective.
Our main goal here should be to take the fire hose of information that is the result of a usability test and turn it into something more like a tea cup’s worth. Now, the first thing to realize about this is that it is not easy. It can be very tempting to simply refashion that fire hose worth of stuff. It takes a lot of work to figure out what the flood of information actually means and boil it down to something a lot more consumable.
One thing I’ve found very useful is something an art director at a former employer shared once in a presentation about how to create better presentations. I forget the exact numbers, but it was something along the lines of 10-20-30 – meaning 10 pages, 20 words per page, and 30-pt font. I do pretty good with the last two, but found that I did have to double that first one. That said, when I subtract all the titles pages, appendices, and background info, it actually does come pretty close to the 10.
Here are some other things you can do to make your reports more easily processed:
- Include an executive summary
- Separate out methodological stuff and boil it down as much as you can (other than other usability engineers, very few people seem to care)
- For results, try to include only one idea per slide
- Use a simple, distinct, consistent layout – make it easy for readers to identify your finding, evidence (quotes, pix), and solution
Whatever you do, just be sure you can never be accused of do what I say, not what I do.
Scott Adams, creator of Dilbert, always had a particular appreciation for usability problems