Designing Home Assistant Dashboards: Lovelace Layouts, Custom Cards, and Views That Don't Fight You

This site has walked through installing Home Assistant on a Raspberry Pi, wiring in ESPHome sensors, adding Zigbee and Z-Wave devices, building a voice satellite, and bridging Matter and Thread — and every one of those guides ends with a working backend and a default auto-generated dashboard nobody actually wants to look at every day. The default view dumps every entity into an undifferentiated list, sorted by area at best, with no visual hierarchy between "is the front door locked" and "what's the humidity in the crawlspace." Home Assistant's dashboard system — internally called Lovelace — is genuinely capable of building something you'd actually want mounted on a wall or pinned as a browser tab. This covers how the pieces fit together and how to design one that's actually usable at a glance.

Lovelace's Building Blocks

ConceptWhat It IsDashboardA complete named view accessible from the sidebar — you can have multiple, e.g. one for a wall-mounted tablet, one for mobileViewA tab within a dashboard — group by room, by function (climate, security, media), or by who uses itCardAn individual widget — a thermostat control, a light toggle, a sensor graph, a camera feedYAML mode vs UI modeDashboards can be built visually through the editor UI, or authored directly as YAML for finer control and easier version control/copy-paste between installs

Stock Cards Worth Knowing

Entities card — the basic list card; fine for a quick view but the one that produces the cluttered default look when overused.
Glance card — compact icon-and-state grid, good for a room's quick-status row (temperature, humidity, motion, door state) at the top of a view.
Thermostat / climate card — a proper control widget rather than a text row, worth using anywhere a raw entities-card row would otherwise show a climate entity.
History graph / statistics graph — turns a sensor entity into an actual trend line instead of a single current number, essential for anything you'll want to eyeball over time (power draw, temperature, tank level).
Picture elements card — overlays live entity states and controls on top of a floor plan image; the highest-effort card to set up and the one that makes a dashboard look genuinely custom rather than auto-generated.
Conditional card — shows or hides another card based on an entity's state, e.g. only display the "garage door open" alert card when the garage door is actually open.

The Custom Card Ecosystem (HACS)

The Home Assistant Community Store adds a large library of third-party cards well beyond the stock set. A few that consistently show up in well-designed dashboards: Mushroom cards (a full family of minimal, consistently styled cards that replace most stock cards with a cleaner visual language), Mini Graph Card (compact sparkline-style trend cards that fit far more history into far less space than the stock history graph), Bubble Card (pop-up style controls that keep the main view uncluttered), and Layout Card or the built-in sections view for actual grid-based positioning instead of Lovelace's default single-column stacking. HACS itself isn't part of core Home Assistant and needs to be installed separately, but it's close to a default expectation in the self-hosting community at this point.

Design Principles That Actually Improve Usability

Organize by task, not by device type. A "Leaving the House" view showing door locks, garage door, lights, and thermostat together beats a view that groups all lights in one place and all locks in another — you rarely think "show me every light entity," you think "is the house secured."
Put alerts and anomalies above the fold. A conditional card showing only what needs attention right now (a door left open, a freezer running warm, a leak sensor triggered) at the very top of the main view means a glance actually tells you something, instead of requiring a scroll through forty entities to spot the one that matters.
Use graphs for anything you'd otherwise check twice. A single current-temperature number doesn't tell you if it's rising or falling; a small trend graph does, at no extra glance cost.
Separate the wall-mounted view from the phone view. A dashboard sized for a mounted tablet (like the CYD-based wall dashboard project on this site) benefits from large touch targets and minimal scrolling; a phone view can be denser since it's used more deliberately and less at-a-glance.
Resist adding every entity to the default view. Diagnostic entities, RSSI/uptime sensors from ESPHome devices, and rarely-touched configuration entities belong on a separate "admin" or "diagnostics" view, not competing for space with the things checked daily.

A Practical Starting Structure

A dashboard that holds up over time tends to follow a similar shape: one "Home" view with a status-at-a-glance row up top (conditional alert cards, a glance card for security-relevant entities) followed by room sections using Mushroom or glance cards for quick control; separate views per major room for the deeper controls that don't need daily visibility; a dedicated "Climate" or "Energy" view with history graphs for anything you're tracking over time (particularly relevant if you've also built the CT-clamp energy monitor project on this site); and a low-priority "Diagnostics" view for device health, RSSI, and battery levels that you check weekly rather than glance at hourly.

None of this requires touching YAML if the UI editor covers what you need, but for anything with conditional logic, templated values, or a layout you want to copy to a second dashboard or check into version control, editing the dashboard's YAML directly (Settings → Dashboards → the three-dot menu → Edit in YAML) is faster and more reliable than fighting the visual editor. A dashboard is never really "done" — the point of separating it from the auto-generated default is that it's supposed to keep changing shape as you add sensors and figure out what you actually check.

Related Guides

Loading_