Empty States Designed
The first screen a real user sees, which is never the one in the demo.
SaaS UX Design
SaaS UX Design Where the First Session Decides Activation
Most SaaS products lose users in the first ten minutes, before a single feature has been evaluated. The account is created, the screen is empty, and there is nothing obvious to do. SaaS UX design treats that first session as the product's most important screen — and treats the growing feature set as a problem to be managed rather than a list to be exposed.
We Design the Empty State First
Every SaaS product is demonstrated full of data and used, on day one, empty.
One Path to Value
A single obvious first action, not a tour of everything.
Complexity Deferred
Advanced capability available without being in the way on day one.
Activation Measured
Whether people reached the point the product is useful, not whether they logged in.
Designed for Return
The second session matters as much as the first and is rarely designed at all.
What SaaS product UX is judged on
A software product is judged on whether people reach value and keep returning, not on whether the interface is admired. Everything below is observable in a product analytics tool or a recorded session, and each one points at a specific place the experience can fail.
Time to first valueHow long from signup until the user does the thing they came for
Activation completionWhat share of new accounts reach the defined activation event
Setup drop-off pointsThe specific onboarding steps where accounts stop and do not resume
Empty-state effectivenessWhether a new account with no data knows what to do next
Feature discoveryWhether capabilities users pay for are ever found
Repeat-task efficiencyClicks and time for the action power users perform daily
Error recoveryWhether a user who hits a failure can resolve it without support
Support ticket themesWhich recurring tickets are interface problems rather than questions
Invite and seat flowWhether a user can bring colleagues in without administrative help
Data density toleranceWhether views hold up at the volumes real accounts reach
Keyboard operabilityWhether frequent actions are reachable without a mouse
Accessibility conformanceFocus order, contrast and screen reader behaviour in core flows
Support ticket themes are the cheapest research available and the most under-used. A recurring question is a design failure that has already been documented by the people paying for the product, and reading three months of tickets usually identifies more real problems than a round of commissioned research.
SaaS UX, Explained
Where Do SaaS Users Drop Out?
Four points, and the first two happen before any feature is used.
Discuss Your Product →- 1
The Empty Screen
Nothing there, no obvious first move, and the tab gets closed.
- 2
The Setup Wall
Configuration required before any value is visible.
- 3
The Second Session
They came back and could not remember what they were doing.
- 4
The Growth Point
The product got more capable and the interface stopped being navigable.
What SaaS UX Work Covers
Onboarding, the core loop, and keeping complexity manageable as the product grows.
The build side is covered by SaaS development; the marketing surface by SaaS website design. The marketing site that fills the trial is SaaS website design; the architecture behind the product is SaaS development.
How We Approach SaaS UX
Watch first sessions. Almost every activation problem is visible within five of them.
Define First Value
The moment the product has done something useful.
Watch First Sessions
Real people, real accounts, from empty.
Redesign the Path
One route to that moment, obstacles removed.
Design the Empty States
Every screen before there is data in it.
Measure Activation
By cohort, so changes can be attributed.
What changes the shape of a SaaS UX engagement
Scope here is driven by how the product is adopted and how complex the underlying domain is. A self-serve tool that a single person configures in an afternoon and a platform an organisation rolls out over a quarter are different problems.
Self-serve products with a free trial
Where the entire sale happens inside the interface and nobody is available to explain anything. Onboarding carries disproportionate weight, because a user who does not reach value in the first session usually does not return for a second. This is normally where the work should start.
Products with a genuinely complex domain
Financial, logistics, clinical and engineering software where the complexity is real and cannot be simplified away. The work is about revealing complexity progressively rather than hiding it, and it requires enough domain understanding to know which parts practitioners actually need visible.
Products bought by one person and used by another
Where an administrator configures and a team uses. Two distinct experiences with different needs, and the administrative side is almost always the neglected one — which surfaces later as slow rollouts and stalled expansion.
Products approaching a scale ceiling
Where interfaces built for early accounts break down at the data volumes mature accounts reach. Lists that assumed twenty rows and now hold twenty thousand are the common case, and the fix is usually filtering, search and defaults rather than visual redesign.
Products preparing to add a second product line
Where navigation, permissions and naming have to accommodate something the original architecture never anticipated. This is an information architecture problem before it is an interface one, and doing it in the wrong order means building the same screens twice.
Onboarding
Why the Empty State Is the Most Important Screen
It is the one every new user sees and the one nobody designs.
Why does it get overlooked?
Because everyone building the product uses accounts full of test data. Designs are reviewed with realistic content, demos are given with populated dashboards, and the empty version is never on screen.
The first real user sees a blank table, an empty chart and a navigation menu leading to more blank screens. Nothing in the interface suggests what to do.
An empty state that names the first action, explains what will appear, and provides sample data or a template converts that moment from confusion into a start.
Why is a feature tour the wrong answer?
Because it asks someone to learn the product before they have any reason to care about it. Tooltips explaining six features are dismissed and forgotten.
What works better is one path to one useful outcome. Someone who has done a real thing has a reason to explore, and the rest of the product becomes discoverable rather than needing explanation.
It also produces a better measurement: whether they completed the path, rather than whether they clicked through a tour.
Onboarding is where most SaaS products lose the users they already won
Acquiring a signup is the expensive part, and a substantial proportion of signups never reach the point where the product does anything useful for them. That gap is almost always an experience problem rather than a marketing one — the user was persuaded enough to create an account and then encountered something that cost more effort than their remaining motivation.
The failures are usually mundane. An empty account with no guidance about what to do first. A setup step requiring information the user does not have to hand, such as an API key or a colleague’s permission. A configuration sequence that must be completed before anything can be seen, so the user is asked to invest before receiving evidence that the investment is worthwhile.
The principle that resolves most of this is to deliver something useful before asking for anything substantial. Sample data, a pre-populated example, or a path that produces a visible result in one step gives the user a reason to continue. Configuration then happens after motivation has been reinforced rather than being the barrier in front of it.
Designing for the daily user and the occasional one at the same time
Most software has two populations with opposed needs. Daily users want density, speed, keyboard access and no repeated explanation. Occasional users want guidance, labelling and reassurance that they are in the right place. Optimising for either alone degrades the experience for the other, and pretending they are one audience is the usual source of interface compromise.
The resolution is layering rather than averaging. The default view serves the less experienced user with clear labels and visible affordances, while shortcuts, bulk operations and keyboard paths sit alongside for anyone who wants them. Neither population is asked to accept the other’s interface, because the additional capability does not obstruct the simpler path.
Deciding which population a given screen belongs to matters as much as the layering. An administrative settings page is used rarely by everyone and should be optimised for comprehension; the main working view is used constantly by the core audience and should be optimised for throughput. Treating every screen the same way is what produces products that feel simultaneously cluttered and slow.
Empty states, errors and the parts nobody designs
Product design attention concentrates on the populated, successful case: the dashboard with data, the report that generated, the flow that completed. Users encounter the other states more often than teams expect, and those states are typically left as whatever the framework produced.
An empty state is the first screen every user sees, before any data exists. Left undesigned it communicates that nothing is happening and offers no direction, at exactly the moment the user most needs direction. Designed properly it explains what will appear here, why it matters, and what single action produces the first entry.
Error states carry similar weight in the opposite direction. A failure message that states what went wrong, whether the user caused it, and what to do next converts a moment of frustration into a resolved problem. A generic message with a code turns it into a support ticket. Since support cost is a direct operating expense, the case for designing these properly is straightforwardly financial as well as experiential.
Questions, answered.
SaaS UX design covers the experience inside a software product — activation and onboarding, the core task loop, empty states, and keeping the interface navigable as the feature set grows.
Usually because the first session did not reach anything useful. An empty screen with no obvious first action is the most common cause, and it is invisible to teams working in accounts full of test data.
Usually not. Tours ask people to learn a product before they care about it. One path to one useful outcome works better and gives a clearer measurement.
By watching five real first sessions from an empty account. Most activation problems are visible within that, and it is considerably faster than analysis of aggregate funnels.
Activation — whether users reached first value — by cohort, so changes can be attributed. Signups and logins tell you almost nothing about whether the product worked for anyone.
Usually the first session reached nothing useful. Empty states are the most common cause and the least designed screen, because everyone building the product works in an account full of data.
Three sources, none of which require a research budget. Product analytics showing where users stop in a flow. Support tickets, grouped by theme — recurring questions are usually design failures. And watching five real users attempt a core task without help, which reliably surfaces problems no internal review finds because the team knows where everything is. If all three point at the same screens, the diagnosis is not in doubt.
Specific flows, in almost every case. A full redesign disrupts users who have learned the current product, consumes engineering capacity for months, and changes so many variables at once that nothing can be attributed. Targeted work on the flows where users demonstrably fail delivers most of the benefit at a fraction of the risk. Full redesigns are justified when the underlying architecture genuinely cannot support where the product is going.
Less than most proposals suggest and more than most teams do. Existing analytics, support tickets and a handful of observed sessions are usually enough to identify what is broken. Commissioned research earns its cost when the question is what to build rather than what to fix, or when internal opinion is deadlocked and needs external evidence — see UX research.
It can, and it depends entirely on why customers are leaving. Churn caused by users never reaching value, or by a core task being unreasonably laborious, is addressable through design. Churn caused by pricing, by a missing capability, or by the product not fitting the customer’s actual need is not, and design work will not fix it. Establishing the reason first is what prevents spending on the wrong solution — and any specific retention figure would need your own data to substantiate.
By keeping them discoverable without letting them impose on everyone. Features used by a minority should not occupy primary navigation, and they should not be hidden so thoroughly that customers paying for them never find them. Contextual surfacing — showing the capability at the moment it becomes relevant — usually serves better than either permanent prominence or a buried settings page.
Still deciding if saas ux design is right for you?
Talk to UsNobody on the Team Has an Empty Account
Every person building a SaaS product works in an account full of data. Designs are reviewed against realistic content, demos are given with populated dashboards, and bugs are found in busy states.
The screen every new user sees — blank table, empty chart, navigation leading to more blank screens — is the one screen nobody on the team has looked at in months.
It is also the only screen that decides whether they come back. Creating a fresh account once a month and opening the product cold is the cheapest UX exercise available, and almost nobody does it.
Free UX Review
See Your Product From an Empty Account
Give us a fresh trial account. We will record the first session cold and tell you where a new user loses the thread.
Claim Your Free Marketing Audit
Enhance Your Brand Potential At No Cost!
- Expect a response within 24 hours
- NDA available upon request
- Dedicated product specialists