Bible¶
The bible is the story of each system in Tomoda — one page per feature, written in the voice of a product manager explaining the feature to a new designer. It tells you why the system exists, what experience it tries to create, and what we're optimising for when we make tradeoffs.
It is not a spec. For rules, states, and invariants, see the matching page in Domains.
How to read a bible page¶
Every bible page follows the same skeleton:
- One-line purpose — what this system is, in a sentence.
- The story — what it is, why it exists, the experience we're after. 2 to 4 paragraphs, narrative voice.
- What we're optimising for — bullets. Tradeoffs we accept and tradeoffs we reject.
- See also — links to the matching domain spec, the backend service doc, and (eventually) the UX page.
If a bible page is read out loud to a new designer, they should come away with the gut feeling of the feature, not a list of states.
Index¶
| Page | What story it tells |
|---|---|
| Brand | The voice, the principles, the way Tomoda looks and sounds |
| Identity | The story of accounts — why we built sign-up the way we did |
| Events | The story of plans — how spontaneous meetups become first-class objects |
| Friends | The story of the social graph — why it's small, mutual, and quiet |
| Discovery | The story of the map — how we let users explore without doom-scrolling |
| Moments | The story of ephemeral photos pinned to places |
| Chat | The story of messaging — events, DMs, group rooms, disappearing |
| Presence | The story of "online" and "actively sharing live location" |
| Payments | The story of monetisation — what we sell, what we won't sell |
| Locations | The story of "place" as a first-class primitive |
| Game Rules | The story of how real-world activity becomes collectible memory |
| Stamps | The story of place-anchored curated artifacts |
| Challenges | The story of goals that fire when you actually live them |
| Tomoda Collection | The story of the user's earned curios + stamps |
When to update a bible page¶
Update the bible when the story of a feature changes — when we'd describe it differently to a new hire than we did six months ago. Don't churn the bible for spec changes; those go in the matching domain page.
A good rule of thumb: if you find yourself adding a list of states or a table of rules to a bible page, you're in the wrong layer — move it to the domain.