Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
What to Do with the Data
Once you have all this valuable insight directly from people in your target audience, don’t use it verbatim, but think of it as a guiding light when you get back to your desk to start working on a design document (which we’ll talk about in the next article).
Look for persistent trends. If nine out of ten people are performing the same icky task five days a week, that task is a good candidate for a product requirement. If particular documents everyone uses are buried on a network drive on the dark side of Jupiter, or it takes twelve steps to get to them in the current version of your site, redesign the information flow to make it much simpler for users to pick up the scent and get there easily.
What you shouldn’t do, however, is exactly what users say to do. If a card-sorting exercise results in a stack of cards titled Stuff About Acme, rename that label something like About Acme, because trigger words such as About help users find what they need when faced with a page full of links and images. In the case of software, whether web-based or not, listening to users too closely and bending to their every whim often results in complicated, frustrating products that place everyday features right next to obscure features that you must be a rocket surgeon to use. Sometimes, the best thing you can do is ignore users and design something that makes more sense. Use discretion, and don’t ignore users completely unless you can prove your way is better.
Figuring out what to do with all this data isn’t difficult. Just apply common sense to spot what’s essential for your product versus what can be left in the trash or deferred to a future version, and start making a list. When your list is done, refine it until you’re absolutely sure that only the most essential items are still on it. Keep everything else on a separate "nice to have" list, and see whether any of those items still matter when the product is complete. If so, work them into the next version. Most likely, if you did your job right the first time around, the "nice to have" items won’t be necessary at all.
Finally, start writing a product requirements document (PRD), which you can learn all about in this article from Cooper. The PRD describes the target user and the features the product will contain.
One last bit of advice here: Always keep in mind the technical side of things as you’re writing this document, unless of course you want to lose the respect of your programming team by promising scratch-and-sniff dialog boxes. How the document is formatted isn’t all that important, but keep it as short and concise as possible so other people might actually read it, and avoid saying things that are simply not possible.