Design System Principal Architect, Engineer, & Design Manager
đź’ĽÂ brief
A small incident management software company with an existing product in market, with an inconsistent visual brand across the product surface.
No design system was in place but there was a strong desire to build one, in the hopes of benefitting from consistency and acceleration of the engineering cycle.
Leadership expressed no desire for permanently funding a Design System team, and upon my arrival only one (1) designer was on staff with no design leadership (or management) present.
table of contents
- đź’ĽÂ brief
- 🔍 objectives & constraints
- decisions
- Utilize existing component library
- Published as internal npm package
- Operate as Design Manager
- Secure headcount for 2 additional design roles
- âś…Â results
- Storybook
- Chromatic
- Playroom
- Changelog
- 🧑‍🏫 lessons learned
- đź”—Â links & resources
🔍 objectives & constraints
- Engineering transitioning from Ruby on Rails to Javascript frontend; desire for system to be built in JS; must assist (accelerate) this transition
- No appetite from leadership for a permanent staff for Design System
- Engineering sensitive to changes in product monorepo
- Immediate need for Design management
- Immediate need for additional Design ICs
decisions
As a direct result of several objectives and constraints, the following decisions were made…
Utilize existing component library
No appetite from leadership for a permanent staff for Design System
desire for system to be built in JS; must assist (accelerate) this transition
Because there was no desire to permanently fund a Design System team by leadership, the decision was made early to utilize an existing library. After prototyping with several, I settled on Chakra UI, a theme-able and accessible component library built in React (JS).
Eliminating the need to author (and maintain) each component allowed the team to remain lightweight and simplified long-term maintenance such that it only required an average of 3 hours work every 2 weeks to keep the library up to date.
Published as internal npm package
Engineering sensitive to changes in product monorepo
Product code existed entirely in a single monorepo. This meant that any iterative changes to the design system (and they were abundant and rapid, early on) would require touching, and publishing the product codebase.
To avoid this, we made the decision to utilize a private github package registry and eject the design system from the monorepo, opting instead to install the design system as a dependency within the product.
I love having the design system as a package dependency. I don’t even worry about it anymore.
This allowed the design system team to rapidly develop and cut releases without unintentionally affecting the product codebase. When a portion of the application was ready to upgrade or add the design system, the package was installed (or updated) to the latest, then released to consumers.
Operate as Design Manager
Immediate need for Design management
I stepped in as manager of Design, shortly after joining the company. The directors of Engineering and Product, respectively identified early they were not qualified to operate in that role and asked me to step in. Within weeks we established a working agreement and team structure based on democratic principles.
Secure headcount for 2 additional design roles
Immediate need for additional Design ICs
Within two months of taking on the role of Manager for the design staff, I expanded the team from one (1) to three (3) members, dividing responsibilities, based on input from my staff, between new product work, existing feature improvements, and design systems construction & maintenance.
I’ve never been on a team where I felt like I had a voice in decision making. I just wanted to say how much I appreciate that! 👍🏼
âś…Â results
- full system publish within 6 months
- contribution from all parts of the organization (including CEO)
- roughly double acceleration of engineering organization
this makes things so much faster. I spend maybe half the time I used to building a UI
Storybook
I spent a significant amount of my energy improving the documentation and visual presentation of Storybook stories. We learned early on that Developers instinctively went to Storybook for implementation documentation, and Designers went to Figma for their documentation.
While initially we invested in a Zeroheight documentation site bridging designer and developer documentation, inevitably we focused on Storybook and Figma instead, opting to “go to the user.”
Chromatic
Chromatic is a tool built by the developers of Storybook and integrates seamlessly to provide visual regression testing and UI feedback. We made heavy use of this tool to conduct visual reviews of in-development components as well as maintenance to ensure we were not introducing unintended changes before publishing the package.
Since this testing was always conducted on branches within Github, we were never concerned about publishing something before it was ready.
Playroom
When scaling the Design team, it was important to me to hire folks that were either interested in learning lightweight code, or already had some experience doing so.
Because of this, the design team was able to transition to a culture of rapid prototyping UI using component code in a designer-friendly sandbox, built on an open-source library called Playroom.
Changelog
During discovery, it became evident that Engineering valued clear and consistent change communication and was sensitive to this. As such I added a process and library to the Design System library called standard-version which is a riff on conventional commits. This coupled with a lightweight (and minimally enforced) commit linting process produced beautiful, predictable changelogs.
🧑‍🏫 lessons learned
- using an external component library requires a culture change in Design Discovery; instead of first asking oneself, “what do I imagine it to look like,” we must instead establish a habit of “what does the existing component look like in the library?”
- using GitHub permits easy access to world of tools and simplifies setup of these tools
- private GitHub package registries complicates things
- division between product design / management and design system needs to be clear
