Answer in brief
SaaS product design covers the roles and permissions that decide who sees what, the repeated flows people use daily, and every state each screen can be in — empty, loading, failed, read-only, partial, dense and overflowing. It specifies component behaviour rather than appearance, covers keyboard and assistive use, and ends in a handoff engineering can build from. It does not cover the screens you have not scoped.
Verified facts
- Source review
- 7 September 2026
- Reader need
- SaaS design requirements
What the engagement actually produces
Ask what a SaaS design project delivers and the honest answer is not a number of screens. It is a set of decided situations: who is looking, what they are trying to finish, and what the interface does in each condition the system can actually be in. The populated, happy-path screen is the one everybody reviews and the one that causes the fewest problems afterwards.
The seven states below are where most of the work sits. Enumerating them is mechanical, which is where AI-assisted preparation is quick and inexpensive. Deciding what should happen in each is not, because the answer depends on how your system fails and what your users can afford to lose. That part needs a person who will be held to the answer.
Empty
Looks like: the screen before any data exists, carrying the single action that creates the first record and a plain description of what will appear once it does. Skipped: new accounts open onto a blank table, and support answers the same question every week.
Loading
Looks like: a decided behaviour for slow responses — skeleton rows, progressive fill, or a blocking indicator — and what changes past a stated threshold. Skipped: each screen gets whatever indicator its developer preferred, and slow paths read as broken.
Failed
Looks like: what the user sees when an action does not complete, what they can retry, and what input is preserved while they do. Skipped: a failed save quietly discards what somebody typed, which is the complaint people remember longest.
Read-only
Looks like: the same screen seen by somebody who may view but not change it, with hidden and disabled chosen deliberately rather than per screen. Skipped: permissions hold in the backend and leak in the interface.
Partial
Looks like: how the screen admits that one source failed or a figure is older than the rest. Skipped: a half-loaded screen looks just as authoritative as a complete one, and people act on it.
At scale
Looks like: the same table at a thousand rows — paging or virtualisation, sorting, filtering, and which columns survive the narrower viewport. Skipped: the layout works in the demo and not in the second month.
Overflowing
Looks like: every label and value at the longest length it can plausibly reach, including a translated string. Skipped: buttons wrap, truncation hides the part that mattered, and the repair lands after launch.
Roles and permissions come before screens
A screen is not one design if two roles see it differently. List every role — including the operator and support roles that never appear in a pitch deck — and state for each what it may see, what it may change, and what it must never reach. That table decides how many designs actually exist, and writing it costs far less than discovering it.
Decide deliberately whether a forbidden action is hidden or visible but disabled. Hiding keeps the interface quiet and leaves people unable to discover what they might request; disabling explains the boundary and admits the capability exists. Both are defensible. Choosing differently on each screen by accident is how one product ends up doing both.
Real data breaks layouts that sample data flatters
Ask for a redacted export before the first layout. Ten invented rows make every table look balanced; real records bring names that run long, fields left empty, near-duplicates, mixed languages and far more rows than any demo. Those are the conditions the design has to survive, and all of them are knowable on the first day.
Two numbers matter more than the rest: the longest value a field can genuinely hold, and the number of rows a normal account accumulates in a year. Design against those and the interface holds. Design against the demo and your first real customer becomes the first bug report.
The flows worth designing are the ones people repeat
Most of a working day inside a tool is two or three tasks done over and over. Those deserve the detail: every step, every branch, what happens when somebody is interrupted halfway and comes back, and how they undo what they just did. A settings page opened twice a year does not need the same treatment, and pretending otherwise is how scope quietly doubles.
Say out loud which flows were chosen for that depth and which were deliberately left lighter. An unstated difference in fidelity reads as unfinished work in a review, when it was actually a decision about where the effort should go.
Specify behaviour, not only appearance
A component is not described by how it looks. It is described by what it does: where focus lands, what disabled means, when validation fires and what it says, what happens on a slow response, and how the keyboard moves through it. Appearance can be copied from a picture. Behaviour gets invented in code if nobody wrote it down, and then it differs from screen to screen.
This is not the same thing as building a design system. Specifying behaviour once and reusing it is a deliverable of this work; standing up a system that several teams maintain for years is a separate decision with its own cost and its own readiness question, and it deserves to be asked separately rather than assumed into the scope.
Keyboard and assistive use are functional requirements here
People work inside a tool all day, which changes the calculation. Keyboard operation stops being a compliance checkbox and becomes the fast path for anybody entering data — and it is also the first thing to break when a custom control replaces a native one. WebAIM documents the keyboard behaviour interactive elements need and how to test it.
Custom controls need their semantics stated rather than implied. A styled div behaving as a select communicates nothing to assistive technology unless it is given a role, a state and a label, and MDN documents what ARIA expects of each. Decide this while designing, because retrofitting it usually means rebuilding the component.
What engineering needs in the handoff
The handoff is finished when somebody who was not in the design review can build a screen without asking a question. That means each state in its own frame, the real copy for empty and failed cases instead of placeholder text, spacing and type as reusable values rather than numbers measured off an image, and the rules the interface is expected to enforce written down as rules.
Include what is deliberately not specified, and name who decides it. Engineers make those calls anyway when a deadline arrives; the difference between a good handoff and a poor one is whether they knew they were making them.
What a 15–30 day scope covers, and what it does not
An engagement of this length covers the roles table, the repeated flows end to end, the states for the screens inside those flows, component behaviour for what those screens use, and the handoff. It does not cover every screen in a mature product, a full design system, continuing iteration after release, or research nobody commissioned.
The honest scoping question is not how many screens, but how many states across how many roles. Two roles and eight screens across seven states is a different project from five roles and the same eight screens — and the second is not slightly more work, it is a different estimate.
Write the exclusions down
List what is out of scope in the same document, before the work starts. Not as a disclaimer, but as a shared map of what exists and is not being done yet, with the condition that would bring each item in. Most disputes at the end of a product design engagement are not disagreements about quality; they are two different memories of what was included.
That exclusion list is also the cheapest planning artefact you will get out of the project. It is the next phase's backlog, already argued through, with the reasoning attached — which is more than most backlogs carry.
Practical checklist
- Every role listed with what it may see, what it may change, and what it must never reach
- Each screen specified in all seven states, not only the populated one
- Layouts checked against a redacted real export rather than a sample of ten rows
- The two or three daily-repeated flows designed end to end, interruptions included
- Component behaviour written down: focus, disabled, validation, slow response, keyboard path
- Keyboard operation and assistive semantics covered for every interactive element
- Handoff carries states, reusable values, real empty and failure copy, and enforceable rules
- Exclusions listed explicitly, each with the condition that would bring it into scope
Questions and answers
What is actually delivered at the end of a SaaS design project?
Flows for the work people repeat, every screen in each of its states, written component behaviour, the copy for empty and failure cases, and a handoff engineering can build from without guessing. The count of image files matters much less than whether behaviour is specified.
Why do designers ask for real data before starting?
Because sample data hides the problems. Ten tidy rows make any table look right; a real export brings long names, missing fields, duplicates and a thousand entries, and those decide the layout. A redacted export is normally enough.
How many screens should we expect?
Fewer than you expect, in more states than you expect. Eight screens with seven states each is fifty-six designed situations, and the states are where both the work and the risk sit. Counting screens alone consistently underestimates the job.
Do we need a design system for this?
Not necessarily. This work needs component behaviour specified once and reused, which is a different thing from building and maintaining a design system. If several teams will build in parallel for years, that is a separate question worth asking on its own.
What should we prepare before the project starts?
A redacted data export, the list of roles with their permissions, the two or three tasks people do daily, and somebody who can answer what should happen when an action fails. Those four unblock most of the engagement.