Every resume has a chapter its owner would rather skip: the layoff, the caregiving stretch, the business that did not make it. In interviews that chapter usually gets rushed past with an apology, as if the months counted for nothing.

Building a peer community for people in that stretch surfaced the same pattern in product form. New members arrived apologetic by default. Profiles opened with explanations. First posts spent more words justifying the gap than describing what the person actually did, learned, or handled during it. The design problem was not motivation. It was framing: the tools people are given for talking about work only have a success-story shape, so a hard stretch has nowhere honest to go.

Designing for the chapter, not around it

Three choices shaped this part of the build.

First, prompts ask what was handled, not what was achieved. "What did those months actually involve?" gets a concrete answer — caring for a parent, retraining, freelancing in fragments, holding a household together on a shrinking budget — where "describe your experience" gets a blank stare.

Second, the gap is presented as one chapter in sequence, not as an interruption. Timelines in the community show before, during, and after in the same format, so the stretch reads as part of a working life rather than a hole in it.

Third, peers come before advice. A person rehearsing how to explain a gap gets more from three people who explained theirs last month than from a generic tips article, because the examples are specific and recent and visibly survived.

What worked

Specific prompts beat open text boxes by a wide margin. When the first version left the story field empty and optional, most people skipped it or wrote a single apologetic sentence. Replacing it with two short, concrete questions — what the stretch involved, and what it changed about how the person works — produced longer, calmer accounts that members actually reused in applications and interviews.

Sequencing helped more than tone. Early copy tried to be encouraging, and it read as hollow. What changed behaviour was structural: putting the gap in the same visual format as every other chapter. No special styling, no warning colour, no separate "explain your gap" section. Treated as ordinary, it started to read as ordinary.

Peer examples compounded. Each member who posted a plain, unapologetic account made the next one easier to write. The tenth story in a thread is almost always steadier than the first, not because anyone coached it, but because the norm is visible.

What broke, or nearly did

The first template sounded like a form from a benefits office. Fields labelled "reason for gap" and "duration of unemployment" produced defensive, minimal answers — the exact apology reflex the design was meant to undo. The labels were the bug. Renaming the fields to ask about activity instead of justification changed the answers more than any other single edit.

A "skills gained" checklist broke next. It was meant to help people name what they learned, but a tick-box list flattened real stretches into buzzwords, and members disliked how it read back to them. It was removed and replaced with free text under a single prompt. Fewer completions, better text — a trade worth making, and a reminder that completion rate is not the only metric that matters.

The hardest problem is still only partly solved: rehearsal versus exposure. Practising a gap story among peers who understand it is not the same as telling it to a sceptical interviewer, and the community cannot simulate that pressure honestly. The current approach is explicit about the limit — peer feedback checks clarity and specifics, not interview performance — rather than pretending the gap between the two does not exist.

Lessons for builders

Audit your labels before your copy. A field name is an instruction about what kind of answer is expected. If the label asks for a justification, the answer will be defensive no matter how warm the surrounding text is.

Make the hard case structurally ordinary. Special sections, special colours, and special flows all announce that something is wrong. Rendering the difficult case in the same format as every other case does more than reassurance does.

Let norms do the encouraging. Visible examples from peers set the tone more credibly than any onboarding copy. Design for the tenth post in a thread, not just the first.

Name the limit of the rehearsal space. A supportive environment is good at clarity and bad at pressure. Saying so plainly keeps trust; overselling the preparation loses it when the real interview arrives.

The project behind these lessons is WUUUH, a peer community for rebuilding after a layoff, where a gap becomes one chapter in a longer story instead of the end of one.