5 exercises — signposting language for RFCs, postmortems, and design docs: backward references, forward references, summaries, and section transitions.
0 / 5 completed
1 / 5
A technical design document has three sections: Overview, Implementation Details, and Trade-offs. Which signposting sentence best introduces the Trade-offs section?
Option D is the strongest. It performs three signposting functions simultaneously: (1) it references earlier sections ("as outlined in… detailed in…"), (2) it signals what comes next ("several trade-offs"), and (3) it frames the purpose ("before committing to this approach"). This is the highest-level signposting — connecting the document structure explicitly. Option B is a plain forward reference — acceptable but minimal. Option C is verbose and informal ("this one is no different"). Option A is too casual and direct for a design document. Key signposting functions: backward reference (as discussed above), forward reference (the following section), summary signal (in summary / to summarise), scope declaration (this section covers).
2 / 5
A postmortem begins with a timeline and then moves to root cause analysis. Which sentence best signals the transition?
Option C is the most effective signposting sentence for a formal postmortem. It uses a participial phrase ("Having established…") to acknowledge the completed section, then a forward reference ("the following section") to signal the transition, and names the purpose precisely ("analyses the underlying root cause"). Option A is a bare heading — functional but not signposting; it provides no link between sections. Option B is abrupt and sounds like spoken notes. Option D is too casual ("dig into") for a written postmortem. A well-signposted postmortem helps readers understand the document structure without relying solely on headings. Think of signposting sentences as the "joints" of a document.
3 / 5
An RFC ends its Motivation section and begins the Proposal section. Which signposting phrase is most appropriate?
Option B is the best. "Given the constraints identified above" is a backward reference that ties the proposal to the motivation — the reader understands why the proposal follows. "This proposal describes a solution that addresses…" signals what the section contains and frames it as a solution to a problem. This is the essential pattern for proposal documents: backward reference (problem) → forward reference (solution). Option A is too casual for an RFC. Option C is mechanical — it names the section but builds no logical connection. Option D ("Moving on") is a spoken transition marker, inappropriate in formal writing. RFC and ADR signposting tip: always connect the proposal to the motivation with a backward reference.
4 / 5
A technical guide has covered three configuration steps. Which sentence best summarises before concluding?
Option B is the best. A good summary sentence does three things: (1) signals the summary explicitly ("In summary"), (2) restates the completed actions with specific detail ("configured the database connection, set the environment variables, enabled TLS"), and (3) states the achieved state or what comes next ("The service is now ready to deploy"). This gives the reader a mental checklist and a clear handoff to the next phase. Option A is too casual. Option C is vague ("steps were followed" names nothing). Option D is a prerequisite warning, not a summary. Signposting at section ends: In summary / To summarise / Having completed these steps + specific restatement + achieved state.
5 / 5
An architecture document refers back to a constraint from a previous section. Which version uses backward signposting most effectively?
Option C is the strongest. It names the source section explicitly ("as noted in the Requirements section"), restates the constraint with its specific value ("sub-100ms latency"), labels it precisely ("hard constraint"), and declares the consequence for the current section ("The following design choices are made specifically to satisfy this requirement"). This is the full backward-reference pattern: as [stated/noted/described] in [section/document], [specific detail], [consequence for current section]. Option A uses "as mentioned" without naming where or what — too vague. Option B is too informal ("we talked about"). Option D is casual and imprecise. Strong backward references build logical credibility: they show the reader that each decision is grounded in an established requirement.