How to design an admin dashboard layout

What makes an admin layout different

An internal tool has a different job from a consumer app, and the layout has to follow the job. A consumer screen is designed to be understood in a few seconds, while an admin screen is designed to be worked in for an hour by someone who already knows the domain and wants to compare, filter and act on records. Density is not the enemy in that context. Untidy density is.

That changes what a hierarchy means here. The consumer answer to an important number is a large number with nothing around it, and the admin answer is a number with a comparison attached, because a total on its own is not information. It becomes information when you can see it against last week, against the target, or against the row above it. The mockup tutorial covers the mechanics of getting a frame populated.

• Density is acceptable, untidiness is not
• A number needs a comparison before it becomes information
• 1280 by 800 is the frame most internal tools live in
• Stat, Chart, Sparkline, Donut, Gauge and Table cover most of the screen

Note: A dashboard is not a collection of every widget you can find. It is the shortest path from a question to a decision, and anything that does not serve that path belongs on another screen.

Decide the one question the screen answers

Write down the question an operator opens this screen to answer. Which orders are late, which accounts need attention, which campaigns are below target. The wording matters, because a screen that answers its question with several numbers is a screen with no hierarchy, and the question tells you which of those numbers is the point.

Then put the answer at the top. A dashboard whose first row is a filter bar and a search field is asking the operator to work before it tells them anything, and most of them already know the filter they want. A filter is a control, and controls belong under the answer.

Keep the question narrow enough that one glance settles it. When the answer needs two figures to make sense, either they belong side by side in the headline row as a pair, or the screen is answering two questions and should be two screens.

• Write the question as a sentence before the layout starts
• The answer occupies the top band of the screen
• Controls sit below the answer rather than above it
• A screen answering two questions is really two screens

Note: If you cannot phrase the question, the screen is a report rather than a tool, and it will be read once instead of used daily.

Filter, list and detail in one hierarchy

Most admin screens contain the same three layers, and the layers want a fixed order. The filter layer decides which slice of the data you are looking at. The list layer holds the records themselves. The detail layer is the one record, opened beside the list or in a lower band of the page. Keeping them in that order means the operator always knows which layer they are reading.

The three layers need different treatments so they do not compete. Filters are controls and belong in a bar of small fields across the top of the list. The list is the work area and wants the most space. The detail belongs beside the list, and it should never cover it, because the operator needs the record and its neighbors visible at the same time.

• Filters, then records, then detail, in that order
• Filters in one horizontal bar of small fields
• Detail beside the list and never on top of it
• A main alignment of space spreads a filter bar across the width

1. Build the band order. Place the headline row, then the filter bar, then the records, in that order and in three separate containers.
2. Spread the filters. Give the filter container a horizontal direction and a main alignment of space so the fields spread evenly across the width.
3. Keep the records flexible. Let the list container stretch to take the height that is left, and place the detail beside it rather than over it.

Note: The dashboard layout guide covers the same three bands with a different set of example widgets.

Tables need a plan before they need columns

A table looks like a component and behaves like a product decision. Before you add a column, decide what the operator is scanning for: an identifier, a name, a watched figure, a status, a date, a person. Most tables need one of each, and a table showing every field a record happens to contain is a table nobody reads.

Order the columns by the scan and not by the data model. The identifier first, then the value being watched, then the status, then the date, with actions last. A table whose actions sit in the middle splits every row into two halves and slows down each pass through the data.

The Table component kind gives you the frame, and the rows are yours to design. Keep one row height for every row, put the same kind of value in the same column on every row, and align figures to the right so the decimal points line up. Right alignment for numbers is a small thing that makes a table of figures readable at a glance.

• Decide what is scanned for before you add any column
• Identifier, watched value, status, date, actions
• One row height across every row of the table
• Right align the figures so the decimals line up

Note: A table in a mockup is a picture of a table rather than a live grid. Nothing sorts or paginates, so the design is judged on the shape of the row and the order of the columns. The data table guide covers the row design in more detail.

Keep density readable

A dense screen fails on rhythm long before it fails on color. Every gap on the screen should come from the same spacing scale, so a gap of 8 pixels between two related things and 24 pixels between two unrelated ones reads without any explanation. When the gaps are scattered, a dense screen turns into a wall of small text.

Weight and case do the rest of the work in a dense screen. Column headers in a smaller, muted style above regular cell text is enough to separate them. Upper case labels for section headings are common in internal tools, and they work there because the rest of the screen is quiet, but they fail on a consumer screen where the content has more voice.

• Every gap on the screen comes from the same spacing scale
• Small muted column headers over regular cell text
• One accent color for the element that matters
• Status colors only where a status actually exists

Note: The component guide covers how to keep a table row identical across screens, which is what stops a dense layout from drifting apart screen by screen.

Review with real data lengths

The fastest way to break a dashboard layout is realistic data. A table of short names fits into any column, while a column of names like Northwind Logistics International is a different layout. Build the screen with the longest values you actually expect, and the column widths and row heights will settle themselves without a separate design pass.

Watch three specific things. A long cell value that should be truncated rather than allowed to push the column wider. A status that has to be a word and not only a color. And a figure much larger than the one you designed with, which is what happens the first time a real month of data arrives.

• Build the screen with the longest values you expect to see
• Decide for every cell whether it truncates or wraps
• Statuses carry a word, not only a color
• Check the frame at 1280 wide and again at 1440

Note: Presenting the frames walks them in order with the keyboard, which is a quick way to show the structure of a dashboard without a styling discussion getting in the way.

A checklist you can reuse

• The dashboard is built in a 1280 by 800 web frame
• The question the screen answers is written as a sentence
• The headline row answers that question without any scrolling
• Filters, records and detail appear in that order on the screen
• Every row of the table shares one height
• Figures in the table are right aligned so the decimals line up
• Every gap on the screen comes from one spacing scale
• The layout was reviewed with the longest real values in it

Common mistakes to avoid

• Putting the filters first. A filter bar at the top asks the operator to work before the screen tells them anything. Move the answer above the controls.
• A column for every field. Tables showing every attribute a record has are tables nobody scans. Keep the columns the operator reads and move the rest to the detail panel.
• Color carrying the meaning on its own. A red cell with no word in it means nothing to anyone who cannot see the color, and it breaks in a printed export. Put the word next to the color.
• Scattered gaps in a dense screen. Random spacing turns density into noise. Take every gap from the same scale before calling the screen crowded.
• Actions in the middle of a table row. A row that breaks in two slows every pass through the data. Put the actions at the end of the row, where the eye finishes.

Frequently asked questions

What size frame should an admin dashboard use?

The web frame at 1280 by 800 is the right default, because that is the width of most laptops. The inspector also offers Desktop at 1440 by 900 and Tablet at 820 by 1180. Build at 1280 and check at 1440, where a table can usually take one more column.

How many stat cards should a dashboard show?

Three to five is the working range, and the count should follow the question rather than the space. If your sentence needs six figures to be answered, either it covers more than one screen or some of those figures are detail. The Stat card component gives each one the same shape.

Should the table be the main element?

Often, but not always. When the question is about a handful of records, the table is the answer and it should dominate. When the question is about a trend, a chart belongs above it and the table becomes the evidence underneath. Deciding this first stops a table taking the whole screen by default.

How do I check that a dense screen is readable?

Zoom to 100 percent with Ctrl/Cmd+0 and read the smallest text on the screen without moving closer to it. Then check the same frame in the dark theme, where muted column headers lose contrast first, and export the frames as PNG at 2× to look at the file people will actually be sent.

This guide is part of the design foundations collection. For the wider product tour, read the complete Canvasola guide, and keep the keyboard shortcut cheat sheet open while you work.