SaaS dashboard design: forty actions, one calm screen

A landing page has one job and one button, repeated until the visitor acts. A product screen is different. It can hold forty actions: add, edit, filter, assign, export, undo. Designing it is not about making each button pretty. It is about deciding what the user sees first, what waits one step away and what never needs to appear at all.

Start from the outcome, not the feature list

Before a single wireframe, we ask the owner one question. What must the user walk away with?

In Aimgod, a personal growth system, the answer is a day of finished tasks and nothing forgotten. So the task list is the home screen. In Spillsjakk, the tournament platform of the Norwegian Chess Federation, the answer is a tournament set up, run and closed by an arbiter from one place. So the tournament screen carries players, pairings, games and results.

A feature list tells you what the product can do. The outcome tells you what the screen is for. Every layout decision after that is easier.

Set the direction above the tasks

Sometimes the product needs a direction before it needs a layout. Aimgod could have been one more to do app. Its direction is personal growth, and the task list sits inside it as the daily layer of a larger system:

1. Long focus. Thoughts worth keeping for life, such as a line from a book, saved from a photo and read full screen.
2. Middle focus. Goals for the month and the year.
3. Short focus. Today, with tasks tied to those goals.

Once the direction is clear, it decides which functions belong on the main screen and which belong elsewhere.

Build a hierarchy of functions

With the outcome and direction set, we sort every function into three groups:

1. Primary. Used every session. Always visible, always one tap away.
2. Secondary. Used often, but not every time. One step away: a menu, a popup, a collapsible list.
3. Rare. Settings, exports, bulk changes. Present, but out of sight until needed.

This sounds obvious. In practice most cluttered dashboards are the result of every team adding its feature to the primary group.

Merge screens instead of adding them

The player list in Spillsjakk is the best example we have. The old interface spread player management across five pages. We combined them into one. Collapsible lists keep the overview short. A popup for each player shows the full history and every opponent, and one click moves from player to player. Achievements are drawn as charts instead of tables. The screen holds far more than before and is much faster to use.

Fewer screens mean fewer places to get lost. The work is to make one screen deep, not to make many screens shallow.

Keep rules only where they help

Flexibility is part of usability. In Aimgod any part of the system works on its own: you can use only goals, or only the daily list. Firm rules appear only where they protect the outcome. A goal is split into stages, and the next stage opens only when the previous one is done.

Small interactions matter as much as structure. Setting a time for a task in Aimgod takes two taps. Shaving a step off an action people repeat every day is worth more than any new feature.

Make the structure scale

A dashboard concept is the start, not the deliverable. We turn it into a design system: tokens for color, type and spacing, components with every state, rules for density and layout. The Spillsjakk system covers more than 150 screens in light and dark themes. New screens then take hours, not weeks, and stay consistent with the first one.

In short

1. Name the outcome before drawing anything.
2. Give the product a direction above the features.
3. Sort functions into primary, secondary and rare.
4. Merge screens where people jump between them.
5. Add rules only where they protect the outcome.
6. Turn the concept into a system.

If your product has grown screen by screen and now feels heavier than it should, see how we approach SaaS product design or tell us about it.