Shape the UI around how people in a household find, use, and share their smart home information

[mkerstner]

Problem statement

Home Assistant is evolving from a technical enthusiast’s tool into a multi-user home operating system. To support this growth, we must transition from an Information Architecture based on technical silos to one based on relational transparency.

Our current Information Architecture creates three fundamental friction points:

• Invisible system: Residents can't see or understand key parts of their smart home (automations, devices, dashboards) because they are locked in “Settings”.
• Transparent system: As a resident you can access everything through search today, and edit data that are clearly meant to be about configuring the smart home. For example, the sensitivity of a mmWave sensor, the turn on behavior of a power plug.
• Misplaced control: Maintainers control things that should be personal to residents (like location/health data sharing), while residents lack visibility into shared systems.

This makes Home Assistant feel opaque and too transparent at the same time, disempowering for residents, while creating unnecessary complexity for maintainers.

Community signals

1. Invisible system, Settings buries core concepts
Automations, scenes, and devices sit inside Settings, a space users mentally associate with configuration, not daily operation. The navigation tax is real: automations alone require three clicks minimum. A 5-year user summarized it: "HA is at its core an automation platform. It's really cumbersome for a user to do more than 2–3 clicks to find a critical piece of home automation." Multiple WTH threads since 2022 name the same root: Settings has become an undifferentiated dump of both operational and system-level content. Home Assistant

2. Transparent system, search bypasses all intent
The Quick Search bar lets any authenticated user discover and actuate any entity, including those hidden from their dashboard. Search causes a security issue because normal users can search any entities and control everything. Community workarounds (Kiosk Mode, Browser Mod, custom RBAC integrations) only hide UI elements and are all bypassed via direct URLs or the API. The 2024 WTH survey made this the top complaint. Critically, search doesn't distinguish operational controls (lights) from configuration controls (sensor sensitivity, automation toggles). Home Assistant

3. Misplaced control, location data visible to all users
Any logged-in user can view another household member's GPS coordinates by clicking their person entity. The maintainer decides who has system access, but residents have no control over what's exposed about them to others on the same instance. Logbook and History compound this, exposing all entity activity to all users regardless of dashboard visibility settings. Home Assistant

4. RBAC
RBAC topped the 2024 "Month of What the Heck" survey. A working backend implementation (~2,900 lines, 155 tests) was proposed in architecture discussion #1374 with full API enforcement, but hasn't been merged. The permissions system remains "an experimental feature that is not enabled or enforced yet." Multiple parallel community workarounds exist, but a 2025.12 release regressed even the limited dashboard visibility controls that previously existed, making the gap wider. Home Assistant

While there are multiple areas involved in the reasoning of this opportunity we aim to make it tangible by condensing it to more specific areas to focus on and follow a general iterative approach going forward.

Scope & Boundaries

In scope

• Focus on device page as first area of UI improvements #130
• Automations are ideally already included but are tbd

Not in scope

• Architectural changes to enable the reshaping of the device page (at least we aim for that)

Foreseen solution

• Written outcome documenting baseline to iterate on as Wiki page on UX/Design repository (https://github.com/OpenHomeFoundation/ux-design/wiki)

Risks & open questions

Risks

• Requiring architectural changes to achieve reshaping

Appetite

Big - 2 cycles

Execution issues

No response

Decision log

Date	Decision	Outcome

[jlpouffier]

It's not actionable enough to be an opportunity yet.
I would suggest @matthiasdebaat to :

• Take more decisions in the opportunity writing
• Propose a solution
• Make a wireframe
• Keep it on shaping (now we're really shaping)
• Spend the cycle collecting feedback from all places
• Pitch it next time

We have lots of different proposals we already prototyped.
Pick the most plausible candidate and open up the discussion with the community.

[matthiasdebaat]

Agreed that this one should be kept in shaping until we have defined solution oriented opportunities.

The proposals I have seen are based on the current way, and don't fix the problem statement as described above.

[mkerstner]

@matthiasdebaat As discussed today a concrete first step to proceed is to focus on a revisited device page

[matthiasdebaat]

Published the proposal here
OpenHomeFoundation/ux-design#40

[rekcodocker]

Good problem statement. Opaque and too transparent at the same time is spot on.

Perhaps: Remove the distinction between devices and entities, oh and helpers too.
It always feels too technical for me to have a separate 'entities' tab. Why isn't every entity part of a device?

Same confusion in automations. I literally never know whether to start from a device or an entity. I usually pick 'device' and then I select the entities I need.
But why is the option to pick some orphan entity there in the first place? This is technology-driven. The data is there so lets expose it to the user. All of it.
But the user just wants to play a Spotify song when the living room lights turn on or turn off the lights when he leaves. Notice how the word 'entity' does not appear in that sentence.