Use this when designing an internal tool or operational app where the safest path is to prove the workflow and UI before locking in backend structure.
Use this when designing an internal tool or operational app where the safest path is to prove the workflow and UI before locking in backend structure.
Work in this order:
Do not jump straight to database tables, service layers, or event pipelines unless the user explicitly wants backend-first design.
Create or update these artifacts as needed:
wireframe-planmock-data-planapi-contract-setUse the toolkit contracts as the durable output layer:
contracts/wireframe-plan/CONTRACT.mdcontracts/mock-data-plan/CONTRACT.mdcontracts/api-contract-set/CONTRACT.mdUse templates/outside-in/ only as supporting design references when the
contract template needs more detailed domain-specific structure.
First determine:
Primary skill:
workflow-discoveryTurn jobs into:
Primary skill:
screen-flow-designCreate:
Then validate that the UI flow can operate against those mocks.
Primary skills:
mock-data-designmock-api-contractsOnce the mocked slice makes sense, derive:
Primary skill:
backend-derivationOnly after the validated slice exists, define:
Primary skill:
infra-derivation| Don't | Do Instead |
|---|---|
| Start from database tables | Start from user jobs and screens |
| Model the entire backend first | Prove one workflow slice first |
| Use unrealistic mock data | Use realistic records and edge cases |
| Design internal services before UI actions are clear | Let screen actions drive contract design |
| Over-spec infrastructure on day one | Derive infra after workflows and contracts stabilize |