Why Your Dashboard Feels Overwhelming (And How We Fixed Ours)
Our support dashboard put forty elements and six colors on one screen. Here is the progressive disclosure method that made it readable in three seconds.
Back to all articlesThe page nobody could read
We built an internal page for handling customer support. It pulled in the whole email thread, whether we had replied, how long someone had been waiting, which server the customer was on, their billing plan, our internal notes, the version numbers, and the tags. Every one of those facts was true and useful. We shipped it.
"Way too much information, at the wrong time, for things I don't care about. My eyes are just overwhelmed."
That was the verdict from the person who had to use it every morning. When we counted, the page put about forty elements in front of you before you scrolled. It used six colors. Six separate status badges competed for attention, and two of the colors meant two different things each. Purple meant "a reply is drafted" and also "this ticket was reopened." Green meant "we answered" and also "this customer pays us."
Nothing on the page was wrong. The page was still unusable.
The cause: building from the data outward
Here is the trap, and it is almost invisible while you are in it. You open the database table, see twenty columns, and ask yourself the wrong question: "where do I put these?"
Everything gets shown, because everything is true and you did real work to get it. Then everything gets a colored badge, because each fact felt important during the hour you spent building it. Nobody decides to make a cluttered screen. Clutter is what accumulates when no one is allowed to say no.
The cost lands on the reader. With everything shouting at the same volume, the eye has no entry point, so a person has to read the whole page to find any single thing on it. Researchers call the avoidable part of that extraneous cognitive load: mental work your design created, that the actual task never required.
The better question is the opposite one. Not "where do these fields go," but "what is the one decision this person is here to make."
Two questions and a budget
The method we adopted comes from a 1996 idea in information visualization that has aged extremely well: overview first, zoom and filter, then details on demand. We turned it into three steps a person can actually run on a Tuesday.
1. Write one sentence about the job
A person doing a specific thing needs to decide one specific thing. Ours: "Someone triaging support needs to decide who is waiting on me, and what do I say to them." If your sentence needs the words "and also," you have two screens, or one screen with two tabs.
2. Name the three second question
What must be answerable with no scrolling, no clicking, no reading of paragraphs? Exactly one question per screen. On the ticket page it was "does this need me right now, and what did they say?" Anything that does not answer that question is demoted by default. Most of the work is demoting.
3. Cap the glance layer at five things
Information lives on four layers. The glance layer is free to the reader, so it is the scarce one. Scanning costs attention. A click costs more. Navigating away costs the most.
The cap is the part that actually works, and it is the part most teams skip. To promote a sixth thing onto the glance layer, you have to demote something else. Without a fixed number, every field somebody is proud of drifts back to the top over the following six months, and you rebuild the same mess. A budget forces a trade instead of an addition.
Demoting is not hiding. Every lower layer needs a visible door: a chevron, a count, a row that reads "8 earlier messages" and shows the first line of each. Content tucked away with no sign that it exists is the classic way this goes wrong.
Color is a currency, not decoration
Our six colors were the loudest symptom. The fix was to write down what each color is allowed to mean, pick three, and delete the rest.
That left one question. If our replies are no longer blue and the customer's are no longer amber, how do you tell them apart? The answer turned out to be the useful insight of the whole exercise.
Roles are structural. Colors are exceptional.
"Ours versus theirs" is not an alert, it is a role, so it should be shown with structure. We indented our replies and gave them a thin left rule, the way a chat transcript does. It reads instantly, costs no color, and freed amber to mean the only thing that needed a color: somebody is waiting on you.
What actually changed
| Before | After | |
|---|---|---|
| Elements at a glance | ~40 | 5 |
| Status badges | 6 | 1 |
| Colors | 6 | 3 |
| Messages expanded | all 10 | 2 |
| Internal notes | same screen | own tab |
The internal notes moving to a tab is the change worth copying. Our diagnosis of the problem and the customer's own words are two different jobs. They were sitting at the same size, on the same screen, competing. Splitting them cost one line of controller code and made both easier to read.
We also added a rule to the review process. Anyone shipping a screen has to name what they removed or demoted. If that list is empty, the screen was not designed. It was accumulated.
This gets more important when AI writes the code, not less
Ask any AI coding tool to build a page for a table with twenty columns and you will reliably get a page with twenty columns on it. The model has no idea which three of them your warehouse manager checks every morning, and it will not ask. It optimizes for completeness, because completeness is what it can see.
That is worth being clear about, because we build software with AI for a living. Moving a business off spreadsheets and into a real database application is the easy half now. The half that decides whether anyone actually uses the thing is whether a person can open a screen and know what to do in three seconds.
So we stopped treating design as taste and wrote it down as a process, with a number in it. The team gets the same method whether a human or an agent is doing the building. The published version of that method is linked below, with the Rails and Tailwind code for the tabs, the collapsed rows, and the single status badge.
Get the software, and the screens people can read
We turn spreadsheets into database applications your team will actually open. If you are staring at a workbook that four people edit and nobody trusts, that is the conversation we have every week.
Turn your spreadsheet into an appKeep reading
- The full method, with code . The layer map, the tab pattern, the collapsed rows, and the color budget as Rails and Tailwind you can copy.
- Why formula generators won't save your spreadsheet . The same accumulation problem, one layer down in the data.
- Beyond the CRM Excel template . What breaks when a shared workbook becomes the system of record.