SaaS dashboard and admin panel design

The problem this solves

The brief usually arrives as a list of charts. Somewhere behind it is a real complaint: an operations lead who opens the tool every morning, reads six numbers, and still has to go somewhere else to find out which accounts need attention today.

That is not a charting problem. An average tells you a state; a queue tells you what to do. A dashboard that is all state is a report, and a report is something people check rather than something they work from. The expensive version of this ships twenty views nobody opens.

The fix is upstream of the visuals. Before anything is drawn, the decisions the product is supposed to support have to be written down: who makes each one, how often, on what evidence, and what happens when they are wrong.

What you get

• A decision inventory

  Every decision the dashboard exists to support, with who makes it, how often, and what they currently open instead. This is the document that decides what gets built.

• Annotated flows and states

  The screens, with empty, loading, partial-permission, error and too-much-data states drawn rather than assumed. Those states are most of the real usage and they are usually the last thing anyone designs.

• A component inventory

  What already exists, what has to be built, and what can be retired. Enough for an engineer to estimate from without a workshop.

• A Figma file your engineers can build from

  Tokens named after decisions rather than colours, real data in the tables, and the density your product actually runs at rather than a marketing screenshot.

How it runs

1. 1

   Watch someone use the current one

   Sessions with the people who open it daily. Not a survey. The interesting finding is almost always what they open alongside it.

2. 2

   Write the decision inventory

   Agreed with whoever owns the outcome before any screen is drawn, because this is the document everything else is measured against.

3. 3

   Structure before surface

   Situation, explanation and action separated, and the exceptions promoted over the averages. Low fidelity, because this is the part that gets argued with.

4. 4

   Build it out

   Real data, real density, every state. Reviewed against the inventory rather than against taste.

5. 5

   Hand it over and stay reachable

   Annotated file, component inventory, and answers while it is being built rather than a document thrown over a wall.

The longer version of this, with what happens in each week, is on the process page.

Where this has been done

• Symantec CloudSOC, for Broadcom

  20% higher retention, 35% fewer UX support tickets

  Fortune 500 security analysts were losing 40% of their day to false-positive alerts. Twelve sessions with analysts changed the direction of the redesign, and alert triage was rebuilt around decisions made under time pressure.

• US Health Care Nurses

  401 screens across a two-sided operation

  Nobody could say who was covering a client on Thursday without opening three systems. A marketplace, a scheduling board, clinical records and payroll, designed as one operational surface.

Typical engagement

Most dashboard work runs four to eight weeks depending on how many distinct roles use the thing and how much of the decision inventory already exists. A single-role admin panel sits at the short end; a multi-role operational product with permissions and audit requirements sits at the long one.

I work with one client at a time on this, so the honest answer about when it can start is usually more useful than the answer about how fast it can go. Tell me your timeline and I will tell you whether it is real.

Who this is not for

• You want the existing screens restyled. If the structure is right and only the surface is dated, you need a visual pass and this is more than that.
• Nobody can get me thirty minutes with someone who uses the product daily. Without that this becomes decoration with a process attached.
• The chart list is already signed off and the job is to draw it. That is a production task, and someone cheaper will do it faster.
• You need it in two weeks. Complex operational software does not compress that far without the compression showing.

How I think about this

• Your dashboard doesn't need another chart — the argument this service is built on, with the three layers a dashboard is made of
• Every product is empty on the first day — why the states nobody briefs are most of the real usage
• 4.5 to 1 is a floor, not a target — severity encoding that survives a colour-blind analyst on a bad monitor
• Your design system isn't slow — what to do when the library gets blamed for an unmade product decision

Frequently asked questions

How long does a SaaS dashboard design project take?

Four to eight weeks for most products, driven by how many distinct roles use it rather than how many screens it has. Two roles with different permissions is a bigger job than forty screens for one role. If a decision inventory already exists, the first week or two disappears.

Do you work with our engineers or hand over a file?

Both, and the file alone is rarely enough. I stay reachable while it is built, because the questions that decide whether a design survives are asked during implementation, not before it. The handover includes annotated flows and a component inventory an engineer can estimate from.

What timezone do you work in, and how much overlap is there?

I am in Karachi, UTC+5. That gives a working overlap with Europe for most of the day and a morning overlap with the US East Coast. I schedule the calls that need everyone at your end of the day rather than mine.

Can you sign an NDA?

Yes, and most of the work here is already under one. That is why several case studies on this site are readable but unindexed, and why the screens in them are not public. If your legal team has a template, send it.

What happens if the scope changes mid-project?

We reprice or we re-cut, and I would rather do it in the open early than absorb it quietly and deliver something thinner. Scope changes on operational software are usually a role or a permission model nobody mentioned at the start, which is a real discovery rather than a failure.

What do you need from us to start?

Access to the current product, thirty minutes each with two or three people who use it daily, and one person who can say yes. Sales call recordings and support tickets help more than a requirements document, because they are what people said when they were not being asked to specify anything.