Tree Testing · Guide

The Job-Shaped Task: writing task instructions for tree testing

By UXbeam, information architecture research since 2021 · Updated July 24, 2026

At UXbeam, we recommend writing every tree-test and usability-test task as one sentence, in a format we call the Job-Shaped Task.

We have found it a natural way to make a task clear. It tells participants what they are trying to accomplish without ever naming where to click, so your results reflect how people move through your structure, and the task stays light to read.

What a task instruction is

A tree-testing task is smaller than it looks. It is a single sentence, and every good one is built from the same few parts. Keep it to one sentence, write it in the second person, and cap it at three clauses. Every clause you add works against clarity: more to read and misread, more room to take the task in a direction you did not mean, and one more chance to lead the participant toward an answer. Short keeps it clear.

The reliable way to hit that shape is to describe the participant's goal, not your interfaceNN/gNielsen Norman GroupTurn User Goals into Task Scenarios for Usability TestingMarieke McCloskey · 2014 · nngroup.com. A goal-shaped task names a situation and a need; name the button instead and you have stopped testing navigation. Every rule below follows from that one choice.

The job-story format

The shape to reach for is a job story, a format Alan Klement introduced as an alternative to the user story: instead of "As a user, I want X," a job story reads "when [situation], I want to [motivation], so I can [expected outcome]." If your team already works in job stories, you know this shape, and a Job-Shaped Task is the same sentence with the participant in the "you" seat.

That template shows the most familiar order, but the clauses rearrange freely. Because situation, intent, and outcome are clause types, they slot in any order: "Now that you have moved, you want your parcels sent to the new address" leads with the situation, while "You want your parcels sent to the new address, now that you have moved" leads with the intent. Both are valid Job-Shaped Tasks.

There is a mechanical reason the shape works. A job story describes what a person is trying to get done rather than the feature that does it. So it cannot name a menu label, the wording that turns a findability test into a reading test. Good structure prevents the most common bias before you go looking for it. Where a leading word slips in anyway, spotting and rewriting leading tasks is its own method.

The job story makes a good shared anchor because it is already familiar to everyone around the table. At UXbeam, we refined it into a small taxonomy and a few rules, so that even people new to tree testing can jump in gracefully.

The three clauses: situation, intent, outcome

Those three are the whole taxonomy.

Use each type once. Two intent clauses put two goals in one task: the participant chases one, or splits between them, and the first click can no longer tell you which goal drove it. You have folded two questions into one, with a real chance one gets lost, because each participant will focus on whichever goal they noticed most. A second situation or outcome only pads. So if a task seems to need two goals, it should be two tasks.

Three clauses at the most. The ceiling is about cognitive effort: a task is read once, quickly, and held in limited working memory. Pile on clauses and participants do not keep them all in view; each person latches onto whichever clause is most salient to them. Different readers fix on different parts, so they end up answering different questions, and their first clicks scatter.

Read that scatter as an artifact of the task: the tree or navigation may be sound, but the overloaded task pulled the participants apart. One or two clauses, three at the most, keeps everyone answering the same question, so the scatter you do see is telling you something real about the structure.

Clauses that do not belong

Anything that is not a situation, intent, or outcome is padding, and sometimes bias. Two clause types do the most damage, and three more show up almost as often.

The question mark itself is not the problem. "Where would you find gift cards?" is a fine intent, just phrased as a question, as long as its words do not echo a label in your tree. What breaks a task is the bare trailing "where would you find this, that, or it," pointing back at a goal another clause already carried.

Three more clause types are subtler, and each fails for its own reason:

• Feature clauses name the solution: "Use the bulk editor to update them all." They assume the participant already knows the feature exists and point straight at it, so you measure recognition of a named tool, not whether people would find it.
• Hint clauses suggest the answer: "It is probably under your account settings." Even a soft hint moves the first click. A task should never carry a guess about where the answer lives.
• Backstory clauses pad the persona without changing the goal: "You are a busy parent of three who loves gardening, and one evening after work..." The extra reading buries the task, and as the three-clause limit explains, different readers latch onto different details.

Write one in three steps

1. Pick the clauses you need

   Run through situation, intent, and outcome. Keep the ones that carry the task, describe each as a goal rather than an actionGOV.UKGOV.UK Service ManualUsing moderated usability testingGovernment Digital Service · 2017 · gov.uk, and put them in whatever order reads naturally. Often just an intent, sometimes two.

2. Trim everything superfluous

   Step back and cut everything you can spare. Anything that is not a situation, intent, or outcome goes first: directions, trailing questions, feature names, hints, and backstory padding, each for the reason the section above gives. Then question the clauses that remain, and the words inside them. Every word you remove is one fewer chance to confuse or mislead, and because every participant reads the same task, each trim multiplies across your whole sample. Trimming is the key to task writing.

3. Check the wording against your tree

   Read the sentence against every label in your structure. Any word that repeats a label lets participants match text instead of navigating. Swap it for a neutral synonym.

Before and after

Each rewrite below drops a direction or a trailing question and replaces it with a situation and a goal.

Of course, do not swing into fiction. A task buried in a paragraph of backstory gets skimmed, and the detail that matters gets lost. One sentence of concrete situation is all you need!

Task-design checklist

• One sentence, and no more than three clauses.
• Only situation, intent, and outcome clauses. No directions or trailing questions.
• At most one clause of each type. No task carries two intents.
• No word that repeats a label in your tree. When one is unavoidable, choose it deliberately and read that task's results as label-assisted. (More on leading terms.)
• Concise enough that a participant reads it once and understands the goal.

The one-page cheat sheet

Here is the method on a single page, free to save or use in training and facilitation:

How UXbeam helps as you write

UXbeam builds two of these checks into task setup, so the review happens while you write rather than after your participants have already answered.

1It flags the dead question clause

When a task ends in a "where would you find this" or "where would you go for this" clause, UXbeam flags it and suggests removing it. The tree test already asks that question, so the clause repeats the test and can steer the answer. Cutting it leaves the situation and goal that belong.

2It checks wording against your tree

The same setup step compares each task against your tree's labels and flags words that repeat one, with suggested rewrites that avoid the tree's vocabulary. That is the leading-term check covered in full in the leading-tasks guide. Between the two, a task that names the interface rarely reaches launch by accident.

Both checks are optional, and we recommend leaving them on. They catch the two mistakes an occasional user is most likely to make (a leaked label, a dead trailing question), so those never skew a result, without anyone needing to hold the rules in their head first.

Frequently asked questions

References

• Alan Klement, "Replacing the User Story with the Job Story", Jobs to be Done, 2013.
• Marieke McCloskey, "Turn User Goals into Task Scenarios for Usability Testing", Nielsen Norman Group, 2014.
• Government Digital Service, "Using moderated usability testing", GOV.UK Service Manual, 2017.