Cuelin is a recipe app with an edge: beyond searching and saving recipes, it lets users detect raw ingredients through the camera and suggest what dishes can be made from them.
Role
UI/UX Designer
Year
2025
Industry
Fintech
Design partner
Malvin Firdaus
Method
Atomic Design
Clients
BTN · Bank Mandiri · Bank Victoria · Bank Jatim · CIMB Niaga
Deliverables
Tokens, components, guidelines & documentation
Scope
Web & mobile banking products
COLOR TOKENS
TYPE SCALE
Aa
Heading
Body text
COMPONENTS, THEMED PER BRAND
Chapter 01
Before Sephora Design System, our design files were difficult to maintain and reuse. We needed a more structured component workflow for designers and developers working across multiple banking projects.
Separate working files become one structured arrangement: the same pieces, now organised for reuse.
A more structured way to build and adapt layouts using Auto Layout.
Components needed better organization, variants, and configurable properties.
Make supported use cases reusable without repeatedly detaching component instances.
Chapter 02
Two directions were considered before committing to a shared system.
Create separate design systems for each brand, which would allow for unique styling per product but introduced a high maintenance burden, as any update would need to be made across each system.
We needed a system that would streamline workflows across products with different brand identities while remaining simple enough for developers to implement.
Chapter 03
A two-person team collaborated on component design, layout decisions, research based on existing designs, and component testing. The team leader also reviewed components as part of the process.
Study previous interfaces to understand recurring elements, actual use cases, and where standardization makes sense.
Use Auto Layout, Variants, Boolean Properties, Nested Components, and Variables to support the intended component workflow.
Check component behavior against requirements, refine where needed, and request a team-lead review.
Chapter 04
The design system was organized into five areas to provide a common reference for designers and developers.
Base design principles and elements.
Reusable design values.
Reusable interface elements.
Established interface patterns.
Guidance for future use.
The diagram represents the reported structure, not a screenshot of the original Figma file.
We use atomic design for structuring the design system.
Chapter 05
Although the projects shared a common design system foundation, each bank required its own project file because the visual styles differed.
We maintained an established design system file and created one clone for each bank. Project-specific adjustments were made in the relevant clone.
At the time, combining all project-specific work directly into a single design system file could introduce conflicts. Cost constraints also limited our ability to use a centralized synchronization workflow.
To coordinate updates, designers were required to report changes to layouts and other relevant design elements.
When an update was reported, we could review and make the necessary adjustments to the established design system and the relevant project clone.
This made communication between designers an important part of maintaining alignment across files.
The workflow involved a trade-off: separate clones accommodated differing bank styles, while update coordination required additional attention from the team.
Chapter 06
The same system was applied across multiple banking projects, with each brand expressed through its own tokens.
The component structure stays shared. Its colour and radius tokens change at the brand layer.
Brand ABlue primary · compact radius
Auto-cycles while this chapter is in viewMaintained centrally, the system gives every project a shared starting point while each brand remains free to look like itself.
Chapter 07
Building Sephora Design System required us to consider both the design of individual components and the workflow surrounding their reuse.
Cards and tables demonstrated why component design needs to account for real use cases. A reusable component needs an appropriate structure, but it must also accommodate the requirements of the interface in which it is used.
Managing separate project clones also highlighted the importance of communication and update coordination. While a shared foundation supported reuse across projects, maintaining alignment required designers to report changes and the team to adjust relevant files.
A future improvement would be to establish a more formal update and version-management process and introduce measurable indicators for evaluating component reuse, screen production time, and the frequency of component detachment.
The key lesson was that an effective design system is not simply a collection of reusable UI elements. It also depends on how components are structured, adapted, reviewed, and maintained across real projects.
I reply fastest by email.