# UI mockup A mockup is a wireframe with the visual detail put back: real buttons, real form fields, real tables. It is the right fidelity when you want a decision rather than a discussion. Keeping it in the page means it can be updated when the decision changes, which a pasted screenshot cannot. --- ## When to reach for one * Sign-off, where people need to see the actual screen. * Documentation of a feature that does not exist yet. * Support and training material, where an annotated screen beats prose. --- ## How to draw it in Capable | **Route** | **Use when** | | ---------- | ----------------------------------------------------------- | | draw.io | The mockup shape libraries: buttons, fields, tables, menus. | | Excalidraw | When you deliberately want it to look unfinished. | --- ## States worth mocking | **State** | **Why it matters** | | --------- | -------------------------------------------------------------------- | | Empty | The first thing a new user sees, and usually the last thing designed | | Loading | Where layout shift and impatience live | | Error | The state most likely to be improvised in code | | Full | Long names and big numbers break more layouts than anything else | --- ## A few things that catch people out * A mockup that looks finished will be treated as finished. Label it clearly if it is not. * Reuse a shared shape library so mockups across the team look like the same product. * Show the states that break: long text, empty lists, errors. --- ## Related [Site map diagramPage hierarchy, and what links to what.](https://help.gocapable.com/diagrams/site-map-diagram.html) [Floor planWalls, doors and furniture, to scale.](https://help.gocapable.com/diagrams/floor-plan.html) [ExamplesWorking diagrams you can copy.](https://help.gocapable.com/diagrams/examples.html) --- _Fidelity is a choice, so choose it._