Our Journey to a Design Language System
When I started at RigUp four years ago, our journey toward a design language system had already begun. Like so many others, it started out with rebranded Bootstrap components.
As you may know first-hand, we encountered a number of issues with this: overrides to rebrand components led to long cascades and many important! declarations littering our SASS files. Bootstrap documentation was considered sufficient for our needs, so nobody ever documented the custom classes or custom functionality we’d added. All of this made it very difficult to find what you needed and led to multiple functional duplicates.
Around the time “pattern library” was the big buzzword, we decided to make a move in that direction. Our designers mocked up most of the basic components we used to make our website — colors, typography, buttons, cards, etc. — and we began working to match them for development purposes.
We started with a set of designs in Sketch, encompassing the elements we wanted to build for our pattern library. We then built out a set of styles and classes, which we named Rhino after our company sports mascot, that would allow us to match those elements quickly and easily as developers.
This worked to solve several of our problems with our Bootstrap-based components. For the first time we had matching design elements in Sketch and in our codebase, which helped us deliver new features more quickly and consistently. Class-based styles made it easier to move existing content from bootstrap to the new Rhino patterns. We also focused heavily on ensuring that we wrote documentation for all of the patterns and classes we had created so that it would be easy to find and use them.
However, new problems quickly arose.
Our initial take on documentation was hard-coded and static, so it quickly became outdated. We were able to mitigate some of this issue by making live docs, but functional components weren’t always updated to reflect changes. As we added new components, we weren’t always diligent about writing documentation to accompany them.
The limited scope of the assets we originally developed helped us to be flexible, but it failed to address more complex use-cases, leading to the delivery of designs that varied drastically across the same set of functionalities. Developers, sometimes unaware of existing components or reluctant to discuss different approaches when it came to new designs, implemented different components with similar or duplicate functionality.
We also tried to build a lot of magic into some of our complex components. This led to overly-opinionated components that were very inflexible and often difficult or impossible to implement for various unexpected use cases. As a result some components grew unsustainably complex, while others developed more and more duplicates. Our documentation quickly fell out of sync, making the situation even worse.
As we scaled the engineering team, new developers struggled to parse overly-complex and opinionated components to make them work for the purposes at hand. Components that had never been documented were impossible to find, resulting in even more duplicates, many of which were caught only in code review and wasted a lot of development time.
We began looking around to see how other companies were handling the situation. Salesforce had published Lightning several years earlier, and other design language systems from companies like AirBnB were getting a lot of praise. On the surface, however, it was difficult to tell how they were addressing these problems.
We still needed to find solutions for:
- Lack of consistency between design and development.
- Overly opinionated components making development difficult.
- Duplicate components with little clarity around which was the “correct” one to use.
We continued to look into the idea of a design language system, hoping to glean insights from how other companies were managing and mitigating these types of problems. We also wanted to ensure our application was more accessible moving forward, so we integrated tools to ensure that into our design language system.
Around this time, we also made the decision to switch to React. You can read more about this process here, but it provided a good launching point to start really building our design language system and making it a reality.
Our first step was to figure out conventions and best practices up front, and then build out a roadmap for how to design, build, and implement the new design components. In the meantime, however, our migration to React was moving ahead at full steam and we needed design components right away. We made the decision to implement our class-based “Rhino” pattern library through the styled-components plugin while we finished designing the new system.
In building our new system, we decided to separate presentation and functional aspects as often as was reasonable for complex components, to avoid the issues with opinionated components we’d had with Rhino. We also decided on a more cascading approach. While we’d begin with choosing first colors and typography, along with designing and building simple components, we’d establish and continue to follow a process for introducing more complex components moving forward. This gave our design language system a more sustainable platform on which to build than Rhino previously had.
We also decided to use Storybook to ensure our documentation was always up-to-date. We’d tie Storybook into Sketch in order to help maintain synchronicity between design and development.
While this was all coming together, we recognized a new problem that needed to be solved for; as our application and platform grew, we needed a design system that could be adopted by different codebases. We made the decision to follow Salesforce’s tokenization approach to design language system, by creating easily updatable JSON files that could be translated into the correct format for a variety of platforms.
We’re still in the process of building our design language system, and we’re gradually rolling out temporary Rhino components in react in the meantime. Everyone at RigUp is excited to turn this new page in the book of our design and development history!
