Admin dashboard design: build the screens around the owner's questions

Admin dashboard design in one answer

Good admin dashboard design starts from the questions the owner and staff ask every day. Write those questions down in their own words. Give each daily question one screen that answers it, and keep the database tables underneath. Put the rest behind search and each record's history, and make every risky action show its effect before anyone confirms it.

An admin dashboard is the back office of your software: the first screen staff see when they log in, plus the screens they use to find and change records. The easiest one to build has a screen per database table. That is why so many admins are hard to use: each screen is correct, and together they leave the owner to join the tables up in their head.

This guide is for owners and operations leads at UK and EU firms of 10 to 200 people. You may be commissioning custom internal software, and the admin is the part your team will live in. Or you already have one, and people still phone each other to find things out.

Why most admin panels mirror the database

A builder's first instinct is to show the data the way it's stored. Say you run a 40-person facilities maintenance firm in Leeds, whose engineers service boilers and fix faults at client sites. Your software holds customers, sites, jobs, visits, engineers, invoices and payments.

So the admin menu gets seven items, each with a filtered list behind it. Nothing is missing, and it is the builder's map of the system.

Frameworks make that map almost free. Django, a widely used web framework, builds an admin straight from the data model. Its documentation calls the result "model-centric", for trusted users managing content. If you need a "process-centric" interface that hides the tables and fields, it says, it's probably time to write your own screens.

Your map is different. You don't think in visits and payments. You ask what's happening today, who owes you money and what went wrong with the Harrogate job. An admin built on the builder's map answers each question with three screens and a filter, so your staff go back to phoning the office.

Start with the owner's questions

The method is plain. Before anyone draws a screen, write down the questions you and your staff ask, in the words you use, and how often each comes up. The UK government's first design principle makes the same point for public services: if you don't know what users need, you won't build the right thing.

For the facilities firm, a week of listening to you and the office might produce this list:

Seven questions became five screens and one report. Each daily question gets a screen of its own. The monthly one becomes a report, since nobody needs it at eight in the morning. A phone call needs search, because the caller could be any of hundreds of customers.

When we design an admin, this list comes before any screen. Our internal software page promises the current process "mapped before anything is built", and the questions are the part of that map the admin has to answer. Listen to the people who will use it all day, too. The office coordinator asks "who can I send to a no-heating call at 4pm?", a question the owner rarely asks.

Name things the way the business does

Every label in the admin should be a word the owner already uses. Nielsen Norman Group's second usability heuristic says a system should speak the users' language, rather than use system-oriented terms. In an admin, the system-oriented terms come straight out of the database.

Use their words even when those words are jargon. If the firm says "PPM" for planned maintenance, the admin says PPM. The test is whether the owner can find their way round without a glossary. Watch them use it, and rename every word they stop at.

Nothing underneath changes. The history screen reads from the same log, and "work done, not billed" is still a reconciliation. Only the labels are written for a different reader.

What belongs on the first screen

The first screen answers the questions asked every morning, and little else. Stephen Few, author of Information Dashboard Design, defines a dashboard as the most important information for a goal, on one screen, readable at a glance. Seven tables don't fit on one screen. Four answers do.

For the facilities firm, the first screen might hold:

• Today's jobs, with the late ones at the top and the reason beside each.
• Which engineers are out, and where each is booked next.
• Invoices more than 30 days late, as a count and a list.
• Work done this week that hasn't been billed.

Plain numbers and short lists beat charts for daily questions. A chart earns its place when the question is about a trend, such as "are we busier than last spring?" That question usually belongs in the monthly report.

Be careful with what the system decides to show on its own. A "needs attention" feed, scored by rules the owner never saw, sounds helpful. Next to the plain numbers they asked for, it can read as noise. Add alerts one at a time, when someone asks "why didn't it tell me?"

Design the screens for when things aren't normal, too. Our web applications page promises every state designed, including empty, loading, error and permission denied.

On a dashboard, the dangerous state is an error that looks like data. If the invoices query fails and the tile shows "0 overdue", the screen tells the owner all is well when it doesn't know. Show "couldn't load invoices" instead. People trust an admin that fails loudly.

Finding one record among thousands

Past a few dozen records, people stop browsing and start searching. Demo data has twenty customers, and a list works. A year of real work has thousands of jobs, and a list sorted by date answers nothing.

Put one search box at the top of every screen. It should find a customer by name, postcode, phone number or job number, because those are what a caller gives you. Filters are for browsing when you don't know what you want. Search is for when you do.

Each record then gets a page of its own, with its history: every visit, invoice, call and change, newest first, and who made each one. That is the screen the office opens with a customer on the line. A history that records corrections as new entries also answers "who changed this, and when?", one of the signs in our guide to replacing spreadsheets with software.

The web applications page also promises "interfaces that stay usable at real data volumes, not demo volumes". Judge any admin that way: load a copy of a year's data before you decide whether a screen works.

Different people, different first screens

The owner opens on late jobs and money. The office coordinator opens on the diary. An engineer on a phone sees only their own jobs for today, and never the invoice values. Same data, three first screens.

Behind that sit two separate questions for each person: what may they see, and what may they change? Set them up as roles, not as a list of names, so the admin survives the next restructure. We cover how in user roles and permissions that survive your next reorganisation.

Make risky actions say what they'll do

Some admin actions can't be undone: cancelling a batch of visits, issuing credit notes, deleting a customer, sending money. For these, the screen must show the effect, not the settings.

Citibank learned this in public. On 11 August 2020, it meant to send the lenders on a Revlon loan an interest payment. It sent them the loan's entire principal as well, out of its own money. The US district court's findings in the case describe the screen in detail.

The bank's loan software, Flexcube, sent every payment out of the bank by default. To keep the principal inside, the bank's manual said three fields, FRONT, FUND and PRINCIPAL, all had to point to an internal account. The employee entering the payment set one.

A checker and a senior manager then reviewed it under the bank's "six-eye" procedure, and all three believed one field was enough. The software warned that funds would leave the bank, but not how much. The checker clicked yes, thinking of the interest.

Three people checked the form, and none of them saw the effect. The rule lived in a manual. The screen asked for the system's settings, when the task in plain words was "pay the interest, keep the principal". Its warning left out the one number that mattered.

Your admin probably doesn't move loan principal. It may still cancel 200 visits or credit a customer's account with one click. Build those actions this way:

1. Offer the task as one choice, such as "pay interest only", and let the software set the fields.
2. Before the final click, show the effect in plain words: what will happen, to how many records or how much money, and whether it can be undone.
3. Send reviewers the effect, not the form. A reviewer who only sees the form is a rubber stamp, the problem we describe in human-in-the-loop AI.
4. Record a correction as a new entry that points at the mistake, so the history keeps both.

When you don't need a custom admin

Often you don't. A custom admin pays off when your whole team works in it all day and the process behind it is how you win work. Otherwise, try these first.

• If you run on a product such as Shopify, HubSpot or Xero, its admin was built for thousands of firms like yours. It improves without you paying for the work. Configure its dashboards and saved views first. We make the same case for sales teams in custom CRM vs HubSpot or Pipedrive.
• If your questions are about trends in data you already hold, a reporting tool such as Power BI, Looker Studio or Metabase can answer them.
• If a couple of trusted, technical people fix records now and then, a generated admin like Django's, or an internal-tool builder such as Retool, is enough. That is the use Django's documentation recommends.
• If one person keeps the records in a spreadsheet and it works, keep the spreadsheet.

How to check an admin before you accept it

Do these checks yourself, rather than leaving them to the builder.

1. Ask for the question list. Each daily question should be answered on the first screen, or one click from it.
2. Run the glossary test. Ask the person who will use the admin most to find three things without help. Rename every word they stop at.
3. Load real volume. With a copy of a year's data, time how long it takes to find a customer from a phone number.
4. Break it on purpose. Log in as the most junior role and try to open something that role shouldn't see. Switch off the network and read what the dashboard says.
5. Rehearse the riskiest action on a test copy. Read the confirmation aloud. It should say what will happen, to what, and whether it can be undone.

A month after launch, ask whether anyone keeps a spreadsheet beside the admin. A side spreadsheet is a question the admin doesn't answer yet.

Start with a week of questions

This week, note every question you ask about the business: to your staff, to your accountant, to yourself at seven in the morning. Write each one in your own words, with how often it comes up. After five working days you'll have fifteen or twenty, and most will repeat.

That list is the most useful page you can give anyone building your software. If a builder shows you screens before asking for it, hand it over and ask which screen answers each question.

Questions

Should the admin dashboard work on a phone?

For some people, yes. An owner checking today's numbers, or an engineer looking at their own jobs, will reach for a phone. Someone entering invoices all day wants a large screen and a keyboard. Design each person's first screen for the device they actually use, and test it there. A full dashboard squeezed onto a phone rarely works. A phone screen with the three things that person needs usually does.

Can we add screens later, when new questions come up?

Yes, as long as the records underneath hold the facts the question needs. 'Which jobs are late?' is easy to add later if the software stores due dates. 'Why are they late?' is not, unless someone records a reason at the time. So when you write your question list, note what each answer depends on, and make sure the software records it from day one, even if the screen comes later.

Who owns the admin once it's built?

You should. When we build, the code, the hosting and the documentation sit in your company's own accounts and are yours at handover. Ask any builder for this in writing. Check too that you could hand the system to another developer without asking the first one's permission.

How we wrote this: drafted with AI, then checked and edited by the people who build our projects. Figures come from our own work or from the linked sources.