Seeds Design System
Multi-brand design system powering an an accessible open source housing platform
Client:
Bloom Housing
Role:
Design systems lead
Skills:
Multi brand design tokens, Component library, Patterns and guidelines, Documentation and governance
Seeds Design System
Multi-brand design system powering an an accessible open source housing platform
Client:
Bloom Housing
Role:
Design systems lead
Skills:
Multi brand design tokens, Component library, Patterns and guidelines, Documentation and governance
Seeds Design System
Multi-brand design system powering an an accessible open source housing platform
Client:
Bloom Housing
Role:
Design systems lead
Skills:
Multi brand design tokens, Component library, Patterns and guidelines, Documentation and governance
Problem
Bloom Housing had an inherited an design language and needed a new design system to allow the open source platform to be used by anyone. The existing system, provided a solid foundation but had several elements that were very opinionated to the original brand that would need to be white-labeled in order to be flexible.
Since several instances of the product were currently in development we needed to support an approach that would allow for current consumers to uptake the new system. I knew that our success would depend on a deep collaboration between design and engineering teams.
Problem
Bloom Housing had an inherited an design language and needed a new design system to allow the open source platform to be used by anyone. The existing system, provided a solid foundation but had several elements that were very opinionated to the original brand that would need to be white-labeled in order to be flexible.
Since several instances of the product were currently in development we needed to support an approach that would allow for current consumers to uptake the new system. I knew that our success would depend on a deep collaboration between design and engineering teams.
Problem
Bloom Housing had an inherited an design language and needed a new design system to allow the open source platform to be used by anyone. The existing system, provided a solid foundation but had several elements that were very opinionated to the original brand that would need to be white-labeled in order to be flexible.
Since several instances of the product were currently in development we needed to support an approach that would allow for current consumers to uptake the new system. I knew that our success would depend on a deep collaboration between design and engineering teams.
Approach
Along with engineering partners, we outlined an approach that would allow us start small and maintain the flexibility to meet challenges as they developed and the system grew. We had learned that not everything needed to go into the core design system and knew we wanted to create a modular system rooted in atomic design, that would allow us to serve the needs of a growing community.
We proposed an architecture rooted in foundational tokens and a set of flexible core components. Once we had this in place, we knew we could begin adding layers to the system to support our specific content and behavioral patterns.
Approach
Along with engineering partners, we outlined an approach that would allow us start small and maintain the flexibility to meet challenges as they developed and the system grew. We had learned that not everything needed to go into the core design system and knew we wanted to create a modular system rooted in atomic design, that would allow us to serve the needs of a growing community.
We proposed an architecture rooted in foundational tokens and a set of flexible core components. Once we had this in place, we knew we could begin adding layers to the system to support our specific content and behavioral patterns.
Approach
Along with engineering partners, we outlined an approach that would allow us start small and maintain the flexibility to meet challenges as they developed and the system grew. We had learned that not everything needed to go into the core design system and knew we wanted to create a modular system rooted in atomic design, that would allow us to serve the needs of a growing community.
We proposed an architecture rooted in foundational tokens and a set of flexible core components. Once we had this in place, we knew we could begin adding layers to the system to support our specific content and behavioral patterns.
Outcome
Leading design efforts, I worked with my engineering parters to create a design system that could scale across California and nationally.
Token Library that allows for multi-brand theming
Seeds Components that serve as the building blocks for rapid UI development
Additional Patterns library for more complex components and content templates
Centralized documentation site for designers and engineers
Outcome
Leading design efforts, I worked with my engineering parters to create a design system that could scale across California and nationally.
Token Library that allows for multi-brand theming
Seeds Components that serve as the building blocks for rapid UI development
Additional Patterns library for more complex components and content templates
Centralized documentation site for designers and engineers
Outcome
Leading design efforts, I worked with my engineering parters to create a design system that could scale across California and nationally.
Token Library that allows for multi-brand theming
Seeds Components that serve as the building blocks for rapid UI development
Additional Patterns library for more complex components and content templates
Centralized documentation site for designers and engineers
Foundational tokens
Design systems need a foundational set of tokens to establish the shared language the team will use. We looked at a number of existing systems before landing on a concise framework that would give us the flexibility we needed. We established an intuitive BEM like naming convention that everyone could begin to use to describe each token. We used a base 8 system that links our typography and spacing rules together. For our color system we relied on HSL color to give us predictable tints and shades that would ensure consistency and accessibility.
Foundational tokens
Design systems need a foundational set of tokens to establish the shared language the team will use. We looked at a number of existing systems before landing on a concise framework that would give us the flexibility we needed. We established an intuitive BEM like naming convention that everyone could begin to use to describe each token. We used a base 8 system that links our typography and spacing rules together. For our color system we relied on HSL color to give us predictable tints and shades that would ensure consistency and accessibility.
Foundational tokens
Design systems need a foundational set of tokens to establish the shared language the team will use. We looked at a number of existing systems before landing on a concise framework that would give us the flexibility we needed. We established an intuitive BEM like naming convention that everyone could begin to use to describe each token. We used a base 8 system that links our typography and spacing rules together. For our color system we relied on HSL color to give us predictable tints and shades that would ensure consistency and accessibility.
Flexible component layers
For our components, we leaned on atomic design principles to establish our core “seeds” components first. Our Seeds components provide our users with all of the basic building blocks they need to quickly stand up a layout in browser quickly. I worked closely with engineering to ensure I mapped Figma properties to React in order to build on a shared understanding of functionality and variants. Once we had our Seeds in place, we created Patterns to act as content and layout guidelines to document how components could be assembled into use cases.
Flexible component layers
For our components, we leaned on atomic design principles to establish our core “seeds” components first. Our Seeds components provide our users with all of the basic building blocks they need to quickly stand up a layout in browser quickly. I worked closely with engineering to ensure I mapped Figma properties to React in order to build on a shared understanding of functionality and variants. Once we had our Seeds in place, we created Patterns to act as content and layout guidelines to document how components could be assembled into use cases.
Flexible component layers
For our components, we leaned on atomic design principles to establish our core “seeds” components first. Our Seeds components provide our users with all of the basic building blocks they need to quickly stand up a layout in browser quickly. I worked closely with engineering to ensure I mapped Figma properties to React in order to build on a shared understanding of functionality and variants. Once we had our Seeds in place, we created Patterns to act as content and layout guidelines to document how components could be assembled into use cases.
Challenges and learnings
Since we had existing implementations in the wild, we needed to understand what interest and capacity existed to make the updates. We got feedback that some folks would need the option to cherry pick updates in order to meet their own timelines. To resolve this we set up slack channels to announce updates and field questions. in order to provide transparency, we also aligned on how to document updates in each release.
Challenges and learnings
Since we had existing implementations in the wild, we needed to understand what interest and capacity existed to make the updates. We got feedback that some folks would need the option to cherry pick updates in order to meet their own timelines. To resolve this we set up slack channels to announce updates and field questions. in order to provide transparency, we also aligned on how to document updates in each release.
Challenges and learnings
Since we had existing implementations in the wild, we needed to understand what interest and capacity existed to make the updates. We got feedback that some folks would need the option to cherry pick updates in order to meet their own timelines. To resolve this we set up slack channels to announce updates and field questions. in order to provide transparency, we also aligned on how to document updates in each release.
Customizable themes
Our initial challenge was building a system that could be customized and branded. We started by creating primitive and semantic token layers. I used a combination of Token Studio and Figma native variables to manage each brand and mode. I created a color system that would provide consistent contrast values for foreground text based on the chosen brand color, helping with accessibility.
Customizable themes
Our initial challenge was building a system that could be customized and branded. We started by creating primitive and semantic token layers. I used a combination of Token Studio and Figma native variables to manage each brand and mode. I created a color system that would provide consistent contrast values for foreground text based on the chosen brand color, helping with accessibility.
Customizable themes
Our initial challenge was building a system that could be customized and branded. We started by creating primitive and semantic token layers. I used a combination of Token Studio and Figma native variables to manage each brand and mode. I created a color system that would provide consistent contrast values for foreground text based on the chosen brand color, helping with accessibility.
Challenges and learnings
Design and engineering tools have different models for how to accomplish multi-brand themes. Our early attempts at this led to unique implementations that felt dictated by the tools.
To get around this, I sat down with engineering and shifted the language we were using to better align with the engineering model. Eventually Token Studio provided a way to get around the limitations on the number of modes we ran into with Figma.
Challenges and learnings
Design and engineering tools have different models for how to accomplish multi-brand themes. Our early attempts at this led to unique implementations that felt dictated by the tools.
To get around this, I sat down with engineering and shifted the language we were using to better align with the engineering model. Eventually Token Studio provided a way to get around the limitations on the number of modes we ran into with Figma.
Challenges and learnings
Design and engineering tools have different models for how to accomplish multi-brand themes. Our early attempts at this led to unique implementations that felt dictated by the tools.
To get around this, I sat down with engineering and shifted the language we were using to better align with the engineering model. Eventually Token Studio provided a way to get around the limitations on the number of modes we ran into with Figma.
Documentation as a source of truth
Designers love Figma and engineers rely on Storybook, so we needed to find a way to provide a centralized source of documentation that represented everyone’s need. We landed on zeroheight as our solution which allowed us to integrate both design and code assets. I architected the documentation to serve as onboarding for each function, and designed the content to provide value to both sets of user needs, including technical specifications and use cases.
Documentation as a source of truth
Designers love Figma and engineers rely on Storybook, so we needed to find a way to provide a centralized source of documentation that represented everyone’s need. We landed on zeroheight as our solution which allowed us to integrate both design and code assets. I architected the documentation to serve as onboarding for each function, and designed the content to provide value to both sets of user needs, including technical specifications and use cases.
Documentation as a source of truth
Designers love Figma and engineers rely on Storybook, so we needed to find a way to provide a centralized source of documentation that represented everyone’s need. We landed on zeroheight as our solution which allowed us to integrate both design and code assets. I architected the documentation to serve as onboarding for each function, and designed the content to provide value to both sets of user needs, including technical specifications and use cases.
Challenges and learnings
A single source of truth sounds good in theory, but the reality is that designers and engineers spend the bulk of their time in their tools of choice. The challenge become how could we bring the documentation to them.
I’m not sure if we cracked this but we did experiment with Figma previews in VS Code and documentation links within Figma. All of this is currently been shuffled again due to the rise of MCP and needs to be revisited again.
Challenges and learnings
A single source of truth sounds good in theory, but the reality is that designers and engineers spend the bulk of their time in their tools of choice. The challenge become how could we bring the documentation to them.
I’m not sure if we cracked this but we did experiment with Figma previews in VS Code and documentation links within Figma. All of this is currently been shuffled again due to the rise of MCP and needs to be revisited again.
Challenges and learnings
A single source of truth sounds good in theory, but the reality is that designers and engineers spend the bulk of their time in their tools of choice. The challenge become how could we bring the documentation to them.
I’m not sure if we cracked this but we did experiment with Figma previews in VS Code and documentation links within Figma. All of this is currently been shuffled again due to the rise of MCP and needs to be revisited again.
Features and systems
Once we had the updated design system in place, we had to provide additional guidance to help with adoption. In the original version, the design system was overly prescriptive and an unintentional bottleneck. I worked with product team designers to establish a feature workflow, that would allow them to use as much of what they could from the system and innovate as needed to meet deadlines. I created a governance workflow, that included a process of checking for needs against the current design system to avoid duplication, but provided the freedom to build for specific use cases.
Features and systems
Once we had the updated design system in place, we had to provide additional guidance to help with adoption. In the original version, the design system was overly prescriptive and an unintentional bottleneck. I worked with product team designers to establish a feature workflow, that would allow them to use as much of what they could from the system and innovate as needed to meet deadlines. I created a governance workflow, that included a process of checking for needs against the current design system to avoid duplication, but provided the freedom to build for specific use cases.
Features and systems
Once we had the updated design system in place, we had to provide additional guidance to help with adoption. In the original version, the design system was overly prescriptive and an unintentional bottleneck. I worked with product team designers to establish a feature workflow, that would allow them to use as much of what they could from the system and innovate as needed to meet deadlines. I created a governance workflow, that included a process of checking for needs against the current design system to avoid duplication, but provided the freedom to build for specific use cases.
Challenges and learnings
I continue to revisit what resolution feature teams should to deliver in. In previous iterations, feature teams would create high resolution “mockups” for each “screenshot” within a user flow. Even with a design system, this is time consuming.
In later iterations, designers have moved towards delivering “content wireframes” that document the user flow with lighter weight references to the components that are already well documented. The hope is to focus the design on use cases and outcomes and share the UI responsibilities with engineering partners.
Challenges and learnings
I continue to revisit what resolution feature teams should to deliver in. In previous iterations, feature teams would create high resolution “mockups” for each “screenshot” within a user flow. Even with a design system, this is time consuming.
In later iterations, designers have moved towards delivering “content wireframes” that document the user flow with lighter weight references to the components that are already well documented. The hope is to focus the design on use cases and outcomes and share the UI responsibilities with engineering partners.
Challenges and learnings
I continue to revisit what resolution feature teams should to deliver in. In previous iterations, feature teams would create high resolution “mockups” for each “screenshot” within a user flow. Even with a design system, this is time consuming.
In later iterations, designers have moved towards delivering “content wireframes” that document the user flow with lighter weight references to the components that are already well documented. The hope is to focus the design on use cases and outcomes and share the UI responsibilities with engineering partners.
Sharing accessibility responsibilities
The team aligned early on accessibility as a core principle and value. I brought in accessibility experts from LightHouse for the Blind to consult on how we could ensure the building blocks we created were as accessible as the could be. Our color system was designed to maintain AA color contrast ratios. Each of our components was reviewed for accessibility requirements and usage guidelines were clearly documented. We also took the time to outline inclusive design best practices for content writing, form fields and validation errors.
Sharing accessibility responsibilities
The team aligned early on accessibility as a core principle and value. I brought in accessibility experts from LightHouse for the Blind to consult on how we could ensure the building blocks we created were as accessible as the could be. Our color system was designed to maintain AA color contrast ratios. Each of our components was reviewed for accessibility requirements and usage guidelines were clearly documented. We also took the time to outline inclusive design best practices for content writing, form fields and validation errors.
Sharing accessibility responsibilities
The team aligned early on accessibility as a core principle and value. I brought in accessibility experts from LightHouse for the Blind to consult on how we could ensure the building blocks we created were as accessible as the could be. Our color system was designed to maintain AA color contrast ratios. Each of our components was reviewed for accessibility requirements and usage guidelines were clearly documented. We also took the time to outline inclusive design best practices for content writing, form fields and validation errors.
Key takeaways
Through collaboration with engineering partners, we were able to build a design system based on collaboration and a shared empathy for each other needs. Our approach allowed us to create a system that was based in the core accessibility needs of our end users and empowered an open source community to build implementations based on their brands and business rules.
Key takeaways
Through collaboration with engineering partners, we were able to build a design system based on collaboration and a shared empathy for each other needs. Our approach allowed us to create a system that was based in the core accessibility needs of our end users and empowered an open source community to build implementations based on their brands and business rules.
Key takeaways
Through collaboration with engineering partners, we were able to build a design system based on collaboration and a shared empathy for each other needs. Our approach allowed us to create a system that was based in the core accessibility needs of our end users and empowered an open source community to build implementations based on their brands and business rules.