I led a project to establish the Rexlab product team’s Design System, and it wasn’t the first time the team had tried to tackle such a challenge.
The rich text element allows you to create and format headings, paragraphs, blockquotes, images, and video all in one place instead of having to add and format them individually. Just double-click and easily create content.
A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!
Headings, paragraphs, blockquotes, figures, images, and figure captions can all be styled after a class is added to the rich text element using the "When inside of" nested selector system.
And here is a really important quote that I'll want to highlight.
• • •
Our user base was skyrocketing and our product suite was expanding. This growth meant an increase in our teams, which led to the number of components in both the design department and development department to snowball, resulting in a number of problems.
We needed to clearly define these problems, and produce a solution that would allow our teams to produce new features and products without creating redundancies and to limit the inconsistencies.
"Our goal was to make our product team's work more efficient, enjoyable and to have a more cohesive product suite."
• • •
• • •
Stage 1 consisted of a Component Library for our existing CRM. Before my time with the team, previous designers had attempted to create solutions that were too complex and failed either during creation, or when it came to implementing them with the team.
After 2 prior attempts over 2 years with 3 designers, Rexlabs was still optimistic about having a functioning Design System—they knew that the reward would be worth their while.
With this knowledge, I was able to create a solution within a short time-frame, that became paramout to our entire design team’s workflow.
First, I further defined the problem:
And then determined what outcomes we were looking for:
Aware of the problem and what a solution looked like, I determined our team required the following:
I then researched leading design systems, primarily those dealing with complex interfaces, i.e. Polaris, which helped me understand that each component library should be structured differently, depending on it’s complexity, features, users and functionality. I was also fortunate enough to visit both Badoo and NET-A-PORTER to have a personal walk-through of their design systems.
A crucial step to get right is the grouping and hierarchy of our component library. This meant it either was intuitive, or another friction point in our team's process.
I made sure the structure was as simple as possible, I then proposed it to our team, asked for feedback, made adjustments, tested it in practice with the team, and adjusted it again.
From this, I determined the grouping/hierarchy of the library into foundations, components, patterns and layouts.
Once the components were designed and named appropriately to suite the above structure, the Component Library came together quite quickly.
I shared the component library with the team within 3 weeks of starting the project.
The four libraries in total contained over 400 symbols, however it only made up about 50% of the live components our CRM uses, (it’s a beast). I shared it so early into the process because it was more important to get the library into the designers hands rather than giving them a complete library. I didn’t want to spend time completing and perfecting the components if the solution wasn’t suitable. The users (the designers) were also able to provide extremely valuable feedback, allowing me to make really important adjustments along the way. This quick feedback and adjustment loop was an important key into making this component library so successful.
"The discoverability of the components was important, which is why Runner Pro became such a valuable asset to our design system."
Not only did it save the designers time, it also allowed them to search for components as a way of finding out what was available in the library. This is why naming conventions were important to get right.
"Understanding the complete power of Sketch Symbols was invaluable when creating each component."
Leveraging the power of nested symbols, colours styles and text styles not only makes it faster for the designers when designing, it also allows the design system to set limitations for certain components, as well as making it much easier to update components across the entire system when a text or colour style changes.
In order to introduce the designers to the library, I presented the component library live to the entire product team with a casual presentation, pushing everyone to ask questions to start different dialogues.
"It was important for everyone to know that they could approach me and others familiar with the design system with any question, feedback or comment."
I invited the product team to a new Slack channel specifically for the component library #proj-comp-lib.
Within this channel, I shared tips on how to use the component library:
Took requests for additions to the component library, and shared updates to the team:
Any new processes that involved the component library were documented and shared with the team via the Slack channel, and kept in our team's Process Guide document.
Once the library matured and became more refined, I set it up in Abstract to allow the entire team to be able to contribute to it. This meant that the library wasn't reliant on one person, and was able to evolve much faster. I remained the 'librarian' — the go-to person if a designer needed some assistance in adding/adjusting the components. Each change also had to be reviewed and approved by 2 other designers, which was a quick yet important process that kept the library consistent across the team, as three designers were accountable for each change.
The designers were able to now use the Component Library, however, they had no context on how each component was to be used unless they asked around, or had a lot of experience with our product. To prevent incorrect usage of the components, and increase correct implementation within the development team, a library documenting the components was required.
After trialing GoogleDocs, GitBook, GoogleSites, and about 5 others, we finally went with ZeroHeight as the platform to document our design system. We loved how simple it was to use, as we didn't need much:
Here's a sneak preview of our result:
All of the components that enter the Luna Design System first go through a Research phase containing the following processes:
Until recently, there has been a lot of similar projects conducted, however the research and outcomes have been lost deep in the Google Doc sphere. New designers weren't about to know what research had been conducted, how we got to our current solution for many of our components and features, and what alternatives were explored along the way.
We needed to solve this problem, but how?
I looked at what an ideal solution would look like:
After exploring different resource library services in the previous Stage, ZeroHeight provided us with the best integrations ad a simple interface. It was also beneficial utilising the same platform across the Design System and Research Library to reduce learning time and keep consistency.
"The design system was created by a few people in order to establish a strong foundation and set up processes. However, it's now managed by the entire product team."
This is crucial to allow the design system to grow at the same pace as the products and the team. With some appropriate process in place, we were able to maintain a level of quality to the system.
• • •
Sketch, Runner Pro (Sketch Plugin), Paddy (Sketch Plugin), Google Docs (process documentation), ZeroHeight (document the design system)
Google Sheets for initial component auditing
Sketch for component library creation
Runner Pro Sketch plugin to assist with the Sketch component library
Abstract for sketch design file management and version control
Google Docs to document the initial design system
XeroHeight to document the final design system and research lab
Slack for team communications