35 lines
1.2 KiB
Markdown
35 lines
1.2 KiB
Markdown
|
|
# Design
|
||
|
|
|
||
|
|
```
|
||
|
|
Status: Current
|
||
|
|
Owner: <who maintains this>
|
||
|
|
Last reviewed: <YYYY-MM-DD>
|
||
|
|
Governs: docs/design/**
|
||
|
|
Review trigger: Any new user-facing surface, or a change to the product's tone
|
||
|
|
```
|
||
|
|
|
||
|
|
## What belongs here
|
||
|
|
|
||
|
|
What it should feel like, and the decisions behind that:
|
||
|
|
|
||
|
|
- **Product decisions** — what the user can do, in what order, and what happens
|
||
|
|
when they get it wrong. The error states are design, not an afterthought.
|
||
|
|
- **UI plans** — screens, states, and what each one is for. Include the empty
|
||
|
|
state and the loading state; they are the two most people see first and the
|
||
|
|
two most often left undesigned.
|
||
|
|
- **Copy** — the actual words. Interface text is a design surface, and writing
|
||
|
|
it late means writing it badly.
|
||
|
|
- **Tone** — how this product talks. One paragraph is enough, and it settles a
|
||
|
|
hundred small arguments.
|
||
|
|
|
||
|
|
## What does not belong here
|
||
|
|
|
||
|
|
- How it is built — that is `docs/architecture/`
|
||
|
|
- Scope and audience — that is `docs/planning/PROJECT_PLAN.md`
|
||
|
|
|
||
|
|
## Include the rejected version
|
||
|
|
|
||
|
|
For any decision that was genuinely close, record what was not chosen and why.
|
||
|
|
Without it, the same option gets proposed every few months and re-argued from
|
||
|
|
nothing.
|