leogodnik Mockup first, code second
Why
The gap between what a person pictured and what they got is cheaper to catch in a mockup than in finished code. This skill inserts one stop: show a clickable mockup as a link, then wait for a yes before touching the real file.
Where the line falls
A noticeable change gets a mockup. A one-off tweak goes straight to code.
- Several small tweaks that together change the layout count as one noticeable change.
- If you are unsure whether it is noticeable, treat it as noticeable. But do not build a mockup silently — ask in one line.
Order of work
- Say in one sentence what is changing. Ask a clarifying question only if the mockup would certainly be wrong without an answer. Otherwise take a sensible default and name it in the caption.
- Take the styling from an existing project file: colors, fonts, radii, spacing, ready-made markup. Do not invent your own — the mockup should look like a continuation of the page.
- Build the mockup in a temporary folder: the part being changed plus enough surroundings to show where it lives. Placeholder data, but plausible. Buttons press, tabs switch, empty and error states show if the task involves them. Never touch the real file.
- Publish it as an Artifact. Give the link and 3–4 plain sentences: what is visible, which decisions you made on the person's behalf, what you deliberately left for later. If publishing fails, save the file and open it in a browser — but do not drop the step.
- Wait for an answer. Revisions mean editing the same file and republishing to the same address; the link does not change. Never slip into code silently.
- After a yes, carry the approved version over literally: layout, labels and states match the mockup. The only deviations are ones you were asked for.
- The mockup file stays in the temporary folder: it never moves into the project or lands in git.
Neighboring skills
- Material for students —
course-handouthandles it: the published page is the deliverable there, so no separate mockup is needed. - Not yet decided what to build —
superpowers:brainstormingcomes first. frontend-designandmake-interfaces-feel-betterapply while building the mockup, not instead of it.
Excuses that do not work
| The thought | What is actually true |
|---|---|
| "It is obvious how this should look" | Obvious to you; it still needs agreeing. |
| "It is a small change" | The layout changes — then it is not small. |
| "I will just show it in finished code" | Then rework happens in the real file. |
| "I will do the mockup and the code at once" | Approval is their answer, not your guess. |
| "They are in a hurry" | A mockup takes two minutes; reworking code does not. |