Build on Outword

Most new work in Outword is a new way to play, a new card on Home, or a new moment around a round. Almost all of it can be built from parts that already exist. This page is the path from idea to shipped, in the order the work happens.

#Start from what exists

#Recipe: a new game mode

Trivia is the worked example of this recipe; see Trivia.

1. Name the race. One sentence: what is the player racing the clock for? ("Solve as many questions as you can in 2 minutes.") If it takes two sentences, it's two modes.
2. Compose the round. Eyebrow, HUD pills, anything the mode adds above the board, the slot with the word pill, the board, at most two outline actions. If the part above the board changes length, give it a fixed space (D-004).
3. Use the existing feedback. Neutral while tracing, green at the moment something scores, rose for a refusal, and a quiet response (or none) to a fumble. Don't add a new colour or a new kind of feedback for a new mode.
4. Score small. Numbers a player can add in their head; count in fives and threes. Write the rule down where the other scoring rules live.
5. Results. Standings first, then what happened per word or question, with words in lit tiles. Celebrate only a rare positive, and only after the round.
6. Entry and states. How it's reached (Play, or a Compete card), the countdown, waiting in a room, no connection, the last 10 seconds, the end.
7. Freeze the round. Nothing moves during play except feedback: no ambient motion, no confetti, no new banners.

#What earns a place in the system

Something moves from one screen into the system when it is:

• Useful: it solves a real need in a shipped screen, not a hypothetical one.
• Unique: nothing in the table above already does the job, even with a small change.
• Used: in about three places, or it's a global part (a button, a field), or a treatment that must be identical everywhere (an error, a destructive confirmation).
• Consistent: it follows the principles and the rules, in both modes, with reduced motion.

#Lifecycle

Nothing is deleted from under a screen that uses it. Old names keep working through an alias until they're unused; the legacy colour names are the current example.

#Definition of done

Before a UI change ships:

• Colours, sizes and motion come from tokens and existing values. No hex in components, no legacy names. The release check enforces this.
• It works on both grounds, and text passes AA contrast (4.5:1).
• Every control is at least 44px, has the focus ring, and has a reduced-motion version.
• Every state is designed: rest, pressed, disabled, loading, empty, error, no connection.
• Copy is plain: sentence case, verbs that say what happens, numbers before names.
• Only feedback moves during a live round.
• The docs are updated in the same change: the page (from its template), a decision record if a real choice was made, any screenshot it changed.
• It's been tried at 390×664 and 320×568, and the preview has been approved.

#Propose a change

For anything bigger than a fix, write this down first. It becomes the decision record if the change ships.

Problem        What's wrong or missing, for whom, and how we know
What exists    The closest existing part, and why it isn't enough
Proposal       What changes, with a mock
Options        At least two other ways, and why they lose
Evidence       What will be measured to know it worked
Cost           What it adds: tokens, sizes, states, audit numbers

#How the system keeps itself honest

Every release runs one check. It stops the release if the docs' generated files don't match the code, if the system's version doesn't match the game's, or if any system health number got worse than its ceiling. Improving a number lowers its ceiling, so it can't creep back.