A Home Assistant dashboard's job is to answer the question the grower is asking right now. A dashboard that answers ten questions the grower is not asking, while burying the one they are, is worse than no dashboard. For agricultural operations, the working reality is specific: growers check dashboards on phones while standing in the greenhouse with dirty hands, often with poor signal, often in bright sun. They need to see zone conditions in fifteen seconds, spot anomalies at a glance, and drill into detail only when something warrants attention. They need different views for different moments — a quick-check in the morning, a detailed review in the evening, a specific propagation-room screen when that room is active, a read-only view for visiting staff. This page covers the design principles that produce dashboards people actually use: mobile-first layouts, the quick-check view as the primary interface, information hierarchy that leads with what matters, role-based access, dark-mode considerations for field use, and the specific design mistakes that make dashboards a distraction rather than a tool. Platform-specific implementation — how Lovelace views, sections, and cards actually work — is covered in the [Lovelace Fundamentals](/home-assistant/dashboards/lovelace) page; this page is about design decisions that apply regardless of the platform specifics.
Before designing dashboards.
Prerequisites from earlier work:
The sensor and integration work is done. A dashboard surfaces data and controls that already exist. If the underlying integrations are not in place, the dashboard has nothing to show. The Getting Started and Integrations sub-sections cover that foundation.
Areas and naming conventions set. Per [Organizing Home Assistant for a Farm](/home-assistant/agriculture/organizing). Dashboard cards reference entities by name, and the quality of names directly affects dashboard readability. A dashboard showing `sensor.temp3` is worse than the same dashboard showing `sensor.greenhousezone1temperature`.
Template sensors in place for derived values. Per [Template Sensors](/home-assistant/automations/templates). Dashboards for agricultural operations often show VPD, DLI, and other calculated values more prominently than their raw inputs. The templates that produce those values need to exist before the dashboard can show them.
A clear sense of who uses the dashboard and when. The same person uses dashboards differently at different moments. The same operation has different users (the owner, the production staff, the occasional visitor) who need different views. Before designing anything, the question is worth asking explicitly: who is looking at this, when, and what do they need to know.
The quick-check view.
The single most important dashboard in any agricultural Home Assistant deployment. It is the one the grower opens thirty times a day, often for five seconds at a time, to confirm nothing is wrong. Everything else flows from this.
The fifteen-second test. A useful quick-check view answers "is everything okay right now?" within fifteen seconds. Longer than that and growers stop using it; they drift to checking individual sensors or automations instead.
What the quick-check shows. The minimum that tells the grower whether immediate attention is needed. For most operations:
- Current conditions in every zone at a glance — a temperature and humidity value per zone, laid out so the grower sees all zones on one screen. - Any active alerts. These should be visually obvious — color, size, position at the top. A dashboard with a red block saying "Zone 2 over temperature threshold" communicates faster than a green dashboard that says nothing about a problem. - The most recent significant event — last alert, last irrigation cycle, last automation that ran. Three or four lines of the most recent activity gives context about whether the system is doing its job. - System health in one indicator. A green dot for "all sensors reporting, all automations enabled, no stuck states"; red for anything that needs investigation. The grower should not need to audit the system to know whether it is healthy; a single glance should answer.
What the quick-check does not show. Detailed graphs, full automation lists, entity configurations, anything that requires reading rather than glancing. Those are the detailed-analysis view's job.
Layout for the quick-check. Mobile-first, because that is where it lives. Zones laid out in a grid that fits the phone's portrait orientation. Alerts span the width and stand out. Health indicator top-right or top-left where the eye lands first. Large values — the temperature numbers big enough to read at arm's length.
The emotional design of the quick-check. The dashboard should feel calming when things are fine and attention-getting when they are not. A steady green cast, big readable numbers, and quiet status when the operation is nominal. When something is wrong, the grower should see the problem before they see anything else.
The detailed analysis view.
The dashboard the grower uses in the morning and evening, when there is time to actually look at the operation rather than just confirm it is okay.
Purpose. Review the last day's patterns. Spot trends that are not yet problems. Plan the coming day's work. Investigate anomalies that the quick-check flagged.
What the detailed view shows.
- History graphs for the zones — temperature over the last 24 hours, humidity, VPD, soil moisture, light. Graphs let the grower see patterns that a single current value cannot convey. A zone whose temperature is currently fine but oscillated wildly overnight is a zone worth investigating. - Per-zone detail — current conditions with more depth than the quick-check. Actual setpoints, target ranges, time since last irrigation, accumulated DLI so far today, distance from targets. - Automation status — which automations fired in the last period, with timestamps. Useful for confirming that the scheduled irrigation actually ran, that the supplemental lights came on when expected, that the photoperiod transition happened. - Equipment status — current state of valves, fans, heaters, supplemental lights. Whether commands match physical reality (via verification templates or sensors). - Alert history — the last few days of alerts, even resolved ones. Recurring alerts suggest a threshold needs adjusting or a real problem needs fixing.
Layout for the detailed view. Less mobile-constrained; this view is often consulted from a tablet, laptop, or desktop. Graphs can be larger. More information per screen is acceptable. The information density is still a design choice — too much still overwhelms.
Per-zone versus aggregated detailed views. Operations with many zones often want both: an aggregated view that shows every zone's graphs side by side, and a per-zone view that drills into one zone's detail. Both are useful; neither substitutes for the other.
Role-based views.
Different people need different dashboards.
The owner or primary grower. Needs the full view — all data, all controls, the quick-check and the detailed analysis and everything else. Generally has administrator-level access to Home Assistant.
Production staff. Needs the controls that are part of their work (start irrigation, acknowledge an alert, note that a task is complete) without the settings and configuration that are not. A staff dashboard is simpler and more focused than the owner's dashboard. It may have no access to automations, setpoints, or entity configuration — just the day-to-day operational controls.
Visitors. Growers hosting other growers, extension agents, or students benefit from a read-only view that shows the operation without risk of accidental changes. A "visitor mode" dashboard with current conditions and some graphs, but no controls, serves this purpose.
The field technician. When equipment needs maintenance, a technician may need a dashboard focused on that specific equipment — the pump's recent run history, the valve's state, the sensor's diagnostic values. A technician-specific dashboard points at one area and provides the specific information needed for repair.
Implementing role-based views. Home Assistant supports multiple dashboards per user. Each user account can be given access to specific dashboards. The owner sees a dashboard with everything; production staff see a dashboard without configuration options; visitors see a read-only dashboard. [User Management and Security](/home-assistant/operations/security) covers the access-control details.
The trade-off with restricting views. Fewer options on a dashboard means fewer mistakes. It also means users cannot explore when something unusual happens. Role-based dashboards should be designed so the intended user has everything they need for their role — not so little that they must escalate every unusual question to the owner.
Mobile-first design.
The grower is in the field, on a phone, in the sun, with dirty hands.
The dominant use case is mobile. For agricultural operations specifically, the primary device is a phone. The dashboard opens first on a phone; it may open from a tablet in the farm office; a desktop view is a tertiary concern.
Design the mobile layout first. Dashboards designed for a desktop first and squeezed onto a phone second are usually worse than dashboards designed for a phone first and expanded gracefully on larger screens. The constraints of a phone screen force prioritization; the space of a desktop screen enables sprawl.
Readability at arm's length. Numbers on a dashboard should be readable without bringing the phone to the eye. Larger fonts for primary values. High contrast. Avoid thin font weights for anything that matters.
Tap targets for gloves. Buttons, toggles, and interactive elements should be large enough to tap with gloves on. Small icons, tight lists, and closely spaced controls do not work in the real agricultural use case.
One-handed operation. The other hand is often holding a tool, a hose, a plant. Controls should be reachable with one thumb. Important controls within the bottom third of the screen (easier thumb reach). Rare controls or settings tucked away in menus or secondary screens.
Dark mode for field use. Bright sun on a phone screen makes light-backgrounded dashboards hard to read. Dark backgrounds with bright text are often more legible in outdoor conditions. Home Assistant supports per-user theme selection; growers who spend time outdoors benefit from a dark theme.
Network realities. Greenhouse WiFi is often marginal. Cellular in a field can be poor. Dashboards that load quickly on slow networks are dashboards that get used. Heavy images, many large graphs, and real-time WebSocket subscriptions that reconnect slowly all affect usability. A dashboard that works on a cellular-only connection from the back of a hoophouse is the design target.
Information hierarchy.
What comes first. What comes second. What is present but not in the way.
Most important first. Whatever matters most — active alerts, current conditions, critical health indicators — goes at the top of the view. The top of the phone screen is what the grower sees the moment the dashboard opens, before scrolling. The prime real estate should hold the most valuable information.
Grouped by zone or by domain. Two natural ways to organize. By zone means each zone's information clustered together (Zone 1: temp, humidity, VPD, lights, irrigation; Zone 2: the same). By domain means all temperatures together, all humidities together. For agricultural operations, by-zone is usually better — growers think about zones, not about metrics across zones.
Progressive disclosure. The overview shows the summary; tapping a card opens more detail. A zone card on the overview shows the key metrics; tapping it opens the zone's detailed page. This lets the grower see everything at a glance and drill into anything that needs it.
Redundancy of critical values. Important values can appear on more than one screen. The current temperature of Zone 1 might show on the quick-check overview, on the zone's detail page, on the graph page, and on a per-zone card on the detailed analysis view. Redundancy is fine for important values because the grower checks them from different places.
Secondary controls tucked away. Controls that are used rarely — settings, advanced options, maintenance functions — do not belong on the primary dashboard. They belong in a menu, a secondary view, or an admin dashboard. Primary dashboards stay focused on the daily workflow.
Visual grammar.
The visual language of the dashboard.
Color is information, not decoration. Green for okay, yellow for attention, red for problem. Reserved for status, not used for styling. A dashboard where every tile has a different colorful icon is a dashboard where nothing stands out as urgent when something actually is urgent.
Consistency. The same metric should look the same in every zone. If Zone 1's temperature is in a big number on the top-left of its card, Zone 2's temperature should be in the same place on its card. Consistency lets the grower develop visual shortcuts — they glance at each card and know exactly where to look.
Whitespace. Dashboards crowded to the edges are harder to scan than dashboards with breathing room. Grouping through space — related values closer together, unrelated values farther apart — helps the eye organize what it sees.
Typography hierarchy. The primary value (current temperature) larger than the label ("Zone 1 Temperature"). Timestamps and secondary data smaller. The hierarchy tells the eye what to read first without the grower having to think about it.
Iconography used sparingly. Icons are shorthand — they work only if the grower recognizes them. Unfamiliar icons become visual noise. For agricultural operations with users of varying technical backgrounds, text labels usually win over icon-only labels.
Graphs with enough detail to be useful, not so much to be overwhelming. A graph that shows the last six hours with clear axis labels is more useful than a graph that shows the last thirty days at a scale where individual variations disappear. For long-period analysis, dedicated tools like [Grafana](/home-assistant/dashboards/grafana) are better than cramped Lovelace graphs.
What to leave off.
The hardest dashboard design decisions are often about omission.
Metrics nobody acts on. If a value is displayed but never triggers any decision — not an automation, not a visual check, not a review — it probably should not be on the dashboard. It takes up space and attention that should go to metrics that matter. Raw battery voltages on dozens of sensors, for example, often clutter dashboards without adding value; a single "any sensor battery below threshold" alert is more useful than twenty always-displayed voltages.
Decorative elements. Gauge dials that take space but convey no more information than a number. Logos and branding. Decorative headers. Any visual element whose job is not to communicate operationally relevant information.
Configuration controls on operational dashboards. Temperature setpoints, threshold adjustments, automation enable/disable — these belong on configuration dashboards or in settings, not on the dashboard the grower uses thirty times a day. Mixing operation and configuration invites accidental changes.
History graphs that never change. A graph of a constant value is just a flat line. If something is not varying meaningfully, its graph is not providing information. Current value suffices.
Status indicators that are always green. If an indicator has never been anything but "okay" in the operation's history, it is not communicating — it is decoration. Indicators earn their place by signaling meaningful state changes.
Wall-clock time displays, usually. The phone already shows the time. A dashboard taking up tile space to repeat it adds nothing. Exceptions exist (a timestamp of the last sensor update is useful), but "it is currently 2:37 PM" does not need its own tile.
Dashboard evolution.
Dashboards are not one-time designs. They change as the operation changes.
Start simple, expand as needed. The first dashboard is the minimum viable view. New zones, new sensors, and new needs get added as they come up. Adding thoughtfully is easier than pruning after the dashboard becomes cluttered.
Periodic review. Every six to twelve months, look at what the dashboard shows that the grower no longer checks. Remove or deprioritize it. Look at what the grower checks by navigating away from the dashboard; promote that to a dashboard location.
Version control dashboards. For installations with more than a few dashboards, putting the dashboard YAML under Git (same as automations) lets changes be tracked, reverted, and understood over time.
Dashboard sprawl is a symptom. Operations that end up with fifteen dashboards usually have three overly complicated dashboards plus twelve attempts to simplify. Consolidation — a smaller number of well-designed dashboards — usually works better than proliferation.
Test changes before relying on them. A redesign of the quick-check view that the grower now depends on deserves a test period on a secondary dashboard before replacing the primary one. Trust in the dashboard matters; breaking trust is costly.
Common failure modes.
Specific design problems that come up in real operations.
The dashboard that tried to show everything. Twenty-five cards, eight history graphs, every sensor in the operation on one screen. The grower could not find what they were looking for. Fix: apply the fifteen-second test to the quick-check; move everything else to secondary dashboards.
The dashboard that hid the alerts. Active alerts were buried in a card somewhere down the page. A real alert fired for hours before the grower noticed. Fix: alerts at the top, visually obvious, standing out from other tiles. Color and position earn their value when they catch attention.
The dashboard that nobody knew existed. The grower made a detailed-analysis view, hit it once, and forgot about it. When an investigation was needed months later, the view had fallen out of memory. Fix: link from the primary dashboard to secondary dashboards; use dashboard organization features so new dashboards are discoverable.
The dashboard that did not match how the operation was structured. The dashboard was organized by metric (all temperatures, all humidities) but the grower thought in zones. Every glance required mental translation. Fix: organize by zone for most agricultural operations; the grower's mental model is the design constraint.
The dashboard that used unfamiliar custom cards. Someone installed HACS custom cards with idiosyncratic interaction patterns. The grower tapped what looked like buttons and they did nothing; taps that should have drilled in did something unexpected. Fix: prefer standard Home Assistant cards for primary dashboards; test any custom cards thoroughly before including them in critical views.
The dashboard that broke after a Home Assistant update. A card that worked in one version no longer rendered in the next. Parts of the dashboard disappeared or showed errors. Fix: test dashboards on a staging instance before updating production; have a rollback plan; version-control dashboards so recovery is easy.
The dashboard staff could not use. The grower's dashboard had too many controls; staff tapped the wrong things. Fix: role-based dashboards — give staff a dashboard with only the controls they need; restrict configuration access.
The dashboard that showed wrong data. A template sensor's formula was subtly wrong; the dashboard showed the wrong value confidently. The grower made decisions based on it. Fix: verify derived values against known cases; log important dashboard values so their history is reviewable.
The dashboard that lagged. A dashboard with dozens of history graphs and real-time templates took ten seconds to load on a phone. The grower stopped using it. Fix: fewer graphs per view; use thumbnails or single-value displays for overview, graphs on drill-in; ensure the server running Home Assistant has enough resources.
The dashboard that looked great on desktop and terrible on phone. The design was done in the UI editor on a laptop; the phone view wrapped awkwardly, hid important elements behind scrolls, and made taps frustrating. Fix: design and test on the phone first; view every dashboard on the target device before considering it done.
What not to do.
Patterns to avoid.
Don't design for a marketing dashboard aesthetic. Agricultural Home Assistant dashboards are working tools, not showpieces. Flashy visualizations, animated transitions, and decorative graphics distract from the operational function. The dashboard should look like a running tool, not a product demo.
Don't design by accretion. Adding a card every time the grower wants to see something without removing anything produces cluttered, unusable dashboards. For every addition, ask what it replaces or whether it belongs on a secondary view.
Don't expose configuration on primary dashboards. Operational dashboards should show state and accept operational input (start irrigation, acknowledge alert). Configuration — setpoints, thresholds, automation enables — belongs in settings or admin dashboards.
Don't design without knowing who uses the dashboard. "The grower" is not specific enough. The grower in the morning has different needs from the grower in the evening. The owner has different needs from staff. Before designing, know who and when.
Don't over-rely on custom cards from unknown authors. Custom cards from community sources can add capability but introduce dependencies. Each custom card is a potential break-point on a Home Assistant update. Use them where they genuinely add value; avoid them where a standard card suffices.
Don't design the dashboard in isolation from the automations. The quick-check view shows active alerts, but alerts exist only when automations create them. Dashboard design and automation design inform each other; a dashboard that shows irrigation status depends on automations setting that status visibly.
Don't make the dashboard busy to hide that the system is not producing useful information. A dashboard with many gauges and graphs can give the appearance of a sophisticated system while actually obscuring that the underlying data is not actionable. Simplicity that reveals actionable information beats complexity that hides its absence.
Don't forget about printouts. Some growers print pages for field reference. Printed dashboards with dark backgrounds waste toner and look awful. Dashboards should have reasonable print styles that render usefully on paper when someone prints a page.
Don't skip accessibility. Growers include people with visual limitations, motor limitations, and temporary physical constraints (injuries, gloves, awkward positions). Designing for accessibility — sufficient contrast, reasonable touch targets, text alternatives to color cues — helps the whole user base, not just the most-limited users.