...

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.

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.

...

Ultimately, we need to turn our findings into solutions we can act on – changing terminology that is confusing, merging or splitting topics, discarding an idea that isn’t testing well, and so on.

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):

•  sssnapshot of marking up hardcopy

If we’re using a tree/task matrix (as described earlier in ~), we can add another column for solutions across trees, or another row at the bottom for solutions across tasks. We typically highlight these to make them easier to act on later:

...