Mockups are most valuable when they are part of a decision-making process. A mockup by itself is just a picture. A mockup used in review is a proposal that the team can accept, reject, or refine.
When to use mockups in review
Use mockups when you need visual consensus before implementation starts. This is typically during the design phase of a feature workflow, after requirements are clear but before code is written.
Good moments for mockup review:
- You have two layout options and need the team to pick one
- A new feature has UI implications that are hard to describe in words
- You want to validate an interaction pattern with stakeholders
The review flow
- Open Mockups (Mod+5) and create the mockups you want to compare
- Ask kui to generate variants — two or three approaches to the same problem
- Open the review modal. Navigate between variants with the arrow buttons
- Share the mockups with your team. They can view them in the preview pane and add comments in the chat pane
- Select the winning variant and click Submit. Add a comment explaining the choice
- kui links the approved mockup to the PRD so downstream agents can reference it
Pairing with documents
If the design decision has trade-offs, write an ADR in Docs (Mod+4) alongside the mockup. The mockup shows the visual outcome. The ADR explains why it was chosen — what alternatives were considered and why they were rejected.
This pairing is powerful. Six months later, when someone asks why the settings page uses a sidebar instead of tabs, the ADR has the answer. The mockup shows what the tabs would have looked like.
Related pages
- Mockups — creating and reviewing mockups
- Documents — writing ADRs and PRDs
- Plan a feature — the design phase where mockups are used