What is a Design System?
Here's my definition:
“A Design System is a product comprised of three parts: design components, code components, and cross-discipline documentation.”
User Pain Points
- Visual Design screens take too long to create
- Inconsistent UX with the UI Prototypes in User Testing
- Poor handoff experience with developers
- UI implementation did not meet professional standards for Visual Design consistency
- Slower development time to market
- Poor user experience
- Prototypes take too long to create
- No documentation
- Lack of parity between design and developers
Defining the Scope
I was a core contributor to HDS and instrumental to its success for three and a half years. My work on HDS began in 2019, shortly after I started full-time as an Associate Visual Designer. When I joined the team, my colleague Heidi Baggerman had created the first draft of the design components and some light documentation. The front-end dev team has also created a react code repository with several components.
The first development phase of HDS focused on creating components for all patterns and visuals present in our internal products at that time. Shortly after beginning this initiative, we migrated our files and design processes to the Figma product design application. This design system was the first that my partner Clay Porter and I had created, so determining the system's scope was our first challenge. We leaned heavily on the other designers on our team and the developers on our front-end UI team to decide what should be included based on their needs. Another method that we used was Precedent Research. We surveyed several top design systems to understand what the industry had determined were essential components for a stable design system. We used this research to create our project scope and began an audit of the web applications. We gathered screenshots of dozens of application elements and patterns and mapped those images to plans for updated designs.
What We Did
Under the guidance of my manager, Nick Mason, we started a bi-weekly discussion series with our front-end UI dev team. This series was cross-discipline and served as a reserved time for discussion and workshops on a regular cadence. Together we tackled several crucial issues, including but not limited to: addressing design debt, addressing tech debt, how to develop using borrowed time, creating a shared language, and assigning naming conventions.
Goals
- Offer a library of design components to
- Shorten the time needed to create Visual Designs
- Shorten the time needed to create Prototypes
- Create a more consistent UX within the UI Prototypes in User Testing
- Improve handoff experience with developers
- Meet professional standards for Visual Design consistency and user experience in web UI
- Lower development time to market
- Create useful documentation for key users
- Increase parity between design and developers
Documentation
We created our first iteration of documentation for the design system in Figma and mirrored the organization of the design components in our core design system file. Eventually, we realized the limitations of creating written documentation in a design program and decided it might be more efficient to create the documentation in the web app ZeroHeight. For the documentation in ZeroHeight, we did precedent research, examining what industry best practice dictated was most critical to include. Later, we worked with the developers to determine their documentation needs. We also talked with the developers about the affordances and constraints of Storybook versus ZeroHeight. At the time, our developers used Storybook for its visual representations and to test the props of the React components.
One of the value propositions of Design System documentation is that it provides a single “source of truth” for designers and developers to reference when further expanding the design system or building new experiences within the internal product suite. This documentation and the previously mentioned design system check-in series allowed us to develop a shared language that was instrumental in all further work on Horizon. We then spent over six months writing and structuring the design system documentation. We documented the majority of our components, starting with the essential ones. Documentation of our more complex components inspired new projects, which delayed the completion of the documentation but served as much-needed launching points for expanding the usefulness of the HDS beyond the current applications. We received a lot of positive feedback from our developers on the Design System, who often found it helpful and easy to follow. Clay and I recorded critical feedback on the documentation and made updates where appropriate.
Incorporating New Standards
After initial work on the HDS documentation in ZeroHeight slowed, product priorities shifted, and we shifted our efforts to smaller design systems needed for other parts of the business. The first was a design system the team later named the “Web Design Ecosystem,” which we created to support future work from the Marketing Design team on the corporate website. Shortly after, the consuming design team tabled the project due to a lack of interest. My Visual Design team partner Clay Porter and I then began work on a design system we would later rename the “Consumer Experience Design System.” This system served the consumer-facing Local Flavor app, which our parent company owned. On this project, we worked closely with the dev team at Local Flavor to simultaneously make overhauls to their existing web UI while also developing the system to meet future needs with the same goals. We advocated migrating to a React framework so that the dev team could convert repeat patterns into reusable components. Unfortunately, product leadership canceled this project when our parent company sold Local Flavor.
Clay and I learned a lot from these projects, and we took our new standards back to the HDS, which we could now continue developing. We renewed our focus on Responsive Design for the Web and recommitted to prioritizing accessibility in Universal Design. This meant putting accessibility first and designing for everyone, including atypical users. These renewed goals, alongside updates to Figma capabilities and features as a tool, spawned a “standards audit” where we redesigned each Horizon component according to the new design practices. In our most recent iteration of HDS, we focused on simple construction and incorporating user feedback along with the previously mentioned goals.
Color System
The final project I helped contribute to within HDS was creating a Color System. I’ve also documented this project within this web portfolio. Jump there now →
Outcomes
- Helped transition our visual design process to a component-based approach, decreasing the time to create visual designs from 2+ weeks to 6 hrs or less
- Enabled the launch of a new internal product with a time to launch of less than two months
- Fostered a strong and collaborative relationship with our Front-End Dev team, where colleagues describe me as a “regular member of the team”
- Ensured that universal accessibility was considered from the start of our design process, positioning our internal products to be WCAG-compliant
- Ensured brand consistency and industry standards via 85+ JIRA issues
- Supported updated company brand, which was crucial for launching new flagship products
- Supported colors for data visualization, which was vital for new Campaign Monitoring and Reporting dashboards in Tableau
- Contributed to dozens of components
