Planning a Dashboard: Before You Add a Single Card

Every genuinely calm dashboard this course has ever built started with a plan on paper, not with clicking "Add card" and hoping structure would somehow emerge afterward. This lesson builds that plan properly, classifying every entity, choosing its audience, and deciding its view and card type before touching the dashboard editor at all.

Questions worth asking before the first card

Before adding any entity anywhere, ask genuinely who needs to see it, a household member glancing by, an admin configuring something, or nobody at all outside an active diagnostic session. Then ask what they'd actually do with it, simply glance at a value, or tap something to change a state, since a value-only entity belongs on a considerably simpler card than one meant to be actively controlled. Finally ask how often it changes and how urgently, a slowly drifting temperature reading deserves a different treatment than a rapidly blinking countdown timer. These three questions, audience, action, and urgency, genuinely apply to every single entity you'll ever place on any dashboard this course builds, and skipping them is precisely how a dashboard quietly drifts into clutter over time.

Classifying entities H / A / T / N

This course uses a genuinely simple four-letter classification for every entity, H for Home, meant for household members and shown simply and calmly, A for Admin, meant for configuration and shown with more technical detail, T for Technical, meant for hardware-level diagnosis like ESPHome or Zigbee link quality, and N for none of the dashboards at all, entities that only ever matter inside an automation's own logic. Most entities genuinely earn exactly one letter, though some, like input_boolean.test_mode_hallway, might reasonably earn two, a simplified version on Home during genuine testing and a full version on Diagnostics for actually debugging it. Writing this single letter next to every entity in your notebook is the fastest way to see your whole dashboard's shape before building a single card.

Three layers of dashboards

Corresponding directly to the H/A/T/N classification, this course organizes actual dashboards into three layers, a Home dashboard for daily living, an Admin dashboard for configuration and oversight, and a Diagnostic dashboard, the very one Module 12 already built, for active troubleshooting. These aren't necessarily three separate Home Assistant dashboards technically, they might instead be three views within one dashboard, but conceptually they're genuinely distinct enough to plan and reason about entirely separately, exactly as this lesson does one at a time below.

The household member's dashboard

A household member's dashboard genuinely shows only H-classified entities, simple tiles and buttons, calm colors, no raw entity_ids visible anywhere, and no more than a handful of cards per view so nothing feels overwhelming at a glance. This is genuinely the dashboard a guest could look at and understand within seconds, lights, a couple of scenes, maybe a temperature reading, entirely free of the timers, helpers, and diagnostic detail that make the rest of this smart home actually work underneath.

The admin's dashboard

An admin's dashboard genuinely shows A-classified entities, helper values with their raw entity_ids visible, automation last-triggered timestamps, and shortcuts into the areas and entities lists Module 13 will lean on repeatedly. This view assumes real familiarity with how the system works, it's genuinely fine to show input_number.office_temp_threshold's exact entity_id here even though that same value appears as a friendly, unlabeled slider over on the Home dashboard.

The diagnostic dashboard

Module 12 already built this one, T-classified entities grouped by concept, Helpers, Timers, Scenes and Scripts, Automations, meant to be opened only during an active troubleshooting session and otherwise left entirely alone. This lesson's plan doesn't rebuild that view from scratch, it simply confirms where it fits into the bigger three-layer picture, and a later lesson in this module revisits it directly to decide what to keep, what to hide, and what to move elsewhere now that a proper Home dashboard exists alongside it.

This course's proposed structure

Concretely, this course proposes one Home Assistant dashboard containing Start, Office, and Climate as Home views, an Admin view for configuration-level entities, and a Diagnostics view carried over from Module 12, five views total inside one single dashboard rather than several separate ones. This structure isn't the only reasonable way to organize things, but it's genuinely the one every remaining lesson in this module assumes, so following it directly makes each later lesson's instructions apply cleanly to your own actual setup.

Four types of elements on a dashboard

Beyond H/A/T/N, it's genuinely useful to separate entities by what kind of element they need, a status to glance at, a control to tap, a trend to watch over time, or a shortcut into something else entirely, like a script or scene. A temperature sensor is genuinely a status, a light switch is a control, several days of temperature history is a trend, and a "Movie Night" scene button is a shortcut, and matching each entity to its true type is exactly what the coming lesson on card types builds on directly.

A limit for the Start view

This course genuinely caps the Start view, the very first screen a household member sees, at eight cards, forcing a real prioritization decision rather than letting every mildly interesting entity crowd onto the one screen everyone opens most often. Eight is genuinely a deliberate, somewhat strict number, and a later lesson dedicated entirely to the Start view will return to exactly this limit and how to actually meet it honestly.

A worked decision: input_number.office_temp_threshold

Walking through this one real entity end to end, its audience is genuinely both H and A, a household member might nudge it occasionally, while an admin actually configures its range, its element type is a control since it's meant to be adjusted, and it belongs on the Office view's Home layer as a plain slider, and on the Admin view labeled with its full entity_id for anyone actually configuring the underlying automation. Working through one entity this thoroughly, rather than rushing quickly past it, is genuinely the exercise every remaining entity in your own home deserves before this module reaches the point of actually building cards.

A decision table, the course's own template

A genuinely simple table with columns for entity, H/A/T/N classification, element type, and destination view covers everything decided so far for any entity in a single readable row. Filling this table out for every entity across Modules 9 through 12 before opening the dashboard editor at all turns what could be a chaotic, reactive process into a calm, considerably more mechanical one, simply add the card the table already told you to add, in the view the table already decided.

The plan written as YAML comments

For anyone genuinely comfortable in YAML, the same plan can live as a block of comments at the top of the dashboard's YAML file, one line per entity, its classification, and its destination, right alongside the actual configuration it describes. Keeping the plan physically close to the thing it describes, whether that's a notebook page or a YAML comment block, makes it considerably more likely you'll actually keep it updated as the dashboard evolves.

A plan is not genuinely forever

Nothing about this plan is genuinely permanent, new entities will arrive as future modules add energy monitoring, security sensors, and multimedia devices, and some current classifications will honestly turn out wrong once you actually live with the dashboard for a few weeks. Treat this plan as a confident, well-reasoned starting point rather than a rigid, unchangeable contract, and revisit the table itself whenever a new entity or a changed habit makes the current answer feel genuinely off.

What can genuinely go wrong

The most common mistake at this planning stage is genuinely skipping it entirely and diving straight into the card editor, only to discover several lessons later that the Start view has quietly grown to twenty cards nobody planned for. A close second is classifying every entity as H "just in case," which defeats the entire purpose of the classification, be honest and specific about who actually needs each entity, not generous.

What this lesson deliberately doesn't do yet

This lesson genuinely doesn't touch the dashboard editor at all, doesn't pick specific card types, and doesn't decide exact section layouts, all of that is deliberately left for the lessons immediately following, once view types and card types have both been properly introduced. Planning and building are kept as two genuinely separate steps throughout this entire module, exactly as trigger-condition-action stayed separate from testing back in Module 11.

An exercise: your own plan table

Build the entity, classification, element type, destination view table described above for every genuine entity you've created across Modules 9 through 12, following the office_temp_threshold example's level of detail for at least five entities before allowing yourself to move faster on the rest. This table becomes the single reference every remaining lesson in this module will ask you to consult before adding a card anywhere.

Why planning on paper beats planning in the editor

The dashboard editor genuinely wants you to add something the moment you open it, a card picker sitting right there, tempting you to fill blank space immediately rather than think first. A notebook page or a spreadsheet has no such pressure, it sits patiently while you genuinely work through every entity's classification, element type, and destination without the editor's blank-canvas anxiety nudging you toward premature decisions. This is genuinely why this lesson insists on a paper or text-based plan completed in full before the editor ever opens, the tool itself is simply the wrong environment for the thinking this lesson asks you to do.

A second worked example: scene.movie_night

Walking scene.movie_night through the same four questions, its audience is genuinely H only, a household member is exactly who taps this button, an admin never needs a separate view of it since there's nothing to configure beyond the scene itself. Its element type is genuinely a shortcut, one single tap replaces several individual light adjustments, and its destination is the Start view, provided the eight-card limit still has room, or otherwise the Office view where it conceptually belongs. Notice how much simpler this decision genuinely was than office_temp_threshold's, some entities resolve in mere seconds once you know the four questions well, and recognizing which entities are simple like this one versus which deserve more careful thought like a shared threshold is itself a genuinely useful skill this exercise builds.

A third worked example: timer.hallway_off

timer.hallway_off is genuinely almost entirely T, a household member has no real use for watching a thirty-second countdown, and even an admin rarely needs it outside active testing, it belongs squarely on Diagnostics and nowhere else at all. Its element type is a status, a live countdown value, not a control, since nobody should genuinely be starting or cancelling this specific timer by hand outside of a debugging session. This example is deliberately included to show that not every entity needs to appear on multiple views, some genuinely belong in exactly one single place and staying disciplined about that is precisely what keeps the Home and Admin views from slowly absorbing every diagnostic detail this course has built.

Grouping entities before assigning sections

Once every entity has a row in your plan table, a genuinely useful next step is grouping rows that share a destination view into rough clusters, everything Office-and-H together, everything Diagnostics-and-T together, and so on. These clusters are directly what will genuinely become sections once actual cards get built, a Climate cluster becomes a Climate section, a Lighting cluster becomes a Lighting section, meaning the grouping work happening right here on paper directly determines the exact section headings you'll type into the editor several lessons from now.

Why classification sometimes genuinely changes over time

An entity's honest classification can genuinely shift as your comfort with the system grows, office_temp_threshold might start as A-only while you're still nervous about household members touching it, then graduate to H once you trust the range you've configured and the household has gotten used to seeing it. Revisiting the plan table every few months, rather than treating it as something decided once and never revisited again, keeps the dashboard's audience boundaries genuinely honest and matched to how your household actually behaves rather than how you originally guessed it might behave.

A hands-on exercise: reviewing your table with fresh eyes

Once your plan table genuinely covers every entity from Modules 9 through 12, step away for at least a full hour, then reread it fresh and ask honestly whether any H classification was really just wishful thinking, and whether any N classification actually deserves a spot somewhere after all. This genuinely second pass, done deliberately after a real break rather than immediately, catches the exact classification mistakes that are hardest to see while you're still deep in the first draft of the table.

Planning for entities that don't exist yet

It's genuinely worth leaving a few deliberately blank rows in your plan table for entities you already know future modules will introduce, energy monitoring, security sensors, multimedia controls, rather than treating this table as if Modules 9 through 12 represent the whole smart home forever. Sketching even a rough guess now, "energy entities will likely be H and A both, shown as a small usage summary," costs almost nothing at all and makes the table genuinely feel like a living plan for the whole house rather than a one-time snapshot that future modules will simply have to work around awkwardly later.

Why two people might classify the same entity differently

There's genuinely no single universally correct classification for every entity, one household might want office_temp_threshold visible to everyone as H, while another household, perhaps with young children who shouldn't be adjusting thresholds, might genuinely restrict it to A only. This lesson's classifications are genuinely reasonable defaults for the course's own running example, not a rigid rule imposed on your actual home, and adapting them thoughtfully to your own household's genuine needs and comfort level is fully expected, not a deviation from the method at all.

The relationship between this plan and Module 12's dashboard

Module 12's diagnostic dashboard was genuinely built without this formal H/A/T/N framework, since that framework didn't exist yet at that point in the course, but reviewing it now through this lesson's lens, it turns out to already be almost entirely and correctly T-classified by instinct alone. That's a genuinely encouraging sign, the underlying judgment this lesson formalizes into four simple letters was already quietly guiding decisions back in Module 12, this lesson simply gives that same judgment a name and a repeatable process you can now apply consistently everywhere else too.

A note on time spent planning versus time spent building

It's genuinely reasonable to worry that a whole lesson, and a whole table, spent planning before building a single card is disproportionate, but the actual card-building work in the lessons ahead moves considerably faster precisely because this table already answered every "where does this go" question in advance. Every single minute spent here genuinely saves several minutes of hesitation and rework later on, when a half-built view suddenly needs an entity moved because its audience was never actually decided clearly ahead of time.

A closing thought before the view types lesson

Everything this lesson has built, the four questions, the H/A/T/N letters, the plan table, the section clusters, exists purely to make the next several lessons genuinely mechanical rather than creative guesswork performed under the pressure of a blank dashboard editor. Carry this table forward deliberately into every single remaining lesson in this module, it is genuinely the single most valuable artifact this lesson produces, considerably more valuable in the long run than any one specific card or view it will eventually help you actually build.

Key takeaways

What's next

With a genuine plan table in hand, the next lesson introduces the view types Lovelace actually offers, Sections, Masonry, Panel, and Sidebar, so each of your five planned views gets built using the type that genuinely fits it best.