Design Systems Lead
Oasis
Design System
One shared design language, carried from semantic tokens into everyday banking experiences.
Oasis v2.1: button emphasis, interaction states, master variants, toggle buttons and surfaces from the original design file.
Product comparison: a repeatable hierarchy for card benefits, eligibility, and next actions.
Project overview
The work
behind the work.
National Retail Bank's product teams were building on a fragmented component library — duplicated patterns, drifting styles, and no shared source of truth across web and mobile.
I led its evolution into Oasis: a versioned, living design system of 2,000+ components governed by semantic tokens, with documentation and contribution rules that let it scale with the organisation.
Decision in focus
Change the emphasis. Keep the state vocabulary.
The original Oasis v2.1 board sets out text, outlined and contained buttons. Compare two of those variants: each carries the same six labelled states, with and without an icon.
Outlined: a boundary around the action
Enabled, hovered, focused, pressed, dragged and disabled states run left to right. Focus changes the boundary and background; the icon row repeats the same vocabulary.
Outlined variants · unchanged detail from the original Buttons board.
Contained: more visual weight
The filled variant gives the action a stronger surface. Its focused state adds an outer boundary; the disabled state withdraws the blue fill instead of appearing ready to act.
Contained variants · the same state sequence with a filled treatment.
Separate emphasis from state
Text, outline and fill establish different visual weights. Within each treatment, the repeated state names keep the specification legible as a system rather than a collection of isolated buttons.
Make focus a designed state
Focus is drawn alongside hover and press, not left out of the board. The visible boundaries give implementation a reference; keyboard behavior and contrast still need to be tested in the product.
Account for the variant cost
Three treatments, six states and two icon configurations make 36 examples in this matrix. That breadth makes review possible, but also creates a consistency and maintenance obligation.
These details come from the Buttons board in the original Oasis v2.1 design file. They document component specifications—not a browser interaction test, an accessibility certification or a measured adoption outcome.
A closer look
Design in detail.
Explore the full layouts and the relationships between their parts. Select an image to inspect it at a larger scale.
Product comparison: a repeatable hierarchy for card benefits, eligibility, and next actions.
Location discovery: applying the same system to a different customer task.
The full personal banking page, showing the system working across a content-rich surface.
Reflection
The constraint.
The response.
The constraint
Components were copied between files and teams, so a single change never propagated. Accessibility and brand consistency depended on individual diligence, and design-to-development handoff was slow and error-prone.
My response
I built a token-driven architecture — primitives feeding a semantic layer feeding components — and paired it with versioning, documentation, and contribution guidelines. The original button board below makes the component-state work visible; the product pages show shared patterns applied to different tasks.