🧩 Design System

[dapper hollow]

Design & development chat about Home Assistants components and guidelines.

More info at design.home-assistant.io

We have been working on improving the [Media Player more-info dialog](#1351536906437005313 message) in the Dashboard channel. One of the comments in the PR is the need to differentiate between the two sliders to avoid confusion and improve aesthetics.

@sacred sluice is on a streak, and is experimenting on updating the slider to the Web Awesome version. Web awesome got slider sizes, that could help differentiate.

Let's discuss design too.

I like what Sonos did: same stroke weight, different dot size. Web Awesomes design is a bit too heavy for my taste.

If there are no concerns, I would suggest to implement the Web Awesome slider with the 3 sizes, and keep the same stroke weight.

[sacred sluice]

This are the sizes so far

[dapper hollow]

Nice!

What is the stroke weight right now?

Seeing this, not sure if we should go for 3 sizes from the start. I think we can drop large. And add it if we have te need.

Small looks like the current size, is that correct?

[sacred sluice]

Track size is 4px. Yes small is nearly the same size as currently

I’ve opened a PR for that already

[dapper hollow]

Suggest to have two sizes:

• Default (same size as the current one)
• Small

Feel free to suggest better names.

What is the size of the current dot? Should the smaller one be half of that size?

[sacred sluice]

The current dot is 14px. 7px is way to small

[dapper hollow]

What about making the track thinner? For example 2px?
cc @modest holly

[sacred sluice]

Hm then the dots within the track wouldn't be that visible, I guess (if we want to use them). https://deploy-preview-27075--home-assistant-gallery.netlify.app/#components/ha-slider

4px is already to thin for them, I think

[dapper hollow]

Yes, agreed. Lets keep it at 4px. That works also with the dots.

Can you remove the white border? I know that WA added this, but makes it less of a single line.

[sacred sluice]

Sure

[dapper hollow]

I like the small and medium sizes. Think we should drop the large one, as people will start using that one. And I don't see a use case for now.

[tranquil coyote]

So im new here, what does this slider do ;(

[dapper hollow]

Details of the details. The dot is not right in the middle.

Web Awesomes default for the track 8px and dot 3px. This means there is 1,5px above an below. Wat about making the dot 2px, that is got 1px above and below?

[dapper hollow]

This is the default slider component in Home Assistant. That is been used on all kind of things, JP make a great overview in his PR.

Home Assistant has been using Material Design Web Components, but they dropped support. So we are migrating our components to Web Awesome.

[sacred sluice]

Changed. Will be visible in a few minutes in the gallery preview 🙂

[tranquil coyote]

Ok tysm!

[tranquil coyote]

Ty

[modest holly]

FIY we've created a GH project for components or design system things in general: https://github.com/orgs/home-assistant/projects/37/views/1?layout=board

I've linked the slider there now, and if there are ANY PR's that introduce new web components, or changes to them, they should be tagged there

[modest holly]

JP please use with-tooltip whenever possible

[dusk widget]

Visibility has to be changed to public 😉

[modest holly]

Also I've noticed that when I tab-focus the slider, there's no visual indicator that I have the "dot-handle" focused (in your draft). On WA documentation there is a blue border around it when I tab-focus. We have a new variable for this --ha-color-focus

[modest holly]

Thanks! Seems every board stills needs Frenks change to make it public. Will do this in a sec.
Fixed!

[sacred sluice]

@modest holly Fixed your comments 🙂

[bold tiger]

Shouldn't we be using the Progress bar here for the 'Seek'? https://webawesome.com/docs/components/progress-bar/

[dapper hollow]

Yes, agreed. When we can control the time we should have something dragable

[raven crest]

So just wanted to clarify, does Home Assistant intend to continue using the Material 3 Design System? Or was the intention to begin diverging and developing an independent design system, for Home Assistant and adjacent software?

I know that it was stated here that the intention is to move away, but the site doesn't clarify this, instead mentioning how the interface is based on Material Design, and if somebody is looking for a component that isn't listed in the Design site, to go to https://material.io/ ?

It also mentions a defunct #devs_ux-archived channel, points to a clearly outdated Figma Design Kit, or asks people to use the discussions and issue on GitHub (which can be quite slow-moving for design work, better utilised for lengthy and important discussions).

Would love to get clarifications on what the design situation is for Home Assistant! ❤️

[sacred sluice]

Home Assistant uses Material UI for most of the things. We’re slowly migrating to Web Awesome due to Material UI’s maintenance only mode. Yes the design page could use some love indeed. For the components we already migrated, the documentation should already mention that they are based on Web Awesome.

And as always we are happy for every contribution on this 🙂

[dapper hollow]

does Home Assistant intend to continue using the Material 3 Design System?

• From a frontend perspective: We are moving towards WebAwesome, as Material web is not supported anymore.
• From a design perspective: Currently we don't have our own design language and identity. We have been using M3 guidelines and visual design. We identified this as a problem, and we want to work on our visual design. Nothing concrete yet to share.

Or was the intention to begin diverging and developing an independent design system?
A frontender could probably explain this better, we already have our own design system that inherit components from other design systems. We have been using M3, and have been building our own components that where specific for our own needs. For example, dashboard cards.

for Home Assistant and adjacent software?
Our design system is build for Home Assistant. We should think about Music Assistant and ESPHome too, and if they should be using the same design system or something else.

[dapper hollow]

Good call. And I agree that we need to update our design website. We are in the process to alocate more resources to our Design System from the Open Home Foundation. Currently we do it on the side, and as you noticed it doesn't get the attention it needs.

[dapper hollow]

I'm going to clean up that page a bit and update the discord links. We have been working on a updated Figma Design Kit, its in the works, a bit rough, and almost ready to share.

We have also ideas how "build in the open" could work for designers. For example when Discord or when GitHub works the best. We will update that soon™.

We love every help we can get. That could also be helping out with anything around our Design System. As designer from the Open Home Foundation I'm here to help contributors. So please let me know if you have ideas that you want to work on.

[modest holly]

Matthias already provided most of the answers. I can just reiterate that we are focusing more time on the design and of course usability aspect of HA (both in the micro and macro approach) and not just technical. Changes started mostly in mid this year form a technical aspect, because our web libraries from Google (MD2/3) are not supported anymore, so the decision was made to migrate twaords Web Awesome web components. With each migrated component (atom if you're thinking of atomic approach to design) we're introducing our own spin on how it looks and where it's used. Best example for now is the humble button component that we've updated in 2025.8. The latest addition is a sidebar in the automation editor. There are more coming, but these are just the atoms. We want to use those as a basis for re-building some of the aspects of HA, not just to do a UI refresh of the same experience, but to make using HA just plain easier.

[raven crest]

So an update to the flow? I did think that the mobile experience has a lot to yearn, with the way it currently navigates nearly identically to the desktop environment

[modest holly]

If you have ideas on a atom/pattern (UI), or a flow (UX) level let's discuss it here, or on GH discussions.

Btw. Hi 👋 I'm Marcin and I'm part of the Product team at OHF. You might think of me as the guy to talk design system things 😉

[raven crest]

Sounds good 😋

Nice to meet you!

[modest holly]

Yes, we have navigation as a big subject to tackle. We've already did some research, and prototypes but had to postpone for other priorities. This is also changing because our team is growing!

[raven crest]

On a first thought, you could have a bottom navigation bar for essential pieces (Overview, Dashboard, Devices & Services, Settings)

Then, at the top can be dedicated for switching between the different dashboards. Or, as traditionally was done, from the side. But if you're going to have it accessible on the side, you might as well add swipe navigation to be able to swipe between them instead

[modest holly]

Yes you're right on par with what we were thinking. We would like to introduce the bottom navigation bar when you start HA to have easy access and discoverability to the most useful things that HA offers. There are questions what should be there, and more importantly how to go about displaying/switching dashboards AND their sub-views (that's the tricky part). But we have to also consider, if on mobile we would promote the items you've listed, how are they displayed on desktop? One answer is, that for example "Devices & Services" should be an item in the hamburger menu on desktop 🤔

[raven crest]

To be honest with you: I feel as though devices and services should make adding services easier. It does feel like a bit of a slog, having to navigate through the settings just to add a device. I realise one solution could be including a flow in the top right with a button to "Add a device* which allows you to pick a service that you intend to look for / include on the network. For desktop, it's not as necessary, though I can agree it should probably be more easily accessible in the hamburger menu (or at least pinnable in it, like add-ons can be)

The hamburger menu could be improved, where when hidden on desktop, it turns into an icon sidebar as opposed to being completely removed. That'd already be a pretty substantial benefit, as long as the icons are readable at a glance :)

[modest holly]

Somewhat related. Last release we've added the "+ Add to home assistant" icon in the top-right on dashboards, where you can add a device and some other things.

[raven crest]

oh right! Honestly I did forget haha, it's not too obvious

[modest holly]

Interesting to hear I wonder why it wasn't ?

[raven crest]

On mobile, since it's hidden behind the three elipses, it's not immediately obvious and quite hidden away

On desktop, I think it's because there are so many icons in the corner, it tends to blend in

[modest holly]

We wanted to make mobile top-bar more open and not wrap the main functions of search/edit/add-to etc. in three-dots, but a more "compact" top bar was a heavily requested feature that a lot of users use now, so this would be a breaking change for some.

[raven crest]

Yeah.. it just removes too much information in the process. I think there's a potential solution, but it would involve the bottom navigation bar implementation

I might try to design something today to put down what I'm thinking into something a little more concrete

If there's a public Figma file for Home Assistant, I'd be interested in having a look

[modest holly]

Thanks for wanting to help. There isn't one yet to share, and I wouldn't focus on pixel perfect just on a general concept, so please feel free to mockup with b/w boxes and text.

[sacred sluice]

@modest holly we have a new token called ha-control-color which controls the primary color of the slider (handle and track) at the moment, but should be used for other controls as well. Paul suggested we should discuss the name.

[raven crest]

primary, secondary and tertiary is usually what I tend to name colours that brand an interface

[sacred sluice]

Yea, would be my guess as well, something like ha-control-color-primary. But this would maybe be to generic as well 🤷‍♂️

[raven crest]

Being generic is better than being specific most of the time, unless the colour is intended for one specific concept and nothing else (e.g. danger, warning, success)

[cinder patrol]

(continuing from #beta message )
please also consider setting the button and the left slider apart. currently they look like 1 element and that does not really look nice imho. it's not only the missing border on the button, but also the lack of opacity of the slider. Toning that down a bit would probably suffice

border does help (set to black in this top slider, but it'd better be calculated from the primary-color probably)

as also shown in the examples in https://github.com/home-assistant/frontend/pull/27075

[dapper hollow]

We are working on a plan how to define our visual design language. That should guide why we have a slider designed like this. Without getting into discussions about preferences.

For now we keep what we have.

[raven crest]

I would love to be involved if there is any way to do so :)

Apologies for the ping

[hybrid talon]

We did have seperate thumb and track theme variables before this update. A PR was made to re-introduce these for the new slider but it was changed to one variable at the last minute. Why? Why can we not have separate slider and thumb theme variables as we had for the old slider? It is a step backwards and looks terrible (IMO).

Actually previously we had three variables:```
md-slider-active-track-color
md-slider-inactive-track-color
md-slider-handle-color

You keep dumbing down custom theming. Is this a step towards removing it it altogether?

[dapper hollow]

That is an oversight on my side. Sorry about that. When I asked JP to keep the same color as today, I haven’t checked what theme variables we had.

As I said above. We migrate components because M3 is not supported. We have to define our visual language, including theming.

[dapper hollow]

Not sure what you mean by “dumbing down” and who the “you” is. Please have a more civilized conversation.

We don’t have the intention to remove theming. We want to make Home Assistant accessible, yet keep its customization DNA.

[sacred sluice]

We could add the variables from my PR, with the ha-control-color as its default. Could have been a misunderstanding in this PR between Petar and me 🤷‍♂️

We are all humans especially with different languages in background.

[cinder patrol]

We want to make Home Assistant accessible, yet keep its customization DNA.
This is great, and I really appreciate the team’s responsiveness in adding/changing various theme variables after discussion.

If I may add a broader remark: please consider documenting these changes in the release notes. So far, the stance has been that themes are not “supported,” which means changes are not treated as breaking and therefore don’t require notifying the user base.

I hope that stance will evolve soon, with changes documented clearly so that the many users relying on themes can adapt more easily. The same applies to plugin developers, who currently experience these changes frequently without much visibility.

btw Jan-Philipp, this #beta message indeed fixes it for now ! thanks for the helping hand, see https://github.com/thomasloven/lovelace-slider-entity-row/issues/313#issuecomment-3357454464

[dapper hollow]

With our wish to build in the open, we also identified the need to have better public documentation around design decisions. It in the early stage and we have identified the problem, we don't have a solution yet.

Specific on theming. I would love us to work on "what theming is within HA ?"and "how you can customize the default one?". From a user standpoint, I see that there are different levels of customization today: default out of the box, download custom package and the last is DIY. I would love to keep these tiers, but better support them all. What this means and how we can make it maintainable is a hard question.

After that, we can decide where to put the theming changes. In my mind the DIY options is almost like developing today. With this in mind, it is better suited on our developers website.

But I'm open for ideas. Yet, don' want to start the ideation and solutions process today. As we first need to work on our visual language and define how we design in the open with the appropriate documentation pages.

[dapper hollow]

JP is a rock star

[hybrid talon]

Apologies. Thank you for considering the extra varables.

[cinder patrol]

nice!, looking forward to the outcome of that process.

Fwiw, I was mainly talking about using theming in HA. Although I use card_mod a lot, I try to do as much as possible inside theming, simply because it is way more robust (and faster). That's why changes to the HA internals matter so much.
For starters, it would help to simply list these changes

[cobalt current]

The reason we didn't document internals is because it then becomes a stable API interface people rely on and we can never change anything. Changing internals is not a breaking change.

[modest holly]

Card_mod fills gaps where HA doesn't have easy themability. We'd like to change that by changing the components with variables that should fill those gaps. We cannot do a 'big-bang' release, and so it will be a release-by-release process.

[cinder patrol]

stable API interface people rely on and we can never change anything. Changing internals is not a breaking change.
this is the exact stance I referred to. maybe call it backward incompatible...
just don't let the users see their themes fault and have no idea other than to rummage through the frontend code themselves. because that is whats happening now. Those unannounced changes break the existing themes, which are 100% pure HA, nothing custom.

of course you can change everything, please just let the user know.

[dapper hollow]

The issue I see is that one group of users wants to customize Home Assistant to truly make it their own, while developers need the flexibility to change the internals. These two needs collide and both are completely understandable.

The principle of flexibility for developers has been there since the beginning. Notifying the community about every internal change just isn’t maintainable and would remove that flexibility.

Customization is acknowledged, but there’s no great solution yet. If we can come up with a better approach that us sustainable, I’m all for it.

[cinder patrol]

yeah, I hear you of course. otoh, it wouldnt have taken more time than it took your post, to write a short heads-up on the 2 fundamental changes, to Web Awesome, and its implications for the now used ha-tab-group-tab, and a line on the ha-slider.

Nothing in depth, just as a service to those who do try to follow along. Let those be your postillion d'amour to the community..

I'll su now. sorry

[barren quest]

A helpful process improvement would be to note in PRs which version they are taregtting. Sometimes I find a PR which has a breaking change and am guessing when it will be released. It seems milestones are only used near a release, mostly to track fixes found in beta etc. Can (or are?) milestones used for these sorts of PRs?

[cobalt current]

The Creator doesn't know when his work gets merged

[barren quest]

@dapper hollow THIS is the type of issue that would be good to have proactive knowledge of, rather than chasing. This history of classic popup style aparantly brings back what used to be default for dialogs. When it changed it was seen as a Browser Mod issue, so to provide users a workaround there is the classic style, which as of Home Assistant 2025.10 is broken and not easily fixed. I always thoroghly test Browser Mod on its internal changes, but not specifically on Home Aassistant changes UNLESS I am aware of change. So as per the discussion, its about awarness of changes. Just like you say developers can't be on top of making community aware of all changes which MAY br breaking in some, at the same time custom element maintainers can't be on top of every PR that may break their custom element. You will know from how the community pops up on PRs in progress that we try and keep on top of these, but this is an example of a 'crack' which we won't to make better in the best way possible. So any suggestions or process improvements will be most welcome. 🙏

[barren quest]

It would be great to know of a general road map, especially for the big changes like migration of a component to webawesome. I am still unclear of the timeline for ha-wa-dialog and whether ha-dialog will by default be migrated to ha-wa-dialog, and if so when?. At the moment I am monitoring the PR to see when ha-wa-dialog may be stable so I can test it with Browser Mod popups. Browser Mod popups are quite popular so making sure they do not break in any way will be important for the Home Assistant community. Thank you.

[cobalt current]

I just want to note that this chat is meant to discuss the design system, which are the looks and how things work. This is not the place to talk to frontend developers about implementation details like Web awesome migrations. They happen, slowly, as time permits

[raven crest]

*rubs hands*

So regarding the conversation that was had last night, I think that it sounds like we are more interested in establishing the identity and brand of Home Assistant's foundational aspects, before moving forward with any kind of design systems. Do we intend to discuss how that will be planned out, or were we looking to move forward and feel our way through it? Both approaches are valid for sure.

[modest holly]

I think as any project that tries to turn over a new leaf, starts with a general direction or a mood-board approach. A DS is the documentation of all of those decisions that build that vision.

[raven crest]

Our issue is that the direction is unsure, so I do not want to start any work that will have to be completely wiped away ... 😌

[modest holly]

My point exactly, that's why I'd like to steer the discussion twoards a big vision, than the small details

[raven crest]

Well, it should be decided whether there is a plan to be had, or if we are moving with the flow.

[modest holly]

Have you had any ideas on how you'd see the start screen of HA? Things like how would the navigation work/look? What would be the other parts and surfaces that the user can interact with?

[raven crest]

Well, I've only been considering T1/T2/T3 for the time being, haha. I did have some considerations on improvements for the new Home page that's being added to HA soon and shared those in #1351536906437005313 already :)

As for implementing those design systems into something tangible, it would come along with T3, but I would say T1/T2 are quite important starting points to come from. 😌

T1 is foundational, T2 is semantical, and T3 is compartmental

[raven crest]

ah, right. cc @dapper hollow and @potent fossil on this question, haha

[ruby shore]

(My) takeaways from yesterday

• A design system eases friction when many people need to converge on a visual language and identity
• Home Assistant is a mature project with tons of assets and artifacts, they can't be redone in one sweep. We should think "design refactoring" rather than "clean slate."
• An open-source project with a lot of contributors has to allow for work to be asynchronous. Contributors should be able to "pick up and play" smaller redesign tasks, rather than eat an entire elephant in one bite.

Questions

• Design work is done in multiple tiers -- brand identity, website, individual Lovelace cards. They're done at different times, by different people. How do we align them? Should we align them at this point, or just pick one area to focus on?
• Where would our best work be done right now? Is it overhauling the brand / web visual language, or is it the HA frontend itself? Which area will be the best guide / north star?
• Where does our output go? Where's the single source-of-truth? Where do people look?
• Who, if any, within OHF needs to be involved? In what way?

[raven crest]

To go off point 2 you made, they've made it clear they hate the current design with a burning passion. It will be a clean slate

[ruby shore]

oh, in terms of design, certainly. I meant more in terms of execution. The design can be all new, but we can't just Thanos snap and have it done 🙂 updated the text.

[raven crest]

I think it'd be worth having it as an Experimental piece of Home Assistant, where we can slowly make changes via an experiment (I'm not sure how in-depth an experiment can be currently)

I'd be curious on what is actually possible in a Labs "preview"

If we could overhaul Home Assistant without touching the current design ... that would be oh-so-wonderful :)

[ruby shore]

that'd be neat, yeah

[raven crest]

It'd mean having the ability to move waaay faster. The alternative is that we maintain a new branch that users can try that's updated far more frequently, but I'm not sure how that'd work

[ruby shore]

let's query the OHF wizards on that one

[raven crest]

Not sure who's the best person to ask regarding how flexible the Labs system is

If it's not flexible enough ... then perhaps the ability to switch between branches with a big warning telling users not to switch unless they're willing to experience issues with the UI/UX

[dusk widget]

With all the people working on it, it's almost impractical to maintain 2 different versions. The labs can be used for anything, see it as feature flags that will enable or disable stuff. We technically enable and disable the winter mode as an example.

I'm going to guess that we will move to webawesome slowly but steady. And along the way rethink the core parts how to make it more for Home Automation.

Having everything themable customizable through supported theme vars is something that we take up along the way.

[modest holly]

@ruby shore you've touched upon a very important and sadly a very misunderstood aspect of how design systems form and evolve: "...when many people need to converge on.." THATS the key for a DS to even have a chance to workout. Is for many people from different departments to work on it and be responsible for building, and maintaining it's parts.

That said, the people that have joined here are mostly product and UX/UI designers, so like with any big goal, we ought to focus on smaller chuncks that we can create and then join them it that system.

That's why I'd focus this discussion on the "UI kit" part of a design system

Re: Home Assistant labs and how to experiment. Frenck vibe-coded this feature and I've helped to make it usable. The first feature that we shipped is also something that I'm currently involved in, so the "Purpose-specific triggers and conditions". Those both expose new features in the core side of ha (so backend stuff), as well as display new frontend UI's.

So that's one potential way of experimenting on live code.

I say one, because there are others!

I'm currently running my own dev environment of the front-end code of HA, and I'm able to prompt ai agents to change HA's front-end code to what I intend via text, and I can see live changes on my own home setup.

And the wild thing is... anyone can do this 🙂

[modest holly]

Example of using this method: The current Activity and History views have a lot of legacy patterns and components. They still also use the old chip-style target pickers. Prompting the ai agent to use specific components and explaining how the screen should work enabled me to vibe-design/code this on live code (left is 2026.1, right is a future draft version).

This gives 10x the feeling of "how this would feel if I'd design it like this" than doing anything in Figma, Penpot or whatever design tool

All of this is to say that: it's possible to skip dedicated design tools altogether, but (!) we could also go about creating a simplified UI kit for HA that is in 70% what we have on production, design a flow/screen with it, and either post it as a PR for some developer from the community to implement it, or ask ai to write a production implementation of it in code, then hand it off for a developer to make it ship-worthy.

[raven crest]

Nothing can beat a dedicated design tool like Figma for productivity AND creativity

AI rehashes existing concepts, it's not a creative machine. Never was intended to be.

It can't build in my vision, it builds in a tokenized vision of pre-existing language and material ... none of it is original concept because all it does is take the essence of humanity and guesses the most likely answer.

[modest holly]

There are different ways to use AI:

1. I don't know anything about code or design, but I know what I want you (ai) to create for me, so: "Design and code a way to [user intent]"
2. I know design and I will specifically instruct you which existing code or design component you should use, and how things should be ordered, with the explicit attention etc. etc.

In case: 1 we're relying on the average knowledge of LLMs how to achieve a goal. With approach 2. we are just using it as a design-implementation multiplier to prototype faster.

[raven crest]

Approach 2, it would've genuinely have been faster to build the component in Figma than to type it out in an LLM and tweaking it over and over until it looked how I want it to

And approach 1 doesn't actually make anything ... that a designer intends?

[modest holly]

Yeah we're not there yet in building components. My example above was to use existing codebase to prototype on existing things.

[raven crest]

Well, this is the Design System post, so we're explicitly looking at "How can the design system which makes up Home Assistant be overhauled effectively?"

[modest holly]

Yes, but atoms make patterns and patterns make a DS*. So we should also talk here about patters, because if we just change how atoms look, we'll just re-skin HA but it will still feel like a MD product.

[raven crest]

MD is mostly about its looks, not the way it is built. Of course it has certain decisions that developers implement, but a majority of it is its visual design.

[modest holly]

Yes, but there are a lot of screens in HA that can benefit from a do-over, not only from a strict UI perspective, but also a usability and a11y one. Case and point: Settings / Areas 🙂

[raven crest]

I'm aware 😅

[modest holly]

It's like a showcase of MD2 😉 Not sure how much UI paint will help to make that not feel like MD 😅

[raven crest]

A fair amount, really!!

[raven crest]

I'm going to try and build out some semblance of a DS, but what I'll do is start with T3 components and then working my way up after people are happy with the way that T3 looks :)

[rustic arch]

I saw your explanation from earlier, but Im not sure to understand your definition of Tier here. Design System already have a definition of tier and it's to describe tokens tier, but I feel like this isn't what you are describing here.

Also general question: is HA looking to get away from Material and build components from scratch? IMO Material is really not the best example and implementation out there. Sure, I have it in my common benchmark link, but it's definitely not my go-to when it comes to design system benchmark, that's probably something to keep in mind!

[raven crest]

They're moving to WebAwesome, but those components are customizable so it should not be too difficult to change them to whatever they'd need.

As for "Tier" in a design system, it's specifically referring to three tiers,

1. The first tier represents the core aspects and building blocks which make up every single piece of the UI
2. The second tier is defining semantics that can be reliably switched around without causing headaches for developers having to go and look for all of the tokens that have already been defined to change them to another one (think --home-page-background instead of --ha-color-gray-500)
3. The last tier is usually where components are built and defined based on the first two tiers, but you can also start with this tier if you're not sure where exactly the design is going to go and then build upon it using Tier 1+2 later on

[rustic arch]

Hmmm okay, I think you are mixing the concept of tier

[raven crest]

no?

[rustic arch]

Tier are meant to explain the token tiers.

[raven crest]

No no, they can describe the tiers of design as well

The tiers describe both

[rustic arch]

That's not a common concept in DS

[raven crest]

how so? if you look up "tiers in design systems" it typically describes the design aspect of tiers

not tokens

there are also many books on the tiers of design systems that specifically touch on design aspects, where you're defining tokens but you are not creating the tokens directly until the developers (or you) are implementing them later on

[rustic arch]

Are you talking this one article? https://medium.com/eightshapes-llc/design-system-tiers-2c827b67eae1

[raven crest]

er, no?

no particular article

there are two sides to a design system that go hand-in-hand

design and tokens

[rustic arch]

there's more than that but sure 😛

You are using word like "core", "semantic" and "components" in your tier definition, which are exact word to describe token tier

[raven crest]

I am not an expert, but I do my best to understand it, if I am misunderstanding then do let me know

But from what I gathered, it's two sides that do 🤝

[rustic arch]

I'm trying to understand your concept of tier to understand what you are trying to achieve but I believe you are mixing some concept together 😛

[raven crest]

maybe? Please correct me if I'm wrong on it haha

I have never professionally done UX/UI design in a work environment, I've merely learnt most of it by helping open source and working on projects in my free time

I'd love to get into it as a job, but entry-level or junior without work experience is about as womp-womp as it gets for that kind of job

(which is why I help open source projects)

[rustic arch]

In DS, Tier are usually use to represent tokens tier. Which are divided in 3-tier.

• Core tokens
• Semantic tokens
• Component tokens

Most design system tends to avoid using the 3rd tier because that's harder to manage.
Core tokens are hard-code value / raw value (like gray-100 = #ffffff, spacing-100 = 16px/1rem)
Semantic tokens are more specific to a certain usage (like action-foreground = gray-100)
Component tokens are tied to a specific usage (like button-foreground = action-foreground or gray-100)

[rustic arch]

That's okay 🙂 I didn't mean to put you on the spot I just wanted to understand your explanation, and language is really important in DS!

[raven crest]

ah, so component is ... more in-depth version of semantic?

i was not aware of that

[rustic arch]

yes semantic are meant to be use by a group / set of components, vs components are really specific to one element

[raven crest]

I see

so Tier 3 would be for like, if there's a special button or something that won't fit perfectly into the existing Tier 2

[rustic arch]

exactly

[raven crest]

that makes a lot of sense

I have no idea where I was getting the idea for T3 being for the component building haha

that must be a different thing then 😵

[rustic arch]

Hahaha yeah I'm still unsure I understand what you were trying to say 😅

[raven crest]

don't ask me 🥀 I'm still trying to learn

It's incredibly difficult when you're basically trying to learn in the dark without having actually. well. y'know, been in a proper work environment LOL

I appreciate your clarifications though

[rustic arch]

Hahaha no worries! I understand 🙂

When you want to start a design system nailing the token system is like the hardest part tbh. I tend to start there but don't overthink it too much and start building the component to test with real elements to see if the token system works and adapt

Also each product is different and have specific needs, that's why most company decide to create their own design system and don't use pre-build system (I understand tho that for budget and time constraint, using a pre-build system is sometimes the easiest and cheapest path to go)

For a fully customizable product like HA tho, I feel like using a pre-build system might end up adding a lot of constraint along the way!

[raven crest]

Yeah, for sure, but I would definitely love to contribute to Home Assistant's design system, as it'd definitely help me both in terms of growth and recognition in the space. Well, also the fact that they want to get as far away from MD2 as possible

Maybe it'll land me a job in design 🤣

Wishful thinking for open source, but hey

[rustic arch]

Hahah yeah DS jobs have been getting more attention in the past few years, most company are still discovering the value of it and it will definetly be important with AI 🙂

[raven crest]

though goodness gracious. some companies think AI can just completely replace designers and then they just get the most plain and boring design I've ever seen in my life

and then the UX just ends up being horrifically horrendous

[rustic arch]

And btw I'm a passionate DS designer so don't get me wrong in general I just like to share my knowledge and my passion haha!

[raven crest]

can I add you on here? :)

[rustic arch]

I mean... for AI to replace Design and generate full-coded screen, they will need to connect to... guess what... a DS 😂

[ruby shore]

surprised_pikachu.jpg

fwiw, the T3 tokens / component tokens are slippery when you work distributed. it can easily devolve into a designer authoring what is essentially just CSS in another form, and a frontender doing the translation work. In my experience, it’s not necessarily where the big gains are.

[rustic arch]

Yeah I pretty much never used them in any of my system.

[modest holly]

To give you a some insights on the token side of things. HA has MD2 components which didn't really use a tierd token set. Because MD2 is not maintained and does not use tiered systems, we are migrating them in code for Web Awesome components that have base a11y built in, and can be styled with a 3-tierd approach.

But it's not as easy as changing a dependancy in code, and we had to tiers of new tokens that bridge the OLD tokens, with the NEW tokens that are used in WA components 😅

Some of those new tokens are already in HA:
https://github.com/home-assistant/frontend/blob/dev/src/resources/theme/color/core.globals.ts
https://github.com/home-assistant/frontend/blob/dev/src/resources/theme/color/semantic.globals.ts
https://github.com/home-assistant/frontend/blob/dev/src/resources/theme/core.globals.ts
https://github.com/home-assistant/frontend/blob/dev/src/resources/theme/typography.globals.ts

We aim for at least a two-tiered approach, so base and semantic, but some components get their own component tokens when implementing.
Base - think of a color palette, a range of spacing tokens, typography sizes etc.
Semnatic - think colors that define primary, secondary, disabled text, or color sets for variants of buttons
Component - a token that will effect only this one component, like --ha-tooltip-border-radius

[rustic arch]

Good to know @modest holly !
One thing about semantic is that most of company have a design system for only one product and don't really have to deal with multi-brand or full-on customization needs. When it comes to semantic I feel like most design system reference we see online are for these single product and they don't work on multi-brand / multi-theme scenario.

This article from Nate Balwin talk well about the problem that can happen with semantic: https://www.designsystemscollective.com/when-semantic-tokens-are-no-longer-semantic-d65ef16fadd7. Most example he's giving are not color example, but I've seen this problem happen a lot with semantic color that are too generic such as "background-primary", "background-secondary".

[ruby shore]

yeah it's that thing again where, if you're not careful, you're kinda just writing CSS in a different format. Sematic tokens are fundamentally a good idea, in that they encode intent, but just like with any communication, if the intent isn't clear...

[modest holly]

@rustic arch thats a good article, although the example with the spacing tokens is a little far fetched. I didn't see a DS using spacing tokens that are so specific (like element- in this article). In HA spacing tokens are there just to provide a scale of px sizes so a dev or designer can easily use it anywhere there is a space to define. They will never change, so in our case they will not break things.

[rustic arch]

Yes, like I said that's because most design system out there only have one product to serve and don't require this level of flexibility. It all comes up to the product needs. What if a HA user wants to have more spacing between their elements? Bigger button? It all comes down to what is the level of flexibility your users will need !

[raven crest]

Any good news on the HA Design System yet? Or is it still in the land of unknown on where it's heading?

I know that branding was going to be reconsidered so that it could be aligned with the DS, but I haven't heard much of what was spoken during the Monday meeting, so I'm curious what I can potentially contribute in the next few days (or weeks, if we're talking that long here)

[ruby shore]

I think the "soft consensus" is that we're still all talking.

A tentative suggested agenda would be something like:

1. identify design pain points. concrete rather than broad.
2. figure out how people can best contribute
3. draw the rest of the #$%^ owl

just like with code, there's bound to be "good first issues" for design. if we can find some, and talk about them in this group, it'll get easier to talk about how we fix them.

[raven crest]

Well, the easiest thing to point towards, is that the OHF heavily dislikes the design of MD2, and wants something that looks a lot cleaner and more modern in today's UI world