Once we’ve recorded our findings, it’s time to turn them into actions. These are usually revisions that we need to make to our site tree, but sometimes they go further - checking terminology with the Legal department, filling content gaps we've discovered, checking technical limitations with developers, and so on.

Obvious or not?

Some findings are simple (e.g. “users don’t understand the term Contingency planning”) and their solution appears obvious (“rename it Planning for emergencies”), so it’s pretty safe in these cases to just get on with it.

But be careful of knee-jerk solutions. Earlier we warned against jumping to solutions too soon, and this is good advice for any kind of user testing. It’s best to do a first pass to write down all our findings before we start solving them, because we often need a wider view to understand what is really going on – what the real causes of the problems are.

We’ll often find that we’ve jotted down solutions for seemingly easy findings, only to encounter some later tasks that either contradict or modify the earlier solutions. It’s best to think of all solutions as tentative until we’ve gone at least once through all the findings.

Recording actions

If we’re marking up hardcopy, it’s easy to jot down our solutions beside the related findings, and highlight them for later action (e.g. by circling or starring them).

If we’re using a tree/task matrix (as described earlier in Recording findings), we can add another column for solutions across trees, or another row at the bottom for solutions across tasks:

Open

Similarly, if we’re adding findings and solutions to our tree spreadsheets, another column does the trick for specific items, and more rows at the bottom can handle the more general actions we want to take.

Next: Summing up the basics