# UX document
# Pattern library
Contribution:
• Review old UI style guide, removing outdated and revising incorrect information
• Structure content for the design system
• Consult established design systems for additional guidance to fill gaps
• Conduct team activities and workshops for team buy-in
Consulted with:
• Front-end developers
• Project manager
• QA
This project is made to showcase my workflow in constructing design systems, featuring a selection of visual examples. The design system presented here is not associated with any of my past commercial projects.
Go to this step
Understand
• Problems
• Goal
• Design system principles
Go to this step
Build
• Design system content categories
• Visual examples
Go to this step
Educate
• Design workshop
• Team activity of using the design system
As an in-house designer, I spent on average 1.5 hours everyday answering questions from developers about UI tickets. It got me thinking if there's a way to improve the efficiency.
Problems:
• Our old UI style guide wasn’t up-to-date so the team had a hard time determining its accuracy
• Undefined areas such as shape, responsive grid, icon style caused UI inconsistency throughout the product
Goal:
The team — designers, front-end developers, QA can have a up-to-date design guideline to refer to when working on interface-related tasks
A screenshot of the old notification components
A screenshot of team activity about what the design system should have
After having the whole team and the management onboard with the idea that we need a design system. Before we dive into building one, I invited the whole team to contribute to what they think the design system should have or what problems they expect the design system to solve. Then I summarized those insights into 4 principles.
Principles:
• Accessibility
• Scalability
• Consistency
• Adaptability
After setting down on the principles, I referred to multiple mature design systems (IBM Carbon, Google Materials, Microsoft Fluent) to get inspirations about what should be included in our design system and how to categorize those.
Three pillars:
I eventually decided to categorize the content into three types. Internally, we call them three pillars.
• Building blocks
• UI Patterns
• Foundation
Three pillars and its individual content
Accessibility
Writing content
Gesture
After the design system is organized, I hosted a design workshop to educate the team (developers, QA, product manager) about the design system.
Topics of the session :
• Where is the design system located in Figma?
• What does the design system include?
• The naming convention of the components and how to search for specific ones?
• Open the door for improvements and suggestions on the design system
* Note: this session is mainly for educating cross-functional teams about the design system, so it didn't include topics about how designers should use the system
A screenshot of the design workshop meeting
A screenshot of the team activity when team members drag components from the library
This is a fun team activity. I hosted this event to get the whole team onboard with the benefits of using a design system.
Tasks:
The team is asked to redesign our product by using the building blocks and UI patterns available in Figma. Every team member can choose a page they feel like designing for (such as Login, onboarding, user profile). Then we vote for the best designed pages. The winner gets a Amazon gift card.
Results:
The team can easily find the UI patterns and building blogs they intend to use. Some of the team members can explain what design principles are followed in their design.
83%
of the polishing tickets was achieved within half year.
2 hours
of communication between design and development on UI tasks are saved every week.
Maintenance is key
Building a design system is continuous work. As the product expands, the content needs to be updated, added or removed. Designers should allocate time on a regular basis to maintain the system. Only by doing this, the design system can be used effectively.
Cater to the team needs
As developers got involved more and more, I made changes to better adapt to their needs. For example, I created a button components library apart from the design guideline sheet so that the team can find things easily. Also, listening to the suggestions from the team, I’m adding more examples and pictures to better communicate the rules.
By referring to mature design systems and getting input from developers, we have decided to create design tokens ready for development use. We have researched on the commonly used platforms (such as Storybook) to move the design system to.
