Kora Financial/2023
Kora design system
Design driven project - Initiated and led the revamp of Kora app design system in 2 months, prompted and supported the storybook component library building of engineer team.
Impact
Aligned the component on design and dev side and established component based front-end QA flow. Each component has been applied in 10+ projects.
My Role
Solo UX Designer
Timeline
2023.7-9
Team size
1 UX Designer (ME)
1 UI Designer
1 Front-End Engineer
1 UI Designer
1 Front-End Engineer
Reponsibility
• Initiated & driven the project
• Set up system structure and crafted all the components
• Leading the QA process
• Set up system structure and crafted all the components
• Leading the QA process
Project Overview
Background
Kora is a financial service app that's only available on iOS
Kora app has several main features: financial activity insights, virtual card, cash advance and financial literacy feature, which were built intermittently.
Problems
Existing design system is outdated and unstructured
Pain point 1: Duplicated components
For example, we have 3 components designed for the same UI element & use case - account card which takes X3 time to design & implement.
Pain point 2: Low flexibility
Most of the components only have one property listing all the variants of a specific case, which makes it impossible to reuse in other context.
Pain point 3: No responsive considerations
All the components have no responsiveness specs and wrong constrains setting. The engineers have to guess the responsiveness behavior on their own.
Pain point 4: Chaotic file structure
All the components were randomly scattered in one page of the file, either by project or by UI element, with no naming conventions. It's hard to navigate in the file.
challenge
How might we establish a robust Figma design system that could streamline our design workflow, enhance collaboration, and ensure consistent user experiences?
Result
Structure & Hierarchy that follows atomic design
Default responsiveness & interaction setting
Flexible components structure
Phase 0: Get support
How to visualize possible impact?
A quick "MVP" with several new components to persuade the team
To provide a more straightforward understanding of how a new design system can highly increase the productivity for both design & development team as well as estimate the time investment, I redesigned several components as an example to show the possible impact.
Where to get support?
Discuss the possibility of revamp with collaborators and stakeholders
With the MVP, I talked to the stakeholders below and ask for their opinions and availability. Luckily, I brought this up at a good time and everyone agreed and had time to work on it.
Head of Product
On management level, is this something we want to devote time and effort on?
Engineer leads
Does the dev team have bandwidth and interest for this project?
Product managers
Based on project plan, do we have time in recent sprints for it?
How to roll things out with limited resources?
Design & implement the new components progressively along with each project
Even though most of the large companies would release the revamp all at once to keep consistency, neither of the teams can devote such time to the design system along with other on going project. After discussing with the dev team, we decided to design and implement new components gradually as a side product of each project.
Phase 1: Which components to build (first)?
What has been used frequently in the project?
Get started with the core component for interaction
After mid-fi, it would be clear to see what have been repetitively used and should be add as component no matter it's an icon, simple molecule or a complex pattern.
Break down the complex patterns
If the core component is complex, add the composing element
However, based on levels of atomic design, patterns should be composed by molecules. So for the patterns from last step, i'll make sure the included molecules to be build before the pattern itself.
What about the old stuff?
Only replace frequently used existing components
Due to limited time, we are only going to rebuild existing components that's extremely duplicated/inconsistent or very frequently used in the project, and keep using the existing ones for the rest.
Phase 2: How to build reusable components?
Principles
Make each component reusable and easy to use for everyone
After having a good idea of what components we should build, here comes the challenge to started crafting the components. Some high level goals that guided the process was:
👯
Consistency
Consistency
Ensure a uniform visual language across all our products.
⏱️
Efficiency
Efficiency
Make sure all the components are flexible to be reused across project.
📈
Scalability
Scalability
Create a system that could evolve and expand with our organization's growth.
🤝
Collaboration
Collaboration
Facilitate better communication and collaboration among team members.
STEP 1: refine styles
Tokenize foundational spacing & color based on tailwind library
To guarantee the consistency of styles and easier future adjustment, I've proposed to apply design token in our design system. After several discussions, the engineer team agreed to build design token on dev side and adapt the tailwind library.
To figure out how to adapt the library from design side, I reviewed the documentation and proposed some customization.
To figure out how to adapt the library from design side, I reviewed the documentation and proposed some customization.
Step 2: Create components and apply styles
Structure the component based on existing use case and checklist resources
By listing out the composing elements and variations of existing instances and referencing well established component libraries, I could aggregate the use case of the component and restructure them in the more flexible way.
I also made sure all the components adapt to different size & content length, if not, I'll add notes for the limitations.
I also made sure all the components adapt to different size & content length, if not, I'll add notes for the limitations.
Problem 1
How to balance flexibility & consistency?
For example, we didn't use any bottom sheet before and just started applying it. However, it can be used for confirmation, warning, selection, etc., and it's impossible to predict all the future cases and plan the structure accordingly.
To balance the possibility of various future usage and the need of a consistent structure for current implementation, I ended up with a template of bottom sheet only with the outer layer padding & interaction behavior, without specifying the actual content inside the bottom sheet.
Problem 2
How to avoid repeated interaction notes in project?
when we finally started applying new component in the projects, I noticed too many repeated interaction notes need to be added.
To avoid the clutter, I added the interaction notes to the design system documentation so the engineers can add global interactions even when they are building the component .
For example, for text field component, the basic focus in/out, error message showing, will be shared across instances.
To avoid the clutter, I added the interaction notes to the design system documentation so the engineers can add global interactions even when they are building the component .
For example, for text field component, the basic focus in/out, error message showing, will be shared across instances.
Step 4 : Documentation
Keep the design system accessible to all the potential "users"
After all the main pieces are put together, I put together the documentation that covers variant choices, usage guidelines, component behavior, and design principles. So that all the possible user of this library can make the right use of the component and the engineers can refer to this design system as the source of truth for future projects.
Phase 3: Implementation & iteration
QA & iteration
Keep feedback from both directions in one place
To make the QA process organized and keep everyone on the same page of the progress of each component, I set up a spreadsheet to tracks the owner & status for components on the first page, and all the detailed feedback from design or request from engineers on the next pages.
An ongoing evolution
Lessons Learned
Get what's best for the team and keep communicating
I'm so grateful to have a supportive team who collaborated with me and roll things out in such a great time. Some key takeaways are:
1. what works for the big techs might not be the best practices for us when the project size is small. Always evaluate the ROI and team bandwidth before suggesting anything.
2. Keep all the possible stakeholders and get them involved early in the stage to make sure the solution works for everyone and avoid getting back and forth.
1. what works for the big techs might not be the best practices for us when the project size is small. Always evaluate the ROI and team bandwidth before suggesting anything.
2. Keep all the possible stakeholders and get them involved early in the stage to make sure the solution works for everyone and avoid getting back and forth.