How to Turn a Familiar Work Task Into a Checklist Someone Else Can Use

You can do the task without thinking—so why do we get stuck when we try to explain it?

A coworker sits beside you and asks, “Can you show me how you do this?”

You start with confidence.

“Open this file. Check this number. Then update this part.”

A few steps later, you stop.

“Actually, if these two numbers do not match, I check something else first.”

Then another check comes back to you only when you reach it.

Does that scene sound familiar?

The problem is not that your skill is missing. Part of it has become tacit knowledge: know-how you use without having to say each part to yourself.

That is why a blank page can be harder than the real task. Your hands and eyes meet the clues in the normal order, but a blank document does not give you those clues.

So let’s not begin by trying to remember every step. Let’s rebuild one real run of the work, make the hidden choices visible, and then see whether another person can use the result.

The short answer

• Let’s give the task clear edges: what starts it, what it needs and what counts as finished.
• Let’s turn each important “it depends” into a visible decision, exception or handoff.
• Let’s let another person try the draft so their pauses show us what is still only in your head.

1. Give the task clear edges before writing every step

When you know a task well, your explanation may begin with the first action you remember.

“Open the tracker.”

But something usually happened before that action.

Perhaps a customer sent a request. A report arrived. A coworker completed the previous stage. A weekly deadline was reached.

That event is the trigger: the thing that tells you this task should begin.

Next, list the inputs. These are the things that must be available before useful work can start, such as a file, message, account, figure or answer from another person.

Then define the finish condition. This is the point where another person can tell that the task is truly complete.

Imagine that the recurring task is preparing a weekly operations update. A first outline could look like this:

Trigger: The latest source information has arrived.

Inputs: The current tracker, the previous update and any open issues.

Normal path:

• Check that the expected information is present.
• Compare it with the previous update.
• Add the new information.
• Check unresolved items.
• Send the completed update to the agreed place.

Finish: The update has been sent, and every unresolved item has a clear next owner.

Now the task has boundaries. A new person can see when to start, what they need and what “done” means.

For safety-related workplace procedures, the UK Health and Safety Executive recommends walking and talking through the real task with users when developing procedures. It also says the amount of detail should fit the task and the person using the procedure. (HSE)

That guidance is written for safety procedures, not ordinary office checklists. The useful lesson here is narrower: watching the real work can reveal steps that memory alone misses.

As you follow one real example, you may notice that you open a second screen, check an older message or wait for another person before continuing. Those small actions are easier to capture when they are happening in front of you.

2. Turn “it depends” into decisions, exceptions and handoffs

A straight list of steps can still fail if the real work sometimes changes direction.

This is often where experienced people say, “It depends.”

Instead of removing that phrase, ask one more question:

What does it depend on?

Suppose you say:

“The figures normally match, but if they do not, I check the source before I continue.”

That sentence contains a decision you can put on the page:

Decision point: Do the figures match the source?

• Yes: Continue with the normal path.
• No: Stop and check the source before updating the report.

An exception is a case where the normal path no longer fits.

A handoff is the point where the work, information or decision needs to move to another person.

For example:

Exception: If the issue does not match the normal examples, do not guess.

Handoff: Send the issue and the relevant information to the person responsible for the next decision.

This is where a simple checklist starts to show the value inside your experience. The important skill may not be that you can complete five actions in order. It may be that you notice when the normal path no longer fits the case.

A checklist does not need to pretend that every judgment can become a rule. The same HSE guidance says procedures should support competence rather than replace it. (HSE)

So a useful guide can say this clearly:

Judgment point: If the case does not match the normal examples below, pause and ask the task owner before continuing.

That line is more honest than inventing a rule that works only in easy cases. Your “it depends” has become a sign that tells the next person when the normal path ends.

3. Let another person reveal what the draft still assumes

When you reread your own checklist, every line may look clear.

You already know what each line means.

That is why the next useful step is to let another person follow the draft on a realistic example that is safe for them to use.

Imagine the checklist says:

Review unusual items before sending.

Your coworker stops.

“What counts as unusual?”

You realise that you normally look for three kinds of mismatch. You have done it so often that you forgot those checks were separate knowledge.

Now you can add them.

Or perhaps the guide says:

Pass it on if necessary.

Your coworker asks:

“When is it necessary, and who do I send it to?”

Again, the pause shows where the document is still borrowing knowledge from your head.

Each pause can usually lead to one of three repairs:

• add a repeatable check;
• add a decision, exception or handoff;
• mark the point where judgment or help from another person is required.

You do not need to add a paragraph for every rare possibility. The goal is to remove avoidable guessing while keeping the guide short enough to use.

If another person can recognise when the task starts, follow the normal path, see the main branches and know when to stop or ask for help, your first version is already useful.

The test also gives you something the original task may have hidden from you. Work that felt “automatic” can turn out to contain careful checking, judgment, exception handling and coordination.

Writing the checklist does not create that value. It makes the value you were already using easier to see and pass on.

A useful checklist has a path, branches and a reality check

The three parts work in order.

The trigger, inputs and finish condition give the task its boundaries. The decisions, exceptions and handoffs show where the normal path changes. Another person then tests whether those parts are visible outside your own memory.

If you test a vague list, you only learn that the list is vague. If you try to document every unusual case before you have written the normal path, the guide can become too large to use.

Start with one real run. Make the normal path visible. Add the branches you actually meet. Then let another person expose the places where the guide still asks them to guess.

The aim is not to turn experience into hundreds of boxes. It is to make the repeatable parts visible and mark the places where judgment still belongs to a person.

Move closer to the person you want to become

• Let’s choose one recurring task and follow one real example from the moment it begins to the moment it is truly finished.
• Let’s circle each “it depends,” “usually,” “unless” and “sometimes” we notice, because one may hide an important decision.
• Let’s invite one other person to try the draft and use each point of confusion to make the guide easier to follow.