Chapter 14 - key points

Most trees will need revisions after testing. If these are more than minor tweaks, they should be re-tested to confirm that they fix the observed problems.

Re-testing results in a better structure, shows that the organization is willing to try out ideas, and lets the project team “prove” that their final design is better than previous ones.

In general, we discard trees (or elements) that didn’t perform well, and pursue those that did, documenting our rationale as we go.

Testing alternative trees makes this iterative approach much more powerful.

When re-testing, we should also revise tasks that were not clear in the first round, or which needs rewording (or different correct answers) because of our tree changes.

We ideally want fresh participants for the follow-up test, but may have to settle for previous participants if our pool is small.

We’re “done” when our success rate is high (>70%) and there are no more useful revisions we can make to the tree.
But if time or budget run out before this point, we can console ourselves with the fact that some testing is better than none at all.