In 2021 I stopped making mockups. Not as a principle; I was on a project with two engineers and no time, and it was faster to build the screen than to draw it. Four years later I have not drawn a mockup for client work since. This is what it actually looks like.
What a day looks like
Morning: paper. A pencil sketch of the flow, usually three or four boxes and arrows. Ten minutes.
Then the browser. I open the team's repository and build the screen with real components, real data and real states: empty, loading, error, too much. By the afternoon there is a link anyone on the team can click.
Then feedback, in the engineering channel, on the real thing. "The empty state is wrong" is a comment on a link, not a comment on a picture of a link.
What it is good at
- There is no handoff. The thing I made is the thing that ships. Jonas at Ledgerly put it as "we never had a handoff problem because there was no handoff."
- States are real. A mockup shows the happy path. Code shows what happens when the list is empty, the name is forty characters long and the request fails.
- The constraints are real. If the component library cannot do it, I find out in an hour, not in a review three weeks later.
- Engineers trust it. Design that arrives as a pull request gets reviewed like engineering, which is a compliment.
What it is bad at
- Exploring widely. Ten rough directions in an afternoon is a Figma job. In code I explore two or three. I do the wide exploration on paper, which is faster than either.
- Teams that do not share a codebase with design. If I cannot get into the repository, I cannot do this. I ask on the first call.
- Visual polish. I am a product designer, not a visual one. For brand work I bring someone in.
What I would tell a designer thinking about it
Learn the team's stack well enough to build a screen, not well enough to build the product. Pair with an engineer for the first month. Keep the paper. And expect the first project to be slower, and every one after it to be faster.
