Use cases

Product requirements documents, styled for reviewers who decide

A PRD gets read by people deciding whether to build something. Its requirements table, user stories and acceptance checklist have to be easy to scan as well as easy to write.

Write it flat, let the layout carry the hierarchy

A PRD written in Markdown stays flat: a heading for each section, a bulleted list for goals and non-goals, a table for requirements. Nobody indents by hand or fights a word processor's outline view. The theme turns that flat structure into the visual hierarchy a reviewer expects: heading weight and rule lines do the work manual formatting used to. The document is written once, not reformatted for the meeting where it gets approved.

The non-goals list matters as much as the goals list to a reviewer deciding scope. A plain bulleted list under its own heading keeps the two from blurring together the way a single paragraph of prose can.

Numbered requirement IDs make review traceable

Give each row of the requirements table an ID such as R1, R2, R3 in a csv fence with an ID, Requirement and Priority column. A reviewer can then reference "R4" in a comment instead of quoting the whole requirement. A later revision of the document can add or remove rows without renumbering the ones untouched.

A table also lets a reviewer scan one column at a time in a way a bulleted list does not. Every "Must" priority groups visually even though the rows are not sorted. Every ID is present and accounted for, and no requirement is buried inside a paragraph where it is easy to skim past. That is the difference a PRD needs, since the reader's job is to approve or reject scope, not to read for pleasure.

User stories as numbered items, acceptance criteria as checkboxes

• Write user stories as a numbered list: each one is a discrete scenario a reader can refer to as "story 2" without restating it.
• Write acceptance criteria as a task list, with - [ ] for an item not yet verified and - [x] for one that is.
• The task list renders with real, disabled checkboxes, so a partly verified feature shows which criteria still need testing at a glance.
• Keep one acceptance criterion per line: a line that bundles two conditions cannot be marked half-done.

Swiss for a decisive read, Slate if the document goes into a wiki

The example above uses Swiss: uppercase headings with letter spacing, hard black rules and a solid black table header, set in heavy-weight Archivo. The look reads as decided rather than open for debate. It suits a spec with numbered sections a team is expected to act on, not one still being drafted.

If the PRD is going to sit inside a product wiki alongside other documents, Slate is the better fit. Plain Inter, cool greys and blue links keep it neutral. A tighter 16px base than the bolder themes lets it sit next to a dozen other pages without standing out.

Two ways to hand it off

For a sign-off meeting, open the document in the editor and use "Print or save as PDF" from the export menu. It opens the browser's print dialog, and choosing "Save as PDF" there gives reviewers a fixed page they can annotate or file alongside the decision.

For a document that lives inside a wiki, use "Copy styled HTML" and paste directly into the page. The styles are inlined, so the requirements table and the acceptance checklist keep their look. List markers on the numbered user stories may not survive every editor. "Download .html" is the alternative when the destination is a file rather than a paste: one page with the theme's styling baked in, fonts and all.