Why’d we create a design system?
Back in 2017, when I just started at CU Direct, we had a ton of inconsistencies across our product line. There were different buttons, different inputs, different layouts of the same element, and different interactions for the same flows. We wasted a lot of time debating design details, just because there were no solid rules for our product. These inconsistencies also brought bad experiences to our users: they caused confusion and made it harder to understand and learn the system.
Because of the variety in code library on the dev side, it was hard to find the “correct code”. Sometimes developers just wrote new codes instead of reusing the old ones, which led to even more inconsistency. It was a vicious circle, and with our team growing over time, communication and product delivery got harder.
Getting to know and understand our products
My first step was to fully understand our products. Working with the Product team, we reviewed every aspect of our product suite and tried to list all important elements on paper (or whiteboard in this case), then group these elements by their usage. For example, style groups could be basic assets such as colors and fonts, and components group includes buttons, cards, tables, dialogs, and etc.
I adhered to the well-known Atomic Design methodology coined by Brad Frost because it helped to compartmentalize all these elements into logical groups. By standardizing our smallest elements like colors and fonts (the atoms), it helped to lay a concrete foundation for our more complex components.
Starting with tooling
As designers, we know the importance of maintaining consistency as we build out UI. Not only to keep consistency, but also as an efficient way to build up product design with accuracy and speed. Once I had the list of elements from our exercise I began the process of standardizing them as UI. This all began originally in Sketch, but we switched over to Figma mid-2018 since their features worked better at fitting our design needs. No matter what design editor you have an allegiance to, generating design work to components (or symbols as Sketch calls them) early on was not only very helpful, but crucial in maintaining reliable and uniform usage throughout future projects like our Enterprise Consumer Portal.
I started with our basic and key elements, like colors and fonts. These pages were grouped by typographic style by usages, like primary headings, secondary headings, labels, card titles, body contents, and buttons. Once we had colors and fonts, I went on to create more complex components such as buttons, cards, and dialogs. By creating components at the start as basic “atoms” and graduating them along they way to more sophisticated UI, I found 2 significant benefits as a result:
- This provided a way to validate smaller atoms and molecules as the UI scaled in complexity, and
- This became highly efficient in practice as I started to combine simpler components to build complicated components, such as index pages and settings pages
Making sure these components were pixel-perfect in each state was insanely tedious, but it only needed to be done once. There was no need to create different sizes or variations of these components, as resizing and renaming could be done easily after proper setup. This was a huge relief as any designer can attest to.
Documenting design usage, rules and patterns
The title is poking fun at the monotonous nature of writing documentation, but it’s oh-so important. It’s the dry part of design, but it’s also what makes for an effective design system. This is where we sum up the rules and principles that could apply to different cases in our products.
Initially we used cooperative platforms to document decisions as an open space to write about these principles and rules. Confluence was our initial starting point, and encouraged other team members to contribute to it and get feedback. For all our components, I utilized the knowledge of how each component would be used, and how to best describe how our developers could leverage it. Because design and documentation happened in tandem, it was critical to ensure the library was always up to date with the latest decisions that have been made. This is the beautiful aspect of a design system; an evolving system that can help all team members work under a consistent design framework. The work of a design system is never done.
Baseline is born
Collaborating with my lead front-end dev made this a reality. Having a live library created an environment that was mutually beneficial to both designers and devs. Developers can now find exact components by class names and deliver high-quality outcomes efficiently. They can copy and paste highly consistent code snippets from the library, which is useful for avoiding UI bugs, miscommunication, and duplicate work. Meanwhile, designers have a place where they can see how their work is displayed in various browsers. They now also have the ability to quickly make changes to visual atoms through the use of design tokens.
Other thoughts
Making the case
Making the case to bring about a design system at CU Direct was the right decision, but it wasn’t an easy undertaking. The organizational benefits of building products faster, enabling teams to understand shared components and processes, and creating a consistent user experiences still faced organizational barriers. After building the initial concept of the design assets we would standardize fact-gathering all the benefits, I arranged a meeting with all stakeholders in the company. Needless to say, I was on the big stage but I had the audience and platform to give my presentation and outline the benefits this would bring to our teams:
- Breakdown our siloes and reduce duplicate work
- Highlight how our customers notice fragmentation
- Involvement of allies and emphasize design system co-ownership
This is the presentation I presented to our executives and stakeholders: Google Slides.
ADA compliance
Another huge benefit for CU Direct was a way to leverage reusable components that abided by WCAG guidelines. In years past, the product team had been dinged by auditors that penalized our sites for failing basic web accessibility features. Adding new or existing components into Baseline would now have to comply with the standards set by the W3C’s guidelines. This meant we could start to build in confidence and that our front-end work would meet these benchmarks without the fear of being audited in the future.
Baseline 1.0 gallery
(right-click “Open Link in New Tab” to view the larger image)
