Design system: enabling velocity and consistency for a lean product team
Industry
Fintech, Marketplace
Duration
3 months
Role
Design System, Documentation, Project Management
Team
1 Product Designer, 1 UX Developer
While working on our core product, we started to realize that our existing component library could no longer improve the team’s efficiency and ensure consistency. This prompted us to start over and create a robust design system that adhered to a more systematic framework and comprehensive documentation. The result was a remarkable transformation, greatly enhancing our product workflow, team efficiency, and overall product experience.
As we began incorporating new features and flows into our core product, we encountered several issues in our workflows:
Frequently, I found myself answering repetitive questions regarding component behaviors, spacing, and colors. Additionally, I spent a lot of time conducting design QA sessions. These redundant tasks diverted attention from higher-priority matters.
The absence of clear guidelines for each component and its variants led to inaccurate use of components and resulted in an inconsistent product experience.
Due to the lack of a well-structured knowledge sharing system, the component library remained primarily accessible to designers. Our engineers and product managers struggled to utilize this toolkit effectively, resulting in time-consuming over-communication efforts.
After carefully reflecting on the issues, we identified several opportunities to elevate our component library into a comprehensive design system that brings greater value to both the organization and the product.
From our existing component library, we learnt that without guidelines, it would become very difficult to ensure consistency when introducing new components. To standardize our design execution and ensure adherence to certain constraints and rules, we developed a 5-step framework. This framework enables us to effectively evolve our design system and transform design atoms into customer-facing views.
To align with the new brand identity, we revamped our color palette by incorporating the new brand colors. The shades of the primary brand blue are applied to fundamental elements like text, backgrounds, strokes, and cards. Meanwhile, the shades of the vibrant blue are reserved for actionable and decorative elements like buttons, icons, and illustrations.
Given that our platform is information-dense, ensuring legibility is crucial. Hence, we revisited our font choices, simplified our font hierarchy, optimized their size, leading, and tracking for improved legibility. Additionally, we introduced a shadow and spacing system to reinforce the information hierarchy and ensure a clear and organized display of information.
The base components form the foundation of user interaction and play a crucial role in delivering a smooth and consistent user experience. To create a seamless user journey, we categorized the base components into five core behaviors that align with a typical user's experience.
We put considerable effort into designing these components, ensuring their alignment with design atoms, and creating comprehensive variants that cover all potential scenarios and behaviors.
In Figma, we transformed these components into interactive elements, allowing them to serve as the bedrock of our high-fidelity prototypes. This approach ensures a solid and reliable foundation for our design process.
We've crafted specialized composite components that cater to our unique business needs and specific requirements. These components are assembled using our base components, resulting in a uniform and cohesive appearance, along with a well-defined information hierarchy.
Each composite component is assigned with business-related properties, enabling it to accurately reflect various component behaviors across different business scenarios. Whether it's user sign-in, investor suitability, IPO status, account status, or any other situation, these components adapt seamlessly to the specific context, ensuring a consistent and user-friendly experience.
One of the challenges we encountered was the inconsistent placement of banners and use of grid across views and breakpoints. We recognized that to build a real cross-platform product, it was necessary for us to articulate the layout grid we use. Therefore, we made the decision to refine and standardize our layout grid to ensure that it was implemented consistently throughout views and breakpoints.
Having established a new framework and revamped our components, it is vital to convert this into a shared resource and unified vocabulary accessible to all team members. To achieve this, we dedicated considerable effort to Storybook and documentation. Our design rules and methods are presented in a clear and easy-to-understand manner, facilitating seamless understanding and execution for all team members.
We believe that true familiarity of the components can only be achieved by interacting with them and seeing the code. Therefore, we worked closely with our development team and implemented a workflow around ↳Storybook . With Storybook, all our components were translated from interactive components in Figma into production-ready React components.
A critical aspect of this process is ensuring that the properties and variants of the components closely match between Figma and Storybook. By adopting a unified naming convention, controls, and property types, we empower our designers and engineers to view the components in perfect alignment. This commitment to consistency and efficiency enhances our design and development workflow significantly.
In our pursuit of creating a design system that truly facilitates collaboration, we recognized the importance of comprehensive documentation. To achieve this goal, we adopted a dual-level documentation approach.
Taking the Select component as an example. The component-level documentation clarifies how it stands apart from other user input components, while the variant-level documentation illustrates the significance of maintaining a neutral approach in certain scenarios and offering default options in others.
In addition to the dual-level documentation, we carefully organized and named our components for easy navigation and search. We also minimized potential friction in these process by converting some non-configurable components into local components.
We initially used a numeric naming convention for our color palette. As our team grew, we realized that it could be confusing for some members to remember the specific use case of each color. To address this, we planned to switch to a naming convention based on the use cases of each color. Unfortunately, this change was not implemented before LEX ceased operations.
However, I was able to implement this use-case-based naming convention in a different design system that I worked on later. You can read more about it here: ↳OpenAsk
Read more LEX case studies:
↳ LEX Product 2/3 - Core Product
Want to see all projects?
Check the ↳project index .
