Building a Reusable Component Library

This was going to be a potentially disruptive project. So getting buy-in from key stakeholders was essential. Applying pressure from the top down was one approach, but convincing product owners to be actively involved was going to be far better. Partnering with a senior PM, I began by asking product owners for a technical representative from each product to be involved in the project. We explained that the project was grassroots and that their involvement early on would be the least disruptive and the path most likely to succeed. We requested that each representative be allocated real time to work on the project, just like any other, and not to expect this work to be done on top of their existing workload. With a little trepidation, we successfully pulled together the required representatives.

Step one was to take an audit of user interface elements across each product. This information was collected in a simple shared spreadsheet, which later formed the required component list that lived in Jira, our tool for managing projects across the Org. The audit asked questions like;

With this information, we knew what we needed to ultimately produce, and so the question became where do you begin? We had a mixture of technology to consider. Some applications were built using Angular 1.0, some with the latest version of React... some had no framework at all. We decided that we had to design and build for the future and not battle retrofitting older apps immediately. As older applications underwent modernization they too could consume the reusable component library.

Starting from zero is always daunting and a lot of times a bad idea. The team made a decision early on to consider beginning with OSS (open-source software). Together with the engineers involved, we evaluated open source solutions. The obvious wins being time saved on components that every UI requires, buttons, inputs, dropdowns etc, already being built. Performance, as many OSS projects already had lots of contributors and a level of maturity we couldn't instantly attain, with regression and performance tests already written. The advantages of building a completely custom library would be flexibility and code ownership, but these seemed like weak advantages.
‍
Ultimately we settled on Semantic UI. Semantic has a clean and modern aesthetic to build upon. It supports theming which was an important consideration for our suite of products, and it had good component coverage relative to our requirements.

The Design Team knew that if our developers adopted a reusable component library they would need to design using the same components. At the time, and maybe still the case for many, design software that allows users to create interfaces using the component code directly was in its infancy and not really production-ready. The organization was using Sketch as its main design tool of choice and switching to something experimental like Figma or Framer X would have been too risky.
With the help of a senior designer on my team, we set about creating a comprehensive series of Sketch Libraries that would mirror the components available to our developers. The libraries and components needed to be version controlled, organized, accessible.

As we had already adopted Abstract as our version control system for Sketch assets internally, it made sense that we utilize this software for our component library.

Beginning with a series of Base Components that had fundamental attributes such as corner rounding and elevation depth (shadows) we built out as many of the Semantic UI components as required based on our earlier product audits.
For each category of component we created an accompanying stylesheet that acted as a reference that a designer could use when looking for a components usage guidelines or differing states.

Designers could directly copy and paste the component they required from these sheets or they could insert them directly through the inclusion of the shared component libraries in Sketch and Abstract.

We also took advantage of a feature in Abstract known as Collections. Collections allowed our team to provide live web accessible views of the stylesheets they directly worked from to the developers. This meant a 1:1 reference was available to the developer to check and make sure that the component they included in code, matched the look and intentions of the design team. If a discrepancy appeared the developer would use the living stylesheet at the source of truth and update the component code to match. (after a quick chat with a designer of course).

To provide my designers with confidence that the code being shipped to production reflected the component aesthetic and functionality intended by the team, I implemented Storybook on top of the node library the developers worked on. This gave the design team a window into the component library without needing any sort of local development environment setup.
Finally, I advocated for visual change detection to run on every ship to production where the app utilized the reusable component library. This would take snapshots in a headless browser of each component in the library and check for visual changes against the previous ship. If a change was detected in a component, it would require a member of the product or design team to sign off accept the change and continue the ship. We caught far more unintentional changes that intentional ones!

New interfaces could now be designed and built with confidence. Designers no longer spent time creating buttons and dropdown menus from scratch or worse, copy and pasting from outdated mockups, while developers simply included components from the available library.