#designsystem

Creating, Maintaining, and Championing the Adoption of Cayuse's Design System

An example of how I audited different components, in this case a load indicator

  1. Auditing the current products
  • Multiple product teams had different usage of components on their products
  • Designers using different components with different styles, sizes, etc.
  • Different code caused different behavior and accessibility issues
  • No consistency

A look at how the components look in the Figma library, created from scratch

Key Points

  • Over 50+ Components/Patterns audited
  • Created Figma component library
  • Created documentation outlining acceptance criteria
  • 200+ accessibility issues fix by Accessibility initiative
  • Worked with developers to create 50+ code ready components in code library
  1. Creating the Figma Library
  • Using Figma features to create components and variants (eg. Product specific)
  • Improved efficiency in creating wireframes

Form element component - shows how I used variants to build component for any situation

  1. Creating Documentation
  • Documenting all aspects of how component is used
  • Not only for designs, but criteria to be followed by PMs and Devs as well

Design System documentation lived in a Confluence space.

  1. Accessibility Initiative
  • Aligned with company wide accessibility initiative, but not originally part of plan
  • Always have accessibility in mind when creating components + documentation
  • Allowed for a better way to prioritize some work
  • Allowed for large amount of ticketed accessibility issues to be dealt with at once

An example of what Accessibility Guidelines looked like in documentation

  1. Code ready components
  • Worked with developers to make a code ready library in a service called bit.dev
  • Would review every component to make sure it matched the documentation and accessibility guidelines
  • Worked with other teams to make sure components were usable and did not break current live product

An example of how I audited different components, in this case a load indicator

The "Common Header" component,. Very important as it was one of the few shared components used by EVERY product

Dialog component, also called a pattern. In Figma page, would contain examples and rules

© Nick Brosas Design 2025

I don't really know what to put in a footer for a portfolio

#designsystem

Creating, Maintaining, and Championing the Adoption of Cayuse's Design System

An example of how I audited different components, in this case a load indicator

  1. Auditing the current products
  • Multiple product teams had different usage of components on their products
  • Designers using different components with different styles, sizes, etc.
  • Different code caused different behavior and accessibility issues
  • No consistency

A look at how the components look in the Figma library, created from scratch

Key Points

  • Over 50+ Components/Patterns audited
  • Created Figma component library
  • Created documentation outlining acceptance criteria
  • 200+ accessibility issues fix by Accessibility initiative
  • Worked with developers to create 50+ code ready components in code library
  1. Creating the Figma Library
  • Using Figma features to create components and variants (eg. Product specific)
  • Improved efficiency in creating wireframes

Form element component - shows how I used variants to build component for any situation

  1. Creating Documentation
  • Documenting all aspects of how component is used
  • Not only for designs, but criteria to be followed by PMs and Devs as well

Design System documentation lived in a Confluence space.

  1. Accessibility Initiative
  • Aligned with company wide accessibility initiative, but not originally part of plan
  • Always have accessibility in mind when creating components + documentation
  • Allowed for a better way to prioritize some work
  • Allowed for large amount of ticketed accessibility issues to be dealt with at once

An example of what Accessibility Guidelines looked like in documentation

  1. Code ready components
  • Worked with developers to make a code ready library in a service called bit.dev
  • Would review every component to make sure it matched the documentation and accessibility guidelines
  • Worked with other teams to make sure components were usable and did not break current live product

An example of how I audited different components, in this case a load indicator

The "Common Header" component,. Very important as it was one of the few shared components used by EVERY product

Dialog component, also called a pattern. In Figma page, would contain examples and rules

© Nick Brosas Design 2025

I don't really know what to put in a footer for a portfolio

#designsystem

Creating, Maintaining, and Championing the Adoption of Cayuse's Design System

Key Points

  • Over 50+ Components/Patterns audited
  • Created Figma component library
  • Created documentation outlining acceptance criteria
  • 200+ accessibility issues fix by Accessibility initiative
  • Worked with developers to create 50+ code ready components in code library

A look at how the components look in the Figma library, created from scratch

  1. Auditing the current products
  • Multiple product teams had different usage of components on their products
  • Designers using different components with different styles, sizes, etc.
  • Different code caused different behavior and accessibility issues
  • No consistency

An example of how I audited different components, in this case a load indicator

  1. Creating the Figma Library
  • Using Figma features to create components and variants (eg. Product specific)
  • Improved efficiency in creating wireframes

Form element component - shows how I used variants to build component for any situation

  1. Creating Documentation
  • Documenting all aspects of how component is used
  • Not only for designs, but criteria to be followed by PMs and Devs as well

Design System documentation lived in a Confluence space.

  1. Accessibility Initiative
  • Aligned with company wide accessibility initiative, but not originally part of plan
  • Always have accessibility in mind when creating components + documentation
  • Allowed for a better way to prioritize some work
  • Allowed for large amount of ticketed accessibility issues to be dealt with at once

An example of what Accessibility Guidelines looked like in documentation

  1. Code ready components
  • Worked with developers to make a code ready library in a service called bit.dev
  • Would review every component to make sure it matched the documentation and accessibility guidelines
  • Worked with other teams to make sure components were usable and did not break current live product

An example of how I audited different components, in this case a load indicator

The "Common Header" component,. Very important as it was one of the few shared components used by EVERY product

Dialog component, also called a pattern. In Figma page, would contain examples and rules

© Nick Brosas Design 2025

I don't really know what to put in a footer for a portfolio