By Mehdi HassanMost "how to design an app" guides go from idea to launch in a few vague stages. This one shows the sequence we actually use when we design a SaaS app from a blank page, with the deliverable each step produces and the mistakes that usually send teams back. It's part of our wider guide to SaaS product design, which covers principles, cost and who should do the work.
How to design a SaaS app from scratch: what are the steps?
You design a SaaS app from scratch by moving from the user's job to a build-ready spec in seven steps, and by refusing to draw polished screens until the earlier steps are done. The order matters more than the tools, because each step removes a category of rework from the next one.
Step | Deliverable | Done when |
|---|---|---|
1. Jobs | Job statements and success moments | Each core user has one first-value moment |
2. Objects | Object map with relationships | Every screen can be named by the object it shows |
3. Flows | User flows plus an edge-case list | Signup, first value, invite and upgrade are mapped |
4. Copy | Screen copy and a terminology list | Every noun has exactly one name |
5. Wireframes | Grayscale screens with real data | Flows tested with users or customer-facing staff |
6. UI | Visual design and component states | Every component has all its states designed |
7. Specs | Annotated files, tokens, behaviour notes | Engineers can build without asking what happens next |
Step 1: What jobs does your SaaS app do?
Start by writing the jobs your app does in the user's words, plus the moment they first get value. A job statement looks like "When a client pays late, I want to send a polite reminder without writing it from scratch." The success moment is "the first reminder goes out."
Get these from customer interviews, sales call recordings and support tickets, not from a brainstorm. Two or three core jobs is normal for a new product. If you have ten, you have several products, and you need to choose one to design first. The success moment matters most, because your onboarding, empty states and first-run flow all exist to get users there.
Step 2: How do you model the objects in a SaaS app?
Model the objects by listing every noun your users care about, such as clients, invoices, reminders, templates and workspaces, then drawing how they relate. This object map is the skeleton of the app. Navigation sections, list views, detail pages and URLs come straight out of it.
Mark which objects belong to a user and which belong to a team, because that decides your permission model later. Decide early whether your app is single-player, team-based or multi-tenant with several workspaces per user. Adding workspaces after launch is one of the most expensive retrofits in SaaS, which is why our guide to roles and permissions UX recommends deciding it here. The structure work continues in SaaS information architecture, where the object map becomes navigation.
Step 3: How do you map SaaS user flows?
Map SaaS user flows as simple boxes and arrows for the four flows every product has: signup to first value, the core job, inviting a teammate and upgrading. Then list the edge cases for each, because SaaS apps spend more time in edge cases than in the happy path.
- No data: the first visit, a new workspace, a filter with no results.
- Too much data: hundreds of rows, long names, many teammates.
- No permission: a viewer opens an editor's link.
- Limits: the user hits a plan cap mid-task.
- Failure: an import breaks, a payment fails, an integration disconnects.
The edge-case list is the deliverable most teams skip, and it's the reason builds slip. Every item on it needs a screen or a state later. Writing it now turns surprises into scope.
Step 4: Why write the copy before the wireframes?
Write the copy before the wireframes because words force decisions that boxes let you avoid. A wireframe can show a button labelled "Action". Copy can't. Writing the real headings, labels, empty states and error messages exposes vague features and conflicting names before anyone draws a pixel.
The deliverable is a screen-by-screen copy doc plus a terminology list, with one name for each object and action. It doesn't have to be final; it has to be real. Our guide to UX writing for SaaS has rewrite pairs you can use as patterns, and B2B SaaS UX principles explains why clarity of language does more for complex products than clever layout.
Step 5: What should SaaS wireframes include?
SaaS wireframes should include real copy, realistic data and every state from your edge-case list, in grayscale so the conversation stays on structure. A wireframe set for a new app usually covers the main list and detail views, the core job screen, onboarding, settings and each state that differs visibly.
Test the wireframes before visual design. A few sessions with target users catch most structural problems, and sales or support staff are a fast second opinion because they hear customers' confusion every day. For data-heavy screens, our SaaS dashboard design checklist is a useful review pass at this stage, and dashboard design examples show how others handle density.
Step 6: How do you design the SaaS UI and its states?
Design the SaaS UI by applying a visual system to the tested wireframes and building each component with all its states: default, hover, focus, active, disabled, loading, error and empty. Start from a proven component library and customise tokens rather than inventing every component.
Design the key screens at full fidelity first, then confirm that the same components work everywhere else. Keep visual identity in typography, color and a few signature details, not in custom versions of standard controls. If your app needs a brand to go with it, do that work alongside the UI so they share a language; our logo design process shows how the identity side runs.
What a full set of component states looks like for one table
A data table in a SaaS app needs more than one design. You need the default list, a loading skeleton, an empty state for a new account, an empty state for a filter with no results, an error state with a retry, rows with very long values, a selected state with bulk actions, a read-only version for viewers and a narrow-screen version. Designing these once, as part of the component, means every table in the app gets them for free. Designing them per screen means some screens ship without them.
Step 7: What makes a SaaS design build-ready?
A SaaS design is build-ready when an engineer can implement it without asking what happens next. That means annotated behaviour, responsive rules, all states, the copy, design tokens that map to code and notes on anything non-obvious, like what saves automatically and what needs confirmation.
Annotate behaviour
Note what each interactive element does, including keyboard shortcuts, validation rules and what happens on failure.
Specify responsive rules
Show how layouts change at each breakpoint, especially tables, sidebars and modals.
Export tokens
Name colors, spacing, radii and type styles so they map to CSS variables or Tailwind config.
Link states to components
Make sure every component frame shows its full set of states, not just the default.
Review the build
Walk through the built version against the design and fix gaps before launch, not after.
Plan your domains at this point too. Most SaaS teams keep the app and the marketing site separate, and our guide to splitting your marketing site from your app covers subdomains, subfolders and proxies. When you plan the settings area, SaaS settings page design has patterns for grouping and save behaviour.
If you want help turning your flows and copy into screens, our $3,000 brand and design sprint delivers a brand refresh or redesign plus 10 product explorations as Figma files, at a fixed price. It's design only, so the build itself stays with your engineers.
