| name | front-of-house |
| description | Use when writing, reviewing, planning, or implementing anything a person will see or use, including pages, screens, search, listings, forms, emails, errors, empty states, onboarding, copy, and frontend behaviour, even when the task is framed as backend, routing, taxonomy, schema, policy, data, testing, or infrastructure work. |
Front of House
Commission the human product, not the machinery. Whatever the brief makes most concrete will dominate the result. If the architecture is easier to picture than a successful session, turn the commission right-side up before proceeding.
Make vivid the person and context, the progress they seek, the useful result, the actual content and interaction they encounter, and how the experience should feel. Use representative real inputs and describe their desired visible outcomes. These are judgement cues, not required headings or a template.
Define success as what the person can understand, decide or do, and why it is useful. Internal states, artefacts and tests may prove the means; they are not the outcome. A passing test that rewards a screen nobody wants is a failing product test.
Detail routing, schemas, policies, agents and architecture only where truth, relevance, accessibility, performance or a binding constraint requires them. Preserve implementation latitude. Technical importance does not create public importance.
Expose an internal concept only when it helps the person understand, decide, recover or act. Otherwise keep normalisation, entity recognition, confidence, routing, agent activity, policy checks and debug detail backstage. Confident interpretation should feel obvious, not narrated.
Explanatory copy must earn its existence, not merely a less prominent placement. Keep marketing pages, dashboards and workflows focused on value, useful content and the next action. Omit facts that do not help with the current action or decision. When the product can enforce a constraint or recover quietly, let it. The existence of legal terms, privacy policy, provider behaviour, pilot status or an exception matrix does not justify repeating them in the product experience. Surface only the minimum information without which the person cannot act successfully or make a necessary decision.
Useful contextual explanation is good interface design. A compact unfamiliar control may reveal a brief user-language tooltip on hover and keyboard focus, with an accessible name. Essential meaning must remain discoverable without hover, including on touch devices. Explain the action or consequence, not the system's internal reasoning.
When a machinery-heavy brief reaches a visible surface, reconstruct the implied human commission and implement that. If its letter conflicts with the useful experience, prefer the experience and report the conflict. This is judgement, not a workflow: no mandatory phases, sections, gates or rubric.
