Big Idea

The argument in one line.

A dashboard that looks good but ignores the shape of its data, the frequency of its actions, and the invisible states binding it together will always feel amateur regardless of surface polish.

Who This Is For

Read if. Skip if.

READ IF YOU ARE…

You are building a dashboard for a side project, portfolio, or client and want it to look like you have shipped real software before.
You use Figma or a component library and can get a table to look clean, but something still feels off when you compare it to Notion or Linear.
You are vibe-coding admin UIs with AI tools and want a checklist to catch the obvious tells before shipping.

SKIP IF…

You already work as a product designer on data-heavy tools — this is entry-level fundamentals.
You are building a marketing landing page, not a data-displaying application.

TL;DR

The full version, fast.

Most beginner dashboards fail in the same three places: the UI is styled generically instead of being shaped by the data (chips for enums, right-aligned numbers, timelines for time-series), secondary actions are always visible instead of revealed progressively (popovers, hover states, onboarding sequences), and the invisible layer is missing entirely (tooltips, copy chips, hover panels, drawers). These are not polish problems — they are structural. Fixing all three requires thinking about what the data IS, when an action is needed, and what states exist that the user never sees until they look.

Free for members

Chat with this breakdown — free.

Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.

Create a free account →

Chapters

Where the time goes.

00:00 – 00:22

01 · Cold open — designing vs. orchestrating

The core distinction: looking good is not the same as working well. Three tells teased.

00:22 – 02:25

02 · Flaw 1 — data not driving the form

Tables styled generically vs. shaped by data type. Chips for enums, right-aligned numbers, timelines for time-series, color from data meaning, avatars for who-recognition, charts as rollups.

02:25 – 04:28

03 · Flaw 2 — progressive disclosure ignored

Share/remove actions permanently in the table vs. tucked into popovers and hover states. Spectrum of explicitness framework. Onboarding as the extreme case.

04:28 – 04:58

04 · Sponsor — Mobin

Curated UI screenshot library with new MCP for AI-dev workflows.

05:00 – 06:15

05 · Flaw 3 — missing invisible UI

The ratio of hidden to visible UI in a mature dashboard. Copy chips, comment indicators, hover panels, tooltips. Tooltips specifically called out as missing from almost all beginner dashboards.

06:30 – 06:59

06 · Wrap-up and CTA

Three-flaw recap. Mobin link. Figma assets link.

Atomic Insights

Lines worth screenshotting.

Department and status fields are enums — they belong in chips, not raw text columns, because there are only a fixed number of valid values.
Right-aligning numbers in a table is not a style preference — digits align by place value, making comparison instant.
Time-series data does not belong in a table; a timeline layout makes the temporal dimension visible without hunting through a timestamp column.
Color in a dashboard should come from the data, not from a design system sprinkle — red means urgent because the action IS urgent.
Progressive disclosure is not about hiding things; it is about sequencing them so the user is never overwhelmed before they need a feature.
The spectrum of explicitness runs from always-visible global button to icon-on-hover — the right position depends on how often the action is needed.
A six-bullet onboarding modal is almost always forgotten the moment it is dismissed; a single tooltip pointing at the most important action is not.
Tooltips are missing from nearly every beginner dashboard, even though they are the cheapest way to handle ambiguous icons or labels.
New features almost never need a dedicated page — they need their hidden states designed and their trigger surfaces thought through.
The ratio of invisible UI to visible UI in a mature dashboard is not small — copy chips, comment indicators, hover panels, and drawers can outnumber permanent elements.

Takeaway

Three checks that reveal a dashboard is actually finished.

WHAT TO LEARN

A dashboard that passes a visual review can still fail all three of these checks — and each one is invisible until you know to look for it.

Every data column has a type. Enums belong in chips, numbers belong right-aligned, time-series data belongs in a timeline — matching the shape of the data to the shape of the UI is the first skill to develop.
Color in a dashboard should be earned by the data, not applied for aesthetics. Red draws the eye because the action is urgent; an avatar speeds up who-recognition because the brain processes faces faster than names.
Progressive disclosure is not about hiding things to be clever — it is about making sure the user is never confronted with more than they need at the moment they arrive.
The spectrum of explicitness is a calibration tool: the more frequently an action is needed, the more permanently visible it should be. A remove-user button belongs on hover; a search box belongs at the top.
Onboarding is progressive disclosure applied to the entire product — one tooltip pointing at the most important action will be remembered longer than a modal listing six features.
Tooltips are the most common missing element in beginner dashboards. Every ambiguous icon and every label that could mean two things needs one.
The count of hidden UI elements in a mature dashboard — hover states, copy chips, drawers, modals, comment indicators — is not small. If a design does not account for them, it is not a finished design.

Glossary

Terms worth knowing.

Progressive disclosure: A design pattern where secondary or advanced functionality is hidden until the user needs it, revealed through hover, click, or progression through a flow rather than displayed permanently.
Spectrum of explicitness: A framework for deciding how visible a UI action should be, ranging from a permanent global button down to an icon that only appears on hover, calibrated to action frequency and importance.
Data-driven form: Designing UI elements based on the actual type, cardinality, and temporal nature of the data being displayed, rather than applying generic table or card layouts regardless of content.
Invisible UI: Interface elements that only appear in secondary states such as hover, focus, scroll, or swipe — including tooltips, copy chips, comment indicators, drawers, and modals. Absent from most beginner builds.
Enum field: A data column with a fixed set of valid values such as department or employment status. Best rendered as chips or badges rather than raw text because the options are predictable and scannable.

Resources

Things they pointed at.

04:28toolMobin ↗

Quotables

Lines you could clip.

00:00

“Designing a dashboard isn't that hard, but orchestrating one is.”

Clean one-liner that creates immediate tension and promises a resolution.→ TikTok hook↗ Tweet quote

05:00

“UI is as much about what you can see as what you can't see.”

Quotable principle, zero context needed.→ IG reel cold open↗ Tweet quote

06:15

“There's so much UI that's hiding that's important for a finished product.”

Clean close to the invisible-UI section, works as a pull-quote.→ newsletter pull-quote↗ Tweet quote

The Script

Word for word.

Read-along

Don't just watch it. Burn it in.

See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.

metaphor

Designing a dashboard isn't that hard, but orchestrating one is. And there's a massive difference between UI that might look good and UI that actually works when you start using it. So whether you're vibe coding a new project or creating a piece for your portfolio, we're covering the three tells that immediately give away you've never built one before and exactly how to fix each and every one.

The one thing that all dashboards have in common is they're built to display data. So if we focus on building the UI around the data we need to display, we end up with a much more usable experience. For example, take a look at this table.

It seems relatively logically laid out, but clearly nothing is driving the form. But for example, if we turned the department and employment into chips or took these numbers and right align them, things start to shape up. We do this because there's only a set number of departments or employment statuses, and we right align the numbers so the digits align by place value.

Then we can augment this further by truncating long text to give more breathing room to the other columns or even shade out rows of the table that are inactive or deactivated. And when we compare them before and after, we can clearly see which is more visually appealing to look at and which is letting the data drive the form.

And the same is true for data that probably shouldn't even be in a table in the first place. This table definitely works. Don't get me wrong.

We could use it. But the time delineated nature means this isn't the best format and we aren't letting the data determine the shape of the UI. Instead, if we were to arrange this as a timeline, it starts to become a lot easier to follow rather than a time sorted table.

This form factor could then be tucked into a sidebar pop out or made wider as a second column beside the table, but either way, now we're letting the data drive the UI. And color is a very important consideration when we do start designing these tables. Landing pages, you can get away with a lot, but dashboard colors shouldn't just be sprinkled in to look nice.

It should come from the data itself. In these activity logs, the red icon in the chip draws your eye to it because the action is urgent. The avatar is there because your eye can associate who did what way faster than reading a name in the column.

And once you're thinking that way, it's a pretty simple jump to adding a chart to roll up the data into a summary. Because this data has a time dimension and a chart shows you that instantly instead of making hunt through a time stamp column just like our previous example.

Often when I talk about hierarchy, I use examples like this where this card has poor hierarchy and this card has strong hierarchy. But there's another type of hierarchy based on what you show and what you hide and it's called progressive disclosure.

For example, this share functionality isn't permanently ingrained in the side of the table since it's not that frequently accessed and frankly not important enough. Instead, we tuck it into a popover so we don't have to rip the user to an entirely different page. And within this popover, the primary action is of course the search box, which is why it's immediately visible at the top.

A secondary action like removing a user isn't overly important. So instead of ingraining it in the UI, we show the remove button on hover along with the tool tip. We could be more explicit by always having them or even still more explicit by having the full label present.

But since we're tight on space and removing a user sharing isn't a main action, we progressively reveal it as soon as the user starts to look for that functionality. And what I've just described is called the spectrum of explicitness, where a global always visible share button is quite high, whereas an icon to copy a cell on hover is much lower on that same spectrum.

And Apple does the same thing really well in their reminders app. On swipe left and right, it reveals useful but secondary actions compared to actually checking off the reminder. And if you think about it, this is exactly what an onboarding is.

When a user lands on your app for the first time, they shouldn't be staring at a fully loaded dashboard wondering where to start. A good onboarding might start with a single tool tip pointing at the most important action. Once they've done that, maybe a second one appears or a simple checklist in the corner.

You're not hiding functionality, you're sequencing it so that the user is never overwhelmed. Compare that to explaining the entire product in a modal with six bullet points the second you log in and then instantly forgetting the moment you dismiss.

And the best way to get a feel for how to handle this, the progressive disclosure, the spectrum of explicitness, and the onboarding flows is to look at a lot of real software, which is exactly what today's sponsor, Mobin, makes dead simple.

They've curated hundreds of thousands of screens from real mobile and web apps. So instead of piecing together an onboarding flow, you can search through hundreds of them. They also just launched an MCP, so you can pull Mobin's full library directly into your AI development.

I had to throw together a mood board for a banking app with real screenshots and actual links in about two minutes. If you're interested in checking it out, the very first link down below will get you 20% off.

A really important concept that AI has a hard time wrapping its figurative head around is that UI is as much about what you can see as what you can't see. Like, for as much as this table works well and looks good, additional functionality in such a dense design needs to come from parts of the UI that you can't immediately see.

This could be as simple as a copy chip over the cells or perhaps comment functionality with a small triangle indicator. Here's all the UI that you can see and then this is all of the UI that you can't immediately see but is still there. And it's not a small amount.

We need it all to actually make any of this table function. Putting the individual pieces together, the spacing, the sizing isn't that hard, but orchestrating them does require some thought. And this applies just as much to the smaller items as it does to the larger drawers, modals, and elements that have hidden components and states.

It makes it easier to see that new features or elements often don't require a dedicated page just to be better thought through how they're implemented. But this isn't just true for dense UI like tables. Think about moments in software that you almost never see.

An announcement about a newly launched feature or an onboarding pop up explaining how part of the product works. But what's missing pretty much unequivocally on all beginner dashboards are tool tips.

We have to assume that the user won't understand all of our icons or that they might want more details or information on ambiguous labels. It goes to show that there's so much UI that's hiding that's important for a finished product. And with that, those are the three subtle flaws that'll give away that you've never built a dashboard before.

The data driving the form, the right things hidden until they're needed, and all the invisible UI that makes the whole thing actually function. If you wanna check out Mobin, it'll be the very first link down below. You can get the link to all of the Figma assets using this video down there too.

Thank you so much for watching, and I'll see you in the next one.

The Hook

The bait, then the rug-pull.

Designing a dashboard isn't that hard — orchestrating one is. The distinction, landed in the first sentence, is the whole video: individual components are easy to make look good, but real dashboards are systems of data shapes, action hierarchies, and invisible states that only show up when someone actually uses the thing.

Frameworks

Named ideas worth stealing.

03:25model

Spectrum of Explicitness

Always-visible global button (most explicit)
Popover triggered by button click
Button visible only on row hover
Icon-only on hover (least explicit)

A linear scale for deciding how visible a UI action should be, calibrated to action frequency and importance.

Steal forAny dashboard or table UI where secondary actions need to exist but should not clutter the default view.

00:22concept

Data-Driven Form

Design UI element shapes based on what the data actually IS — enum fields get chips, numbers get right-alignment, time-series gets timeline layout.

Steal forTable and card UI design reviews — run each column/field through what type is this before choosing a renderer.

CTA Breakdown

How they asked for the click.

VERBAL ASK

06:30link

“If you wanna check out Mobin, it'll be the very first link down below. You can get the link to all of the Figma assets using this video down there too.”

Dual CTA — sponsor link first, then free Figma assets as a value-add. Low-pressure delivery.

MENTIONED ON CAMERA

04:28toolMobin ↗

Storyboard