Design
Screens for what you just specified, drawn in your own visual language rather than a stock template. It works from the requirements, so the states a spec usually forgets — empty, loading, error, too much data — are drawn rather than discovered during build.
- Asks for
- What you are designing — a PRD, an FRD, or a clear description
- Your design system or brand, if you have one
- Which screens you need, if you only want some of them
- Gives back
- Screens for each capability the requirements describe
- The states specs forget: empty, loading, error, too much data, no permission
- Your own colours, type and components where you have a system
- Something concrete enough to review against the document it came from
- Plan
- Pro and Max
- Use next
- Design review, Design system, PRD, FRD
What it gives you
Import — 5 screens 1 Empty. No backlog yet; the drop zone and the one-line explanation. 2 Column match, before saving (PRD §2.1). 3 Match with one unmatched column, asking about that column only. 4 Rows needing a value, listed with row numbers (FRD FR-14). 5 Import failed. What happened, and what is safe to retry. Drawn with the Piko system: ink ground, citron for the one primary action.
How it works
The gap between a specification and a buildable screen is where most features lose a week. The document says what the user can do; somebody then has to decide what it looks like when there is no data, when the list is two thousand rows long, when the save fails. Those decisions get made in code if they are not made in a design.
So this draws from the requirements rather than from a prompt about a pretty page: every capability the document describes needs somewhere to happen, and every state the behaviour implies needs a screen. What comes out is a set you can review against the spec — which is the same thing Design review then does from the other direction.
It draws in your visual language if you have one. Point it at your design system, or build one first, and the screens use your colours, type, spacing and components rather than a generic default that has to be redrawn before anybody can use it.
Who it is for
A PM without a designer who needs something concrete to review and build from, or a designer who wants the dull states drafted before they start.
Where it stops
These are screens to review and build from, not a finished design signed off by a designer, and they will not invent a visual language you have not given it — without a system you get a competent default. Interaction detail, motion and the hundred small judgements of craft still need a person.
Questions people ask
Do I need a design system first?
No, but the screens are much more useful with one. Without a system you get a competent neutral default, which is fine for reviewing whether the states and flows are right. With one — yours, or one built in PikoPM first — the screens come out in your colours, type and components, which is the difference between something you review and something you can hand to an engineer.
Why design from requirements rather than from a description?
Because the requirements contain the parts people forget. A description produces the screen where everything works; a specification implies an empty state, a failure, a limit and a permission case, each of which needs somewhere to happen. If those are not drawn they get decided in code by whoever hits them first, which is the most expensive place to decide them and the hardest place to review.
Can I use these screens as the final design?
For an internal tool or an early prototype, often yes. For anything customer-facing, treat them as a thorough first draft: the flows, the states and the structure will be right, and the craft — spacing judgements, motion, the particular feel of a control — is what a designer adds. Running Design review over them against the same requirements is a good way to find what is still missing.
Run it on your own work
Design needs an account, because it writes against what you give it and remembers what you have told it before. It is part of Pro and Max. Or see what the plans cost first.