How do you design SaaS UX?

In short

With a SaaS product, the sale goes on after the user has started. They pay again every month or every year, so they decide again in every period. That's why in SaaS design I look above all at the path from sign-up to renewal.

In SaaS audits I focus on six places: activation, onboarding, the trial, plan and billing screens, roles and permissions, and empty states. All share one question: when does the user see that the product helps them?

The difference between B2B and B2C SaaS is big. In a business product, the person who buys is often not the person who uses it every day.

Activation and time to value

Activation is the moment a new user first completes the task the product promises. In an invoicing app it's the moment the first invoice reaches the client. In a project tool it might be the first task assigned to a colleague.

Time to value is the time from sign-up to that moment. I measure it in two units: minutes and steps. Minutes show the product's speed, steps the weight of the design.

1. Sign-upThe account is opened.
2. SetupThe bare minimum is entered.
3. First valueThe product does its job for the first time.
4. ReturnThe user comes back the next day.
5. PaymentThe trial ends, a plan is chosen.

Figure: the activation path. Time to value is the time from the first to the third box.

There is no generally accepted definition of these terms. Each product chooses its own moment of value. My rule: the moment of value is an event where the user looks at the screen and can say “This works”.

When choosing that moment I ask two questions. Is the event the user's real task, or only preparation? Do users who experience the event come back to the product?

Preparation steps aren't value. Uploading a logo or filling in a preferences survey sets up the product but gives the user nothing. I call these steps hurdles, because they stand between the user and first value.

You don't need a big analytics setup to measure it. Open a new account yourself, start a stopwatch and note every screen and every wait until the moment of value. In the first weeks that list tells you more than a dashboard.

SaaS onboarding: the task first, then the tour

SaaS onboarding has a single job: getting the user to first value. Explaining the product is worth only as much as it helps with that.

Page Laubheimer of NN/g describes in his 2023 article that tutorials at the start are used more often than needed. They interrupt the user's work and give information without context. Users often skip them, and even when they watch, they quickly forget.

Laubheimer explains this with the paradox of the active user. The user wants to use the product right away and resists learning up front, even if it would help later. He recommends showing help at the moment of need: as a tip, a hint marker or a step-by-step wizard.

This is the order I use in SaaS onboarding:

1. At sign-up, ask only for what the account needs. If the tax ID is needed for the first invoice, ask at the first invoice.
2. Don't put the user in front of an empty dashboard, but at the first step towards value.
3. Don't make the product tour mandatory. Laubheimer also recommends that help is easy to close and easy to find later.
4. Team invites, integrations and preferences come after first value.

Screen patterns and examples are in the onboarding pattern. In the simulator below you can see how the funnel changes when you ask for steps before or after first value.

Activation funnel

9steps6hurdlesThere are 9 steps to first value. 6 of them are hurdles.

Funnel

1. Path Open an account: email and password
2. HurdleLater Confirm email
3. HurdleLater Getting to know you: 4-question survey
4. HurdleLater Company and tax details
5. HurdleLater Card details
6. HurdleLater Product tour: 6 screens
7. HurdleLater Invite a colleague
8. Path Add your first client
9. Path Send your first invoice
10. First value: the invoice has reached the client

A made-up invoicing app. The steps and numbers come from no real product and show no conversion rate. The narrowing bars only illustrate the order. Untick a box and the step isn't deleted, but moved behind first value.

In the simulator no step is deleted; only its position changes. In real products, too, most of these steps are needed. The problem is usually the order.

For settings in complex products I use Jakob Nielsen's recommendation of progressive disclosure. Nielsen recommends showing frequently used options at the first level and opening advanced ones only on request. According to his 2006 article, designs that go beyond 2 disclosure levels typically have low usability, because users get lost moving between the levels.

Kate Kaplan's guidelines for complex applications (NN/g, 2020) point the same way. Advanced options should appear only when they fit the current task. The screen gets simpler without the product losing power.

Designing the free trial

The trial is the time in which the user should reach the moment of value before paying. If they see no value in that time, they have no reason to pay when it ends. That's why I look at the trial's first day before its length.

This is what I check on trial screens:

• Is the remaining time visible? The dashboard should say “Your trial ends on Friday” in a calm spot. A blinking notice on every screen isn't needed.
• Is the first charge stated beforehand? If card details are asked for, the date and amount of the first charge sit right next to the card form.
• What happens at the end? Is the account locked, is data deleted, does it move to a free plan? The user should know before the end.
• Is cancelling as easy as signing up? If sign-up takes two clicks but cancelling only works by emailing support, the user is in a subscription trap.

The last point is a question of trust. I describe such traps with examples in the guide to dark patterns, and the cancellation flow in the subscription cancellation pattern.

Asking for card details at the start of the trial is a business decision that design doesn't make alone. On the design side I have only one condition: the card form says clearly when and how much the user will pay.

Plan and billing screens

The plan screen is where the user looks for the answer to “Which one suits me?”. The most common mistake I see is every plan coming with a long feature list. To find the difference, the user has to compare row by row.

Kate Moran and Taylor Dykes of NN/g recommend in their 2024 article on comparison tables:

• Keep a static comparison table to small selections of 5 options or fewer. If there are more, let users choose what to compare.
• Offer to hide rows that are the same for every option, so only the differences remain.
• In long tables, keep the column headers sticky. Users can't remember which column belongs to which option.
• Keep in mind that on a phone it's hard to show more than two options at once.

I add how the price is written. Whether monthly or yearly, with or without tax, sits right next to the number. B2B buyers look for this at first glance because the invoice goes to accounting. How a pricing page is built overall is in the pricing page pattern.

The billing screen

The billing screen is opened rarely, but when it is, there's usually a problem. The card was declined, or accounting wants last month's invoice. So the screen has to give the information people look for at first glance.

On a good billing screen you see right away:

• the current plan and the number of users,
• the date and amount of the next charge,
• the saved payment method and how to change it,
• past invoices to download,
• how to upgrade, downgrade or cancel.

When the plan changes, show the result first. A preview that says how much is charged today and what the next charge looks like prevents the surprise invoice. The support ticket that would follow never gets written.

If a payment fails, the message gives the reason and the fix. “Your card has expired. Add a new card.” leads the user to the right button; “Something went wrong” doesn't.

Don't lock the account the moment a payment is declined. Give the user a few days to update the card, and state that window clearly on screen. A team shouldn't lose access to all its data on a Friday evening because of a card problem.

Roles and permissions

In SaaS products used by teams, not everyone sees everything. Admins handle invoices and settings; team members do their work. Roles create that separation but, badly designed, leave the user facing a wall with no explanation.

Amy Schade of NN/g mentions in her 2016 article on personalization intranet teams that had split their users into so many groups that the groups could no longer be maintained. The same article recommends reviewing personalized areas regularly, because needs change over time.

I carry that lesson over to roles and keep their number small. For most products, owner, admin and member are enough at first. A custom role comes when the need really arises.

What a user without permission sees is a design decision too. Maria Rosala of NN/g covers a similar situation in her 2019 article on app permissions. When the user opens a feature tied to a denied permission, the reason should be explained instead of a generic error, and an easy way to grant the permission shown.

With roles I do the same. Instead of “Access denied” I write: “Only admins can see invoices. Ask your account admin for access.” Next to it I put a button that sends the request in one click.

Hide the button or show it disabled? If the user will never do this task, I hide it. If they could do it after a role change, I show it disabled and write the reason next to it.

Empty states

In a new SaaS account most screens are empty. The client list, reports and notifications wait for the user's first data. In my audit experience, the empty state is the last screen designed in most products.

Kate Kaplan of NN/g gives three rules for empty states in her 2021 article. The empty screen communicates the current system status, gives a hint about what to do, and opens a direct path into the real task.

Kaplan also considers it misleading to show “no items” while loading. That message can damage the user's trust in the application.

One of Kaplan's examples is especially useful for SaaS. The empty screen has two paths side by side: add your own data or start with demo data. That way the user tries the product safely, without connecting their real data.

Empty state text can read like this: “You haven't added any clients yet. Add your first client or import your spreadsheet.” These two sentences tell the user where they are and what they can do. Two buttons underneath are enough.

For the form to add a client, see the form design pattern.

Common mistakes in SaaS design

Designing onboarding without defining the moment of value. If the goal isn't clear, the flow turns into a tour that explains every feature of the product in turn.

Asking for everything at sign-up. Company size and phone number are asked on the very first screen. The user is worn out by the form before seeing the product.

Making the tour mandatory. If the user can only use the product after the tour, the tour is a hurdle.

Hiding plan differences. If you have to read forty rows to find the difference, the user picks the cheapest plan or leaves the page.

Hiding cancellation. Hidden cancellation keeps a few subscribers in the short term and costs trust in the long term.

Always seeing the product with a full account. The team sees the product in a demo account full of data; the new user starts with an empty one. Run usability tests and audits with an empty account too.

My note

In SaaS audits the first thing I do is open a new account and count the steps to the moment of value. More than the total, I'm interested in how many of those steps are hurdles.

Teams usually add hurdles with good intentions. Finance wants the card details, marketing wants the survey answers. Each request is reasonable on its own, but together they wear out the new user before they send their first invoice.

My recommendation is usually to postpone. Ask for information when it's really needed: the tax ID at the first invoice, the team invite after the first completed task. If you want me to go through the whole product with this lens, UX Audit Pro looks at up to 10 flows.