Your first design contribution

Design contributions start with a problem, not with a screen. Something that confused you, a flow that takes too many steps, a label nobody understands. That is where you begin.

You don't need to be a professional designer. UX research, wireframes and flows, visual design, accessibility reviews, better wording in the interface, and work on the design system are all welcome.

Join the #designers channel on the Home Assistant Discord. It is the quickest way to meet the people working on design, ask questions, and get early feedback. Can't see the channel? Pick the right role under Channels & Roles.

• The project board lists the design tasks that are active and planned.
• The UX design discussions have ideas and proposals that are still being shaped. Join one that interests you.
• The UX issues in the frontend repository are concrete problems in the interface.
• The pages in this area are the design reference of Home Assistant, and some are still missing or incomplete. A component without a page, or a page that no longer matches the interface, is a small and useful first pull request to this site.

Pick something small for a start. Or bring your own: a problem you ran into yourself is a great first topic, because you already understand why it matters.

New to GitHub? See Use GitHub, without being a developer.

The Home Assistant Design Kit on Figma has the components and styles of the interface. Working from it keeps your mockups close to what can actually be built. The components and patterns in this area show how those pieces behave.

Start a discussion in the UX design discussions. Early ideas go in Ideation, designs you want feedback on in Design review. Lead with the problem, then show your solution. Write a proposal has an outline you can start from.

Share early and ask for feedback. A rough sketch with a clear problem gets you further than a polished design nobody asked for. If your proposal belongs to a task on the project board, link them.

Expect questions. That is how designs get better, and it is not a judgment of your work.

Once the direction is agreed on, the design gets built, usually in the frontend. You can do that yourself if you write code, see Frontend. Or a frontend developer picks it up. Either way, stay involved: review the pull request, and check that the result matches the intent. When the change affects a component or pattern, the page about it in this area gets updated too.

• Read how we design, to see the whole path from idea to decision.
• Read the principles and who we design for.
• Check accessibility before you share a design. It is much easier to get right early.