Knox Design System

The Knox Design System consists of design guidelines, standards, and reusable components that empowers designers, engineers, and content to build efficiently and consistently at scale.

In adherence to my non-disclosure agreement, I have excluded and obscured confidential information within this case study. The content presented here is solely my own and may not necessarily align with the perspectives of 1Password.

Image

0.0 Foundations

Knox Design System

The Knox Design System consists of design guidelines, standards, and reusable components that empowers designers, engineers, and content to build efficiently and consistently at scale.

In adherence to my non-disclosure agreement, I have excluded and obscured confidential information within this case study. The content presented here is solely my own and may not necessarily align with the perspectives of 1Password.

Image

0.0 Foundations

Knox Design System

The Knox Design System consists of design guidelines, standards, and reusable components that empowers designers, engineers, and content to build efficiently and consistently at scale.

In adherence to my non-disclosure agreement, I have excluded and obscured confidential information within this case study. The content presented here is solely my own and may not necessarily align with the perspectives of 1Password.

Image

0.0 Foundations

Context

Context

The product design team grew expeditiously to help support internal business partners on new software initiatives within password management for consumers and workforce security in enterprise. These projects ran into difficulties during the development process due to inconsistent styles, patterns, and components across our product portfolio. Design and engineering had made tough decisions without realizing the impact that it has on other parts of the product.

The product design team grew expeditiously to help support internal business partners on new software initiatives within password management for consumers and workforce security in enterprise. These projects ran into difficulties during the development process due to inconsistent styles, patterns, and components across our product portfolio. Design and engineering had made tough decisions without realizing the impact that it has on other parts of the product.

Involvement

Involvement

As a product designer and a contributor to the design system, my responsibilities included working cross-functionally with a product manager and team members to define the product roadmap, refining and testing our contribution model, pairing with engineers to create new components and update existing components and more.

As a product designer and a contributor to the design system, my responsibilities included working cross-functionally with a product manager and team members to define the product roadmap, refining and testing our contribution model, pairing with engineers to create new components and update existing components and more.

Goals

Goals

  • Reduce inconsistencies between design and development

  • Reduce time spent on keeping design files updated

  • Improve speed by reducing creating components from scratch

  • Reduce time spent onboarding new designers and engineers

  • Reduce inconsistencies between design and development

  • Reduce time spent on keeping design files updated

  • Improve speed by reducing creating components from scratch

  • Reduce time spent onboarding new designers and engineers

Methods

Methods

Design System, User Experience Design (UX), Adoption Planning, Stakeholder Interviews, Facilitation Workshops, User Research, and Customer Journey Map

Design System, User Experience Design (UX), Adoption Planning, Stakeholder Interviews, Facilitation Workshops, User Research, and Customer Journey Map

Team

Team

Product Designer (Me), Product Manager, Lead Product Designer, Technical Lead, Engineers, Content Designer

Product Designer (Me), Product Manager, Lead Product Designer, Technical Lead, Engineers, Content Designer

Challenge

1Password lacked a design system that designers and engineers can reference to build products faster and consistently at scale. Teams were spending a lot of time and effort into keeping files up to date—even though it was immensely unmanageable. Multiple squads within those product teams across the organization suffered from duplication in their work through which they were constantly reinventing the wheel each time. This led to drastically different end-user experiences even in our well-established products.

1Password lacked a design system that designers and engineers can reference to build products faster and consistently at scale. Teams were spending a lot of time and effort into keeping files up to date—even though it was immensely unmanageable. Multiple squads within those product teams across the organization suffered from duplication in their work through which they were constantly reinventing the wheel each time. This led to drastically different end-user experiences even in our well-established products.

We needed to simplify the process to production for our design and engineering partners so they could focus on delivering consistent and seamless end-to-end experiences to our customers.

We needed to simplify the process to production for our design and engineering partners so they could focus on delivering consistent and seamless end-to-end experiences to our customers.

01

How might we build a design system that fosters cohesion and trust across all products and features?

How might we build a design system that fosters cohesion and trust across all products and features?

How might we build a design system that fosters cohesion and trust across all products and features?

02

How might we minimize redundant work with the help of a design system enabling builders to focus on their product areas?

How might we minimize redundant work with the help of a design system enabling builders to focus on their product areas?

How might we minimize redundant work with the help of a design system enabling builders to focus on their product areas?

Understand the new problem space

Conducting stakeholder interviews

Building a new design system is just as challenging as getting people to rally around it. I partnered with a user researcher to facilitate an internal stakeholder interview to understand the needs of both designers and engineers. We focused on these two customer segmentation for our research effort because their line of work are cross-functional in nature and both groups are most involved in the stages of the product development lifecycle from: planning, concept generation, product and process verification, launch, and last of all post-launch assessment.

Building a new design system is just as challenging as getting people to rally around it. I partnered with a user researcher to facilitate an internal stakeholder interview to understand the needs of both designers and engineers. We focused on these two customer segmentation for our research effort because their line of work are cross-functional in nature and both groups are most involved in the stages of the product development lifecycle from: planning, concept generation, product and process verification, launch, and last of all post-launch assessment.

We conducted interviews with a total of 30 people across the organization (a split between 16 engineers and 14 designers). Since employees worked remotely across different timezones, we planned each interview session to last approximately 45 mins to manage time effectively for busy stakeholders and leave time for conversation at the end of the session to unearth additional barriers if they arise.

We conducted interviews with a total of 30 people across the organization (a split between 16 engineers and 14 designers). Since employees worked remotely across different timezones, we planned each interview session to last approximately 45 mins to manage time effectively for busy stakeholders and leave time for conversation at the end of the session to unearth additional barriers if they arise.

Engineers want to work more effectively throughout the development cycle and to have a shared language with others on the team, specifically with the UX team.

  • Automate repetitive and mundane work where possible so that engineering can put more focus on higher-value work.

  • Automate repetitive and mundane work where possible so that engineering can put more focus on higher-value work.

  • Have engineering and design teams to work in parallel together and adhering to a unified design language.

  • Have engineering and design teams to work in parallel together and adhering to a unified design language.

  • Improve code quality without sacrificing efficiency, while also having cross-functional clarity to help remove redundancies in the product development process.

  • Improve code quality without sacrificing efficiency, while also having cross-functional clarity to help remove redundancies in the product development process.

Designers want to save time in unnecessary feedback loops and reduce the complexity in the implementation of their designs when collaborating with engineers.

  • Have more knowledge on the component guidelines and patterns that are important for them to know to design experiences that fit together seamlessly.

  • Have more knowledge on the component guidelines and patterns that are important for them to know to design experiences that fit together seamlessly.

  • Have centralized access to design assets and information to the speed up their work flow.

  • Have centralized access to design assets and information to the speed up their work flow.

  • Have high-confidence that my design decisions is good for customers and are technically feasible for engineers to build.

  • Have high-confidence that my design decisions is good for customers and are technically feasible for engineers to build.

Image

1.1 Stakeholder Interview

Image

1.1 Stakeholder Interview

Identifying end-users of the design system across functions

The stakeholder interview helped me identify the user personas and about the roles of each individual in the organization with addition to their current frustrations and pain points. I worked with a user researcher to clarify the insights generated. We then took an additional step by running ideation workshops and cross-functional alignment sessions to build our vision with internal partners and understand where to focus our efforts to create a design system that could be easily adopted by everyone. This enabled the Design System Team to better empathize with the people we are building the design system for.

The stakeholder interview helped me identify the user personas and about the roles of each individual in the organization with addition to their current frustrations and pain points. I worked with a user researcher to clarify the insights generated. We then took an additional step by running ideation workshops and cross-functional alignment sessions to build our vision with internal partners and understand where to focus our efforts to create a design system that could be easily adopted by everyone. This enabled the Design System Team to better empathize with the people we are building the design system for.

The personas provided the team with high-level information about both engineers and designers journey as well as detailing where the pain points and frustrations are presented in the software development phases. It also revealed the lack of inconsistency in how teams operated in the organization—most of which is caused by working in silos. It was clear that there was definitely a gap that we needed fill.

The personas provided the team with high-level information about both engineers and designers journey as well as detailing where the pain points and frustrations are presented in the software development phases. It also revealed the lack of inconsistency in how teams operated in the organization—most of which is caused by working in silos. It was clear that there was definitely a gap that we needed fill.

Lack of consistency made it difficult for designers to work in a organized manner as they tend to adapt very agilely to support the needs of the development teams.

  • Lack of UI consistency creates redundancy in the UX teams workflow which demanded designers into duplicative work.

  • Lack of UI consistency creates redundancy in the UX teams workflow which demanded designers into duplicative work.

  • Design recommendations often times were not implemented fully to the design specification because it modifies existing component or patterns that’s not available in code.

  • Design recommendations often times were not implemented fully to the design specification because it modifies existing component or patterns that’s not available in code.

  • The design team struggles move into the implementation phase rapidly with high confidence Trade-offs were regularly made between the designer and their engineering partner to ensure that the designs were technically feasible.

  • The design team struggles move into the implementation phase rapidly with high confidence Trade-offs were regularly made between the designer and their engineering partner to ensure that the designs were technically feasible.

Engineers lacked awareness of how UX teams operate in order to release products that properly serves the user needs of 1Password customers.

  • Lack of code reusability creates inefficiencies in the development teams workflow.

  • Lack of code reusability creates inefficiencies in the development teams workflow.

  • Not having a reliable single source of truth (SSOT) creates a lot of unnecessary reactive work for the development team.

  • Not having a reliable single source of truth (SSOT) creates a lot of unnecessary reactive work for the development team.

  • Modifying styles and implementing a slew of one-off components decreases the cadence of releases while also make both teams to deal with pressing deadlines that they have to meet.

  • Modifying styles and implementing a slew of one-off components decreases the cadence of releases while also make both teams to deal with pressing deadlines that they have to meet.

Image

1.2 User Persona

Image

1.2 User Persona

Image

1.3 User Persona

Image

1.3 User Persona

Tokenizing and abstracting design tokens

Another aspect of the design system we took time to define were design tokens. These tokens are the single source of truth (SSOT) to name and store design decisions that could be distributed across design tools and code languages.

Another aspect of the design system we took time to define were design tokens. These tokens are the single source of truth (SSOT) to name and store design decisions that could be distributed across design tools and code languages.

Design tokens are important because they us help define the visual foundations of the design system. Atomically, they represent the values used within a design system to construct layouts and components. Up until this point, the team had not standardized any set of design tokens for the team to use, except for styles that only exist in Figma that doesn't match with code.

Design tokens are important because they us help define the visual foundations of the design system. Atomically, they represent the values used within a design system to construct layouts and components. Up until this point, the team had not standardized any set of design tokens for the team to use, except for styles that only exist in Figma that doesn't match with code.

In order to define these design tokens, I collaborated closely with a staff product designer and product manager to organize the effort for this work. We then proceeded with the design tokens standardization efforts by creating a set of tokens and working with engineers to encode the design decisions to their specific platform mapped to our token naming principles. We decided to only focus on design tokens for Q1 as doing this would allow us to move more quickly and efficiently in our work efforts in the next quarter onward.

In order to define these design tokens, I collaborated closely with a staff product designer and product manager to organize the effort for this work. We then proceeded with the design tokens standardization efforts by creating a set of tokens and working with engineers to encode the design decisions to their specific platform mapped to our token naming principles. We decided to only focus on design tokens for Q1 as doing this would allow us to move more quickly and efficiently in our work efforts in the next quarter onward.

Color tokens

Color tokens are used to express style and communicate meaning throughout our components and user interfaces. Our color tokens are named semantically to help communicate the intent of a color and to create predictability and usability across our token set.

Color tokens are used to express style and communicate meaning throughout our components and user interfaces. Our color tokens are named semantically to help communicate the intent of a color and to create predictability and usability across our token set.

Image

2.0 Color

Image

2.0 Color

Typography tokens

Typography tokens are used to organize and structures content. Our type ramp has various typographical options that help make content legible and accessible for people to find their way through an experience.

Typography tokens are used to organize and structures content. Our type ramp has various typographical options that help make content legible and accessible for people to find their way through an experience.

Image

2.1 Typography

Image

2.1 Typography

Spacing tokens

Spacings tokens are used to help make content easier to scan for users and to separate elements such as components and layout blocks both horizontally, and vertically.

Spacings tokens are used to help make content easier to scan for users and to separate elements such as components and layout blocks both horizontally, and vertically.

Image

2.2 Spacing

Image

2.2 Spacing

Elevation tokens

Elevation tokens are used to add depth or improve the visual cue of a component by giving the appearance of distance between other elements, and the surface behind it.

Elevation tokens are used to add depth or improve the visual cue of a component by giving the appearance of distance between other elements, and the surface behind it.

Image

2.3 Elevation

Image

2.3 Elevation

Corner radius tokens

Corner radius tokens are used to give sharp edges a more subtle, rounded effect. Every 1Password component has a specific effect that responds to the use or characteristics of rounded corners.

Corner radius tokens are used to give sharp edges a more subtle, rounded effect. Every 1Password component has a specific effect that responds to the use or characteristics of rounded corners.

Image

2.4 Corner Radius

Image

2.4 Corner Radius

Standardizing components for consistency and accessibility

Before any component work could be explored, we needed to define our priorities and make sure we achieve design system deliverables that are most important in a certain time frame and inform us on how to proceed with our design standardization efforts.

Before any component work could be explored, we needed to define our priorities and make sure we achieve design system deliverables that are most important in a certain time frame and inform us on how to proceed with our design standardization efforts.

I collaborated with a staff product designer and with several product designers and engineers on the team to work with the product manager to lay out a plan to execute our strategy and help make sure our goals and the approach to achieve them are clearly defined and aligned throughout the organization and the stakeholders that we work with.

I collaborated with a staff product designer and with several product designers and engineers on the team to work with the product manager to lay out a plan to execute our strategy and help make sure our goals and the approach to achieve them are clearly defined and aligned throughout the organization and the stakeholders that we work with.

MoSCoW prioritization framework was used to help identify existing components in the product and categorize them into four different prioritization levels: must-have, should-have, could-have, and won't-have. For example, design tokens are non-negotiable deliverables that are essential to the success of the project and the teams quarterly objectives. So therefore, this task is grouped into ‘must-haves’. This exercise was repeated among our team until all the components were catalogued into their own groups. The next step was to create tasks in our repository and divide the work for each design system contributor to accomplish.

MoSCoW prioritization framework was used to help identify existing components in the product and categorize them into four different prioritization levels: must-have, should-have, could-have, and won't-have. For example, design tokens are non-negotiable deliverables that are essential to the success of the project and the teams quarterly objectives. So therefore, this task is grouped into ‘must-haves’. This exercise was repeated among our team until all the components were catalogued into their own groups. The next step was to create tasks in our repository and divide the work for each design system contributor to accomplish.

Image

3.0 Component Library

Image

3.0 Component Library

Video

3.1 Switch

Video

3.1 Switch

Video

3.2 Expandable Bar

Video

3.2 Expandable Bar

Video

3.3 Callout

Video

3.3 Callout

Video

3.4 Checkbox

Video

3.4 Checkbox

Video

3.5 Modal

Video

3.5 Modal

Video

3.6 Menu

Video

3.6 Menu

Video

3.7 Toast

Video

3.7 Toast

Video

3.8 Progress Bar

Video

3.8 Progress Bar

Governance model

Establishing a systems thinking way of working

Another aspect of the design system we invested time into defining were contribution models. Contribution models are considerably important standards for our team because it served as rules and regulations that prioritizes what contributions people can request to have added into the system and what guidelines does it need to adhere to. Essentially, the contract represents the values we want to measure against and expectations in terms of quality of the contribution (does this contribution work universally across 1Password products).

Another aspect of the design system we invested time into defining were contribution models. Contribution models are considerably important standards for our team because it served as rules and regulations that prioritizes what contributions people can request to have added into the system and what guidelines does it need to adhere to. Essentially, the contract represents the values we want to measure against and expectations in terms of quality of the contribution (does this contribution work universally across 1Password products).

In order to ensure that the contribution model focused primarily on what the team’s need, I collaborated closely with another lead product designer on the team and a product manager to host a collaborative workshop to understand how we want to manage contributions and maintain the design system over time.

In order to ensure that the contribution model focused primarily on what the team’s need, I collaborated closely with another lead product designer on the team and a product manager to host a collaborative workshop to understand how we want to manage contributions and maintain the design system over time.

By the end of the workshop, I managed to define the rules of play that apply to contributions, and mapped a clear workflow of how contributions gets accepted into the design system. The new contribution model become the foundation of our current model. Our team was able to quickly increase transparency across design and engineering disciplines, all while creating a shared effort environment to help evolve the design system.

By the end of the workshop, I managed to define the rules of play that apply to contributions, and mapped a clear workflow of how contributions gets accepted into the design system. The new contribution model become the foundation of our current model. Our team was able to quickly increase transparency across design and engineering disciplines, all while creating a shared effort environment to help evolve the design system.

Image

4.0 Governance Model

Image

4.0 Governance Model

A breakdown of the our governance model in three phases

We started off as a centralized team focused on building a design system for teams across the organization to use. However, we quickly learned that for a large organizations like 1Password to scale faster, people outside the design systems team should feel enabled to contribute to the system.

We started off as a centralized team focused on building a design system for teams across the organization to use. However, we quickly learned that for a large organizations like 1Password to scale faster, people outside the design systems team should feel enabled to contribute to the system.

Our governance model framework has three phases. The screenshots below depicts the process flows and procedures that contributors typically goes through (defining the level of their job responsibilities) and what needs to be accomplished to ensure that every contribution has been rationalized collectively for universal adoption.

Our governance model framework has three phases. The screenshots below depicts the process flows and procedures that contributors typically goes through (defining the level of their job responsibilities) and what needs to be accomplished to ensure that every contribution has been rationalized collectively for universal adoption.

Image

4.1 Prioritization

Image

4.1 Prioritization

Image

4.2 Design & Documentation

Image

4.2 Design & Documentation

Image

4.3 Development & Publish

Image

4.3 Development & Publish

Evangelism and outreach

Beyond contributing to the design system, we highly focused on educating all teams in other departments to onboard them to the system and offer support when they are stuck. I was responsible for designing the documentation site, working with the content team to iterate on documentation, and using data to measure the success of the design system.

Beyond contributing to the design system, we highly focused on educating all teams in other departments to onboard them to the system and offer support when they are stuck. I was responsible for designing the documentation site, working with the content team to iterate on documentation, and using data to measure the success of the design system.

Communication is key to drive adoption

Design system changes how people use to do things. Having an open and honest discussion about team's hopes and fears of the design system allowed us to adjust how we communicate with teams, and start building a community of people who has ownership of it.

Design system changes how people use to do things. Having an open and honest discussion about team's hopes and fears of the design system allowed us to adjust how we communicate with teams, and start building a community of people who has ownership of it.

Solicit feedback

We continuously asked for feedback from designers and engineers to ensure that we were successful and are synchronized in the things we were contributing into the design system. Other designers on the team including myself joined other product pods to listen and monitor how the design system is being used and taking in the feedback and incorporating changes.

We continuously asked for feedback from designers and engineers to ensure that we were successful and are synchronized in the things we were contributing into the design system. Other designers on the team including myself joined other product pods to listen and monitor how the design system is being used and taking in the feedback and incorporating changes.

Mentoring other designers and engineers on using the system

To make adoption as seamless as possible, we published instructions on our documentation site, as well as usage guidance for all components so that designers and engineers have visibility and the knowledge needed to apply them into their work.

To make adoption as seamless as possible, we published instructions on our documentation site, as well as usage guidance for all components so that designers and engineers have visibility and the knowledge needed to apply them into their work.

Video

5.0 Documentation Site

Video

5.0 Documentation Site

Impact

The Knox Design System has become an essential tool that is heavily integrated into the designer and engineer workflows at 1Password. Since the first launch, the design system has driven consistency across our applications and that has improved our customer’s experience. The design system has also provided the building blocks that allow designers and engineers to focus on crafting new features instead of reinventing the wheel every time.

The Knox Design System has become an essential tool that is heavily integrated into the designer and engineer workflows at 1Password. Since the first launch, the design system has driven consistency across our applications and that has improved our customer’s experience. The design system has also provided the building blocks that allow designers and engineers to focus on crafting new features instead of reinventing the wheel every time.

Design systems work is not done yet. There are many things that we could improve to help us scale faster. We continually do quarterly community outreach to measure the success of the design system and keep track of what we could improve moving forward to keep momentum of the work going.

Design systems work is not done yet. There are many things that we could improve to help us scale faster. We continually do quarterly community outreach to measure the success of the design system and keep track of what we could improve moving forward to keep momentum of the work going.

10x

10x

10x

Improved speed of designing and shipping to market

80%

80%

80%

Increased design tokens adoption

60%

60%

60%

Reduced the number of snowflake components

200+

200+

200+

Components created

Retrospective

Learnings and recommendations

Designing the Knox Design System from 0–1 was a challenging, yet exciting experience. It was refreshing and fun getting to collaborate across disciplines to cultivate a community of creators so teams can build, share, and evolve the design system.

Designing the Knox Design System from 0–1 was a challenging, yet exciting experience. It was refreshing and fun getting to collaborate across disciplines to cultivate a community of creators so teams can build, share, and evolve the design system.

We now have a single source of truth. A design system that we could build upon and grow it together. Below are some valuable learnings and reflections of my journey.

We now have a single source of truth. A design system that we could build upon and grow it together. Below are some valuable learnings and reflections of my journey.

01

01

We don’t need to have everything

We don’t need to have everything

We don’t need to have everything

The business and product needs of another company is different from 1Password. In fact, there really isn’t a one-size fits all solution when it comes to building a design system. It was important for me to learn from my peers that roadblocks are inevitable and that making mistakes and contributing to the design system incrementally are all part of the process.

The business and product needs of another company is different from 1Password. In fact, there really isn’t a one-size fits all solution when it comes to building a design system. It was important for me to learn from my peers that roadblocks are inevitable and that making mistakes and contributing to the design system incrementally are all part of the process.

02

02

Consistency is important, but so is fostering trust

Consistency is important, but so is fostering trust

Consistency is important, but so is fostering trust

Collaborating in an organization to create a meaningful and impactful design system means that we need to take an empathic approach and treat every problem we encounter as an opportunity to grow and learn. Part of the design systems team job is to help people feel involved, consulted, and listened to. If a design system is too rigid, teams won’t be able to use it easily unless we turn it into a design system that is shared with the people it supports.

Collaborating in an organization to create a meaningful and impactful design system means that we need to take an empathic approach and treat every problem we encounter as an opportunity to grow and learn. Part of the design systems team job is to help people feel involved, consulted, and listened to. If a design system is too rigid, teams won’t be able to use it easily unless we turn it into a design system that is shared with the people it supports.

03

03

Involving engineering in the design process early

Involving engineering in the design process early

Involving engineering in the design process early

The earlier the engineering team is involved, concerns can be easily addressed promptly to avoid delays or time wasted developing a component that’s not useful or meet the vision of the team. Design system work involves close collaboration with stakeholders as well as engineering to mitigate potential technical limitations and inform the design strategy.

The earlier the engineering team is involved, concerns can be easily addressed promptly to avoid delays or time wasted developing a component that’s not useful or meet the vision of the team. Design system work involves close collaboration with stakeholders as well as engineering to mitigate potential technical limitations and inform the design strategy.

Image

6.0 Mobile Templates

Image

6.0 Mobile Templates

Image

6.1 Overall Product Templates

Image

6.1 Overall Product Templates

Looking for your next product designer?

Email me at hello@brlam.co or send me a message through LinkedIn. Let’s get in touch!

© 2024 Brian Lam. All Rights Reserved.

Looking for your next product designer?

Email me at hello@brlam.co or send me a message through LinkedIn. Let’s get in touch!

© 2024 Brian Lam. All Rights Reserved.

Looking for your next product designer?

Email me at hello@brlam.co or send me a message through LinkedIn. Let’s get in touch!

© 2024 Brian Lam. All Rights Reserved.