# Wireframe

A wireframe answers what goes where, deliberately without answering what it looks like. Keeping it in Confluence rather than a design tool means the people writing the requirements can change it.

How finished it looks changes how people respond, so choose the fidelity on purpose.

---

## When to reach for one

* Writing a spec, where the layout is part of the requirement.
* Early feedback, when you want opinions on structure rather than colour.
* Documenting an existing screen you are about to change.

---

## How to draw it in Capable

| **Route**  | **Use when**                                                  |
| ---------- | ------------------------------------------------------------- |
| Excalidraw | Deliberately rough, so people critique structure not styling. |
| draw.io    | Crisp UI shapes when the wireframe is going into a document.  |

---

## Fidelity, and what it gets you

| **Fidelity** | **Draw with**         | **Feedback you get**                    |
| ------------ | --------------------- | --------------------------------------- |
| Sketch       | Excalidraw            | Is this the right structure?            |
| Wireframe    | draw.io UI shapes     | Is anything missing? Is the flow right? |
| Mockup       | draw.io mockup shapes | Does this work as a screen?             |

---

## A few things that catch people out

* Rough wireframes get structural feedback; polished ones get feedback about the shade of blue.
* Annotate behaviour. A static wireframe cannot show what happens on click unless you write it down.
* Keep it beside the requirement it illustrates, not in a separate design space.

---

## Related

[Mobile app wireframeDevice frames, navigation and touch targets.](https://help.gocapable.com/diagrams/mobile-app-wireframe.html)

[UI mockupA screen convincing enough to react to.](https://help.gocapable.com/diagrams/ui-mockup.html)

[ExamplesWorking diagrams you can copy.](https://help.gocapable.com/diagrams/examples.html)

---

_Fidelity is a choice, so choose it._