Write a tutorial with a first success readers can check

Choose one first success

A tutorial gives someone a controlled opportunity to do unfamiliar work. For a creator explaining analytics, a useful first success is a small claim card whose numbers can be traced to a supplied practice table. “Learn everything about LinkedIn reporting” is not a finish line. State the starting knowledge, the output and what the exercise deliberately leaves for later.

Diátaxis distinguishes a learning exercise from directions for someone already doing a job. We use that distinction here; the adjacent explanation guide develops a concept, and the workshop guide plans a facilitated event. This guide authors the repeatable self-study route itself. A well-formed exercise still needs real learner testing before anyone can claim that it teaches successfully.

Supply the whole practice state

Use fictional inputs that require no account connection or publication. Our three practice rows are P01:100 impressions and 5 response events; P02:200 and 10; P03:0 and 0. Every row describes an observation at 24 hours after its fictional post. These are invented exercise values, not a LinkedIn export or a claim about an actual creator.

Put the table and a blank claim card beside the instructions. Define a response event using the exercise label rather than silently substituting people, leads or customers. Keep the fixed observation age, declared units and fictional status on the card. Someone starting from another input needs a different check; the supplied answer does not validate their private data.

Write the complete route and expected results

Complete practice route: copy the three IDs into the card and check that each appears once. Add the impression column:100+200+0=300. Add the event column:5+10+0=15. Divide 15 by 300 and multiply by 100: the exercise event ratio is 5%. After each action, show that specific expected result so a learner can locate the first disagreement.

Finished model card: “Fictional practice:3 post-observation records, each at 24 hours. The entered totals are 15 response events and 300 impressions, giving a5% event ratio. This is not a count of different people or customers.” Ask the learner to identify which row contains an observed zero and why zero differs from missing. The worked answer is P03; a blank would need a separate availability decision.

Rehearse three departures from the expected path

T1 — Clean fictional copy: all three supplied rows and units match. The learner can reproduce 300,15 and 5%, then write the bounded card. This is a correct response to the fixture, not an observed learner result or proof that real reporting works this way.

T2 — A draft changes response events to customers. Return to the unit field and repair the card; correct arithmetic does not preserve meaning by itself. T3 — P02 impressions are blank in the learner’s copy. Stop the supplied total, compare the copy with the source and restore only the documented practice input. Do not replace an unavailable real measurement with 200 or zero.

Check the route from an empty copy

Start the rehearsal from the exact distributed files, not the author’s populated worksheet. Check prerequisites, order, expected output, recovery and a clear end. Google’s procedure guidance supports explicit context and readable ordered actions; its house style is guidance, not a mandatory template. Keep an explanation link available without making every step a lecture.

Describe relevant visual information in text, use descriptive headings and give a keyboard-usable reading path. A screenshot of a completed card cannot replace the editable practice inputs. Record which steps you actually rehearsed and what remained untested. An automated fixture check establishes arithmetic and file identity, not comprehension, accessibility for every reader or independent review.

Keep the lesson separate from evidence of learning

The packet includes the full route, all three rows, model card and three fault cases in both languages, plus a blank authoring record. Keep learner goal, prerequisites, exact inputs, actions/results, recovery, end state and maintenance version together. A changed input or interface can invalidate a later step even when its prose is unchanged.

Sources were read on 1 November 2026 in their declared documentation scope. All T-cases are constructed. No person took this tutorial as part of the reader pilot, no real account was connected and no post was published. Use genuine voluntary observations to improve it later; never turn a passing local checker into a learner-completion claim.

1. Choose one observable first success.
2. Supply a safe complete starting state.
3. Pair each action with its expected result.
4. Write recovery for the first likely disagreements.
5. Rehearse from an empty copy and record untested learning outcomes.