How it started:
The Dashboard Pattern Library
My journey into design systems began in early 2016. I had not heard of the term “design system”, but in trying to improve collaboration with the growing engineering team, I created what I would later realise were the beginnings of one.
Recognising the problem
Previously, I had been involved in some amount of UI development, and was thus able to ensure that the UI was developed as designed. However, as the engineering team grew and I stepped away from development, I began to find that it was harder to ensure that what was developed was accurate to what was designed, and visual inconsistencies started to accumulate over time.
For example, buttons developed by one developer for one feature looked different from buttons developed by another developer for another feature. Although this could be addressed during QA, I realised that the problem could be avoided altogether if the code components and styling were standardised centrally and reused instead of being rebuilt each time, saving both time and effort.
It was around this time that the engineering team and management made the decision to rebuild part of the product from the ground up with newer technology. This part of the product was called the Dashboard, used by event organisers to set up and manage their events. The product rebuild presented the perfect opportunity to build a library at the same time, as it is much easier to ensure the adoption of new library components in a new product than to replace components in an existing product (more on that later).
Building the library
Rather than create a pattern library from scratch, I decided to use a UI framework to help with components that had more complex interactions (e.g. modals). So I did some research, and with the engineering team’s agreement, settled on using Bootstrap 4. Using a UI framework also meant that many useful utilities such as a grid system were available out of the box.
Over the next few weeks, I had a lot of fun building the library component by component based on my existing design mockups. The library comprised brand colours, typography, buttons, form inputs, lists, tables, modals, alerts, toast messages, tooltips, and icons. Technology-wise, the pattern library was built using SCSS via Compass on top of the Bootstrap 4 framework.
I was mainly inspired by MailChimp’s pattern library, which I had come across a while ago, and built the Dashboard Pattern Library with the same structure - component demos, the associated markup, and notes on when and how to use the component. While developed in a separate repository, the compiled stylesheets from the library were copied into the product’s codebase so that those style definitions could be used in the product.
The existence of this library did indeed increase the efficiency of UI development and QA, and the rebuilt Dashboard was released in mid-2016. We have been using this library to this day, and the gain to visual consistency, development efficiency and maintainability still holds.
The design libraries
In 2016, I was the only UI designer in the company, but towards the end of the year, we started growing the team and by early 2017, we had a team of 5 designers. Now that there were multiple designers, standardisation of styles needed to be done on the design side as well.
Starting simple - Adobe CC Libraries
We were using Adobe Illustrator for UI design, so I used CC Libraries to create a library of brand colours, typographic styles, and UI assets for the Dashboard, consistent with the coded Dashboard Pattern Library. The main drawback of this library was that due to the limitations of the software, library assets had to be detached from the source when used, which meant no on-the-fly library updates.
Moving to Sketch
About a year later, at the start of 2018, we moved to Sketch as our primary UI design tool, given its superior workflow and toolset for UI design and its preeminence as the tool of choice in the industry. This time, it was a team effort to create the necessary Sketch libraries. In the first week or two of the switch, we laid the groundwork by building the symbol libraries - I recreated the Dashboard component library, while 2 other designers created the icon library and a library for page layouts of another part of our product, known internally as the Web-app.
Which brings us to...
the Web-app Pattern Library
The Web-app is our internal terminology for the other half of the Pigeonhole Live product. It actually comprises 5 interfaces which are used during live events, known as the Audience Web App, Projector Panel, Admin Panel, Moderator Panel, and Kiosk.
Ever since I experienced the benefits of building the Dashboard Pattern Library, I had wanted to create a Web-app Pattern Library as well. In fact, not only was the implementation of the Web-app’s UI inconsistent, the designs themselves had slight variances which meant that custom components needed to be created each time.
However, without a corresponding Web-app product rebuild, this proved to be much more difficult. The most challenging part wasn’t consolidating component designs, redesigning them, coding them, or replacing the existing components in the product.
Rather, the greatest challenge was finding the priority to do any and all of these tasks over all of the other design and development to-dos.
Unlike the earlier case where everything needed to be rebuilt, this time the interface already existed and people were already able to use it. So while we knew that working on the library had long-term benefits for efficiency and product cohesiveness, in the short-term, every other task of building or improving on features seemed much more urgent. Therefore, the work on the library only made incremental progress at a very slow rate.
The first attempt
In 2017, on my suggestion of creating a Web-app pattern library, one of our designers tried the approach of building the library within the product codebase itself. This was in an effort to integrate the library components more closely with the product code so they could be used directly without any copy-and-pasting. However, because the library couldn’t be built that quickly, concurrent feature development meant that this development branch couldn’t keep up with the changes on the master branch, and this approach was eventually scrapped.
The second attempt
In 2018, I decided to start again with the library in a separate repository. While structured similarly to the Dashboard Pattern Library, the main difference was that it wasn’t built on top of any UI framework, as the Web-app itself didn’t use a UI framework.
Wanting to bring more people into the process, I coached two of my team members to contribute to the library. When we could find the time, we worked on some of the smaller components - buttons, tabs, and dropdowns. I took them through the steps of
- Compiling existing instances
- Reviewing and standardising the design
- Coding the library component
- Aligning with the engineers on implementation, and
- Overseeing the replacement of instances in the product.
This took us to the end of 2019 (yes, slow progress).
Improving library-product integration
Along the way, one of our developers, Hadi, stepped in to refactor the library codebases, so as to standardise the development workflow and tighten the integration between the pattern libraries and the product.
For example, he created scripts to check for version number increments and to copy the right files from the pattern library to the right directory in the product, so that the developers wouldn’t make mistakes when trying to do this step manually. He also removed outdated packages (Ruby and Compass), switching to Node.js, which was consistent with the product’s stack, and improved the directory structure.
New components and evolving roles
In 2020, a couple of features that the team designed prompted the need for a more complex selection dropdown menu that included custom icons and a built-in search function.
By this time, I knew that it was time to hand over the responsibility of coding the library components from the design team to the engineering team. Firstly, not all designers are well-versed in front-end development, and the new components that we wanted to build were more complex, requiring much more scripting. Secondly, it’s important for both teams to feel a shared sense of ownership of the design system, so that it will continue to be well used and maintained.
Therefore, Hadi, now Engineering lead, and I started involving the developers in the creation of the new components in the pattern libraries, ensuring that the designers and developers worked closely together to bring these components to production.
Recent developments and ongoing work
Moving to Figma
In December 2020, we switched from using Sketch to Figma, as Figma had become the more powerful design tool and using it would improve the team’s workflow and collaboration. Accordingly, I recreated the Dashboard component library in Figma, while other design team members created the colour library, text styles, and icon library. Thanks to Figma’s powerful auto-layout and component variant features, these component libraries are now much more robust and flexible than our previous Sketch libraries.
Storybook and the Audience Web App rebuild
By the end of 2020, our plan to gradually replace the Web-app’s components one-by-one had changed again. Over time, the engineering team found that the technology that the Web-app was built on was outdated and difficult to extend, so they proposed that it should be rebuilt using a new framework in order to support further product extensibility and stability.
With the go-ahead to rebuild the Web-app came the opportunity and obligation to re-assess its design as a whole. In terms of the Pattern Library, this meant full speed ahead for the component review and redesign, instead of the slow pace we had been adopting since 2018. In 2 months, I worked with 2 other designers in the team to deliver the updated designs (in Figma) for the main library components — typography, buttons, dropdowns, tabs, form inputs, modals, and toast messages. Once again, I oversaw the entire process, advising the designers on what they should look out for, what kind of specifications they would need to define, and standardising styles across the different components.
The engineering team is currently in the process of building these components in a new Web-app Pattern Library using Vue and Storybook, frameworks chosen for their benefit to collaboration and compatibility with the planned product rebuild.
Unfortunately, designing and developing for accessibility isn’t something that we’ve been familiar with from the start. However, we’ve been making it a point to learn more about accessibility standards and starting from 2020, all new library components have been built with accessibility in mind, in particular designing for focus states and developing for keyboard and Screen Reader navigability.
Some of my takeaways
It takes a village
When I first initiated the design system, I was the only one involved — we were a very small team and there was only so much that each person could do. But as the team grew, it was important to get more people involved — to ensure that more than one person knows how to contribute to and use the design system, and to develop a sense of ownership among the entire team, so that the system will continue to be used, improved on, and maintained in the long term.
A useful design system doesn’t exist in a vacuum
I’ve heard of instances when designers have designed a whole set of new components with great artistic inspiration, but with no further plan or buy-in from the developers on how to integrate it in the product. If you create a symbol library but no one uses it, or if you have coded components but they aren’t adopted in the product, has the design system actually served its purpose?
I’ve also come across people asking about the best way to build a design system; ultimately I believe the best way is one that enables the system to be used, which is largely dependent on how one's team works and the technology that the product uses. Therefore, it's important for us to collaborate with each other and with engineering when making decisions on how to build the design system, and to ensure that there is a plan for adoption. It's not just the design that is important, but the entire workflow and integration with other systems.
All artwork is property of PigeonLab Pte. Ltd.