Upgrading the quality of designer’s (my own) life by streamlining design process
Year
2022
Overview
As a product designer at CitizenLab, I undertook an initiative of creating a Figma UI library for designers, which was previously absent. The objective was to streamline and accelerate the design process, ensuring the maintenance of consistent and organized UI elements, while also enhancing support for the development process.
Client
CitizenLab is a community engagement platform used by local governments and organisations to engage their community members. The company offers engagement tools such as surveys, ideation, participatory budgeting, online workshops, and input analysis.
My role
I took the lead on conducting component audit, building the base for design system, creating a system for colors, icons, and all components. I worked with a senior designer and a front-end developer for typography system and breakpoints.
The Problem
The product I was working on was a pretty complex one. It involved a platform with a registration system and various toolkits, encompassing both citizen-facing pages and back-office for platform admins.
What made things even trickier was that many of the UI elements were implemented as one-off things over a span of 5+ years, resulting in a pile-up of inconsistent UI components.
Incomplete Toolkit
The developers had a Storybook library in place, but it only covered typography, colors, and buttons, and it wasn't kept up-to-date.
Lack of a single source of truth
Without a comprehensive Figma UI library at my disposal for easy drag-and-drop, recreating existing elements for hi-fi prototyping became a time-consuming task. Some design patterns existed somewhere in Figma, but they were scattered and not standardized. I resorted to using bits and pieces of screenshots for quick prototyping, but it became cumbersome to make changes to those static images.
Inconsistency woes
With UI library being absent and a massive product to navigate, it was nearly impossible to keep track of all the UI elements and their corresponding rules.
The Process
I took on a leading role in conducting a thorough audit of colors, icons, and components, to lay the foundation for a comprehensive component library in Figma. Then, I created a Figma Library file leveraging auto-layout and variants. Later on, a senior designer joined the company and contributed his front-end skills in refining the typography and establishing breakpoints. Together, we made significant progress in enhancing the design system.
Component audit: Identifying inconsistencies
I spent a few days gathering as many screenshots of UI components as possible. I went through each page, making sure to capture different states of the components. Then, I created a separate board to group the screenshots by component types. This helped me see how inconsistent the usage of each component was – we had four different types of tables, for instance.
This gave me a good sense of which components were used a lot and which ones had the potential to be turned into reusable components.
Colors
The company had a color system set up on Storybook, but it had several issues:
Too many similar colors: There were 28 shades of grey.
Non-scalable color names: The color names were specific to single, sometimes niche use cases, making it difficult to apply them to other scenarios and find the desired colors when designing. i.e. adminContentBackground and clDropdownHoverBackground.
Duplicate colors: Some colors were repeated, while others were too similar to distinguish easily.
Non-palette colors: Many colors being used in the product were not part of the color palette.
Here’s what I did:
Eliminated duplicate, overly similar colors, or colors that are not used. Reduced from 63 to 39, while adding colors that are being used on product to the palette
Implemented a new naming convention. Instead of using specific use case names, I opted for descriptive color variable names like grey800 and red700. This approach ensures that colors are not limited to a single purpose and are easily discoverable and scalable. However, I retained some semantic names like primaryText and divider as I found it handy.
Icons
The icons lacked a consistent style and had varying padding inconsistencies. Moreover, the naming conventions used for the icons were inconsistent.
To address these issues, here’s what I did:
Achieved consistency in style and padding by updating the icons using Google Material Design icons as a reference.
Implemented semantic icon names with clear guidelines to ensure a standardized approach.
Added a default icon size for seamless implementation and ease of use.
Breakpoints
In collaboration with the a front-end developer and a senior designer, we made decisions regarding breakpoints. We opted for a straightforward approach, using a 3-way naming convention inspired by t-shirt sizes: S (mobile), M (tablet), and L (desktop).
Typography
Under the guidance of the senior designer, we aimed to streamline the typography system. Initially, we restricted the weight options to two: regular and bold. However, later on, we recognized the need for an additional weight and incorporated semibold into the system.
Buttons, fields, and more
Once the foundation of the UI library was established, I went ahead and started linking typography styles, colors, and icons to existing components. This was to ensure changes at a later point to be easily applied to overall library. To enhance consistency and efficiency, the team consolidated and streamlined the listItem components across both Figma and Storybook platforms.
Page templates
Having frequently used pages in a readily available Figma file proved to be immensely beneficial. It allowed me to swiftly grab it whenever needed and make quick tweaks to showcase my ideas.
New Process: Maintaining and Updating the UI Library
The senior designer took the lead in establishing a new workflow to enhance and maintain the design system. This involved centralizing the Jira tickets related to the design system in a single location and assigning a dedicated developer to handle these tasks efficiently.
We were delighted to have the UI library file readily accessible. This milestone allowed us to fully focus on the heart of our work - crafting better solutions in our design tasks. The efficiency of our prototyping process soared, enabling us to quickly create high-fidelity prototypes with consistent component and styles.
On a side note - sometimes this caused small problems, where our colleagues mistook our exploratory prototypes for upcoming implementations, as things looked too shiny and finished.
Retro-spective
My initial ambition was to componentize everything in the product, mapping them to the right structure with variables. Looking back, this approach was not realistic or necessary, and as I worked I learned to let go of my perfectionist style and focused on systemizing what is truly useful.
I also wanted to document the rules for using each component to ensure consistency among designers. However, given our busy workdays, this task never became a priority. As a quick solution, I added some of the example patterns in the UI library that are implemented in the product, so that designers can quickly refer to it to learn the rules and make consistent designs.
That's it! Thanks.
© 2023 Made by Yaesul