Projects
VeriChannel
In mid 2019, together with the Global Head of UX, I started the move of VeriPark's Banking Channel from V7 to V8. The groundwork was collecting V7 feedback and building the roadmap, and the build began in early 2020. I built the design system on my own: a tokenised, modular foundation with local layers, so banks could adapt the product without breaking the core.
Role: Senior Product Designer (UX/UI). Built the design system on my own, guided the team in using it, and stayed on to design product flows.
Scope: Design System Architecture, Design Tokens, Multi-Brand Theming, Accessibility, Information Architecture, Onboarding, Money Transfers
Context: Retail Banking, Fintech
Team: Product design team of six plus Head of UX. Design system built solo.
Year: 2019 - 2025
Two audiences who never meet
VeriChannel is a retail banking platform that banks license and deploy under their own brand. The end user is an ordinary customer checking a balance or sending money. The buyer is a bank with its own regulator, its own brand and its own opinion about what a banking app should look like.
​
Those two audiences never meet, and every decision has to hold for both.
​
I worked in a product design team under a Global Head of UX, alongside four other Senior Product Designers. I built the design system on my own and guided the team in using it. I also designed onboarding, mobile money transfers, KYC and login.
How the work was sequenced
Workshops came first, several months of them, before anything was designed. They set the direction: simplify, and fix what was demonstrably broken. The product had been built as a copy of the internet banking menu resized for a phone, and that inheritance showed. Navigation was organised by action rather than product. The Accounts category alone held twenty four actions in one flat list. Opening an account took thirteen steps.
​
Then a concept: a single visual and structural direction, agreed before systematisation.
​
Then the system, built bottom up. I did not start from a component inventory. I started from the components the old flows used most, because those already carried the product's weight and were the ones the team needed first. The system grew from there through requests from the other designers as they hit gaps in their own flows.
​
Then the flows. I designed onboarding and money transfers while continuing to develop the system in parallel. The two informed each other: a flow would surface a missing state, the state would go into the system, and the system would hand it to the next designer who needed it.
​
The system's first users were my colleagues. It grew on demand rather than on a plan.
Eleven properties on a single input. None of them were planned. Each one was added when a designer on another flow hit something the component could not do yet.
Theme, currency and brand as separate axes
VeriPark sold the same platform to banks and credit unions with different brands, currencies, regulators and reading directions. The decision that shaped everything was treating variation as separate independent axes rather than as bundled themes.
​
Theme is one axis: Standard, Dark and Projection. Projection is not a brightness variant. It is a distinct colour mode that also carries its own text tokens for right-to-left reading, so an Arabic deployment is a mode switch, not a separate file.
​
Currency is the second. Two variables, currency-symbol and currency-code, across four modes: USD, GBP, TRY and EUR. Switching a deployment from euro to Turkish lira touches no component and no theme.
​
Brand is the third, handled through the local layer.
​
They combine. A Turkish bank running dark mode is a combination, not a fourth theme. Bundled themes would have multiplied the file with every new market instead of adding to it.
Two variables, four markets. Currency is a mode, not a value.
Two layers, four collections, 355 variables
The primitive layer holds 159 variables: Color Palette with 146, Numbers with 11, and Currency with 2 across 4 modes.
The Numbers collection is a 4-based scale running from x0 to x10.
​
The semantic layer holds 196 tokens. This is the layer components consume. Nothing in a component references a hex value or a raw number.
​
spacing-m resolves to x4, which resolves to 16. icon-blue resolves to Primary/Primary, which resolves to 316CE2. Radius runs on the same numeric spine as spacing, so geometry never drifts between the two.
​
Built natively in Figma variables.
What banks could change, and what they could not
A central Foundation Base Library feeds product libraries, with Local Design Systems layered on top per bank and market. The governance question is where the line sits.
​
Geometry and identity were open: border radius, input shape, colour and typography. A bank that wanted fully rounded fields got them. I built the modular structure so clients and designers had a genuine space to work in, because a system that refuses everything is a system teams route around.
​
Accessibility was closed, not a negotiation. The enforced floor was WCAG 2.1 AA at a 4.5:1 contrast baseline, with AAA as the working target across the system. When a brand request came near the floor, I raised it in terms the room could act on rather than as a standards objection.
​
Contrast was checked case by case with Stark, against live screens and against actual client presentation material rather than against the palette in isolation. An earlier Stark audit set the baseline the system was built to correct.
​
Open to the bank:
-
Border radius
-
Input shape
-
Brand colour
-
Typography
Closed to the bank:
-
WCAG 2.1 AA floor
-
4.5:1 contrast minimum
-
Non-colour error signals
-
Focus visibility
​
Let the client own how it looks. Do not let the client own whether it can be used.
Same component, two brands. Both pass the same contrast floor.
A state is not done until it works empty
An accessible library survives implementation only if the people implementing it know what they are preserving. I ran training for the development and QA teams on Figma and accessibility principles.
​
Every input ships with seven states: default, hint, focus, filled, error, inactive and skeleton. Each one has to hold whether the field is empty or filled, so the matrix is two rows deep rather than one.
​
Focus is a colour change plus a stroke weight increase from 1px to 2px, never colour alone. In the error state the stroke, the label, the message and the message icon all change together, so the state survives when colour does not. Loading is handled by skeletons across all components, with 300ms treated as the ceiling.
Skeleton not shown.
One system, two products
The system feeds VeriChannel and VeriTouch, the SaaS product on the CRM side. Multi-brand is one problem. Multi-brand across two products with different users, a bank customer on a phone and a bank employee at a desk, is a different one. Tokens had to survive both without forking.
Two versions, one system
The internal version moved with the product. When a new feature was built, product managers came to the system to check whether it needed a new component or token, so additions went through the system rather than around it.
​
The client-facing version was a stable release, so banks in delivery worked against something that did not shift under them.
Sixty two banks
Before touching navigation I benchmarked sixty two retail banking apps, looking for the point where menus stopped being usable. The finding pointed one direction: simplify, and keep sub-levels to a minimum.
​
I needed that evidence. The internal pressure ran the opposite way. The company's commercial position was that the product should contain everything a bank might conceivably want, so no deal was lost to a missing feature. The CEO's stance was consistent: more of everything. That is a defensible strategy and a hard design brief, and I did not win the argument outright. I trimmed where I could defend the trim, and sixty two apps saying the same thing is harder to wave away than one designer's preference.
​
The restructure moved navigation from action-first to product-first. The customer selects the account or card, and product-specific actions move to the detail page as a context menu. Progressive disclosure keeps the first level short. Quick actions on the home screen let the most common tasks start in one tap.
​
62 apps benchmarked · 24 actions in one category · 13 steps to open an account
Action-based
Product-based
Thirteen steps to six, and a flow that bends to the regulator
The original flow was thirteen steps. The redesign brought it to six.
​
The number underneath matters more. The actions inside those six steps range from sixteen to thirty two depending on deployment, because onboarding requirements are set by the regulator of the market the bank operates in. Some markets need all thirty two. Others accept sixteen.
​
So I was not designing one flow. I was designing a structure that holds two very different regulatory loads without the shape of the experience changing. Six steps stay six either way. What varies is the density inside them, not the path through them.
​
The second decision was soft onboarding. Rather than front-loading document collection, a customer starts with minimal input and completes verification through live chat with a bank agent. That removed most of the paperwork burden from the customer and the physical document handling from the bank, which connected the work to carbon reduction goals several client banks were reporting on.
The craft is in the input
A short flow with a high cost of error. Most of the work lives in a few components.
The amount field
I kept cents at full size rather than shrinking them typographically. The visual argument for shrinking is real, but it created implementation problems and the gain was cosmetic, so I dropped it. Component width was sized from the start for amounts running into millions and billions, because a field that breaks at scale breaks in exactly the accounts that matter most. Decimal separators apply automatically as the user types.
Keyboards matched to input type
Text opens the standard keyboard, amount opens numeric. Dropdowns do not open as dropdowns: they open as bottom sheets, thumb-reachable and large enough to select from without precision.
​
The common touch target standard is 44px. This system uses 68px because label and placeholder both sit inside the field, so it carries more than a touch target's worth of content. Icons follow a related rule: a 24px icon inside a 40px coloured background.
A review screen before execution
Sending money cannot be undone, so the flow ends on an execute screen showing the complete transaction before anything moves, with two actions: correct, which returns into the flow, and send, which commits.
Every spacing value in the component resolves to a token. 4, 12 and 16 are x1, x3 and x4 on the same numeric scale used across the system.
Building a component and then arguing against it
The system includes a captcha, and its state matrix is complete. User feedback on it ran unanimously in one direction: too annoying. Every round said the same thing.
​
So my position became using it as little as possible rather than improving it. It stayed in the system because some deployments require it, but it was kept out of flows wherever an alternative existed. Building a component well and arguing to limit its use are not contradictory.
​
Every round of feedback said the same thing. Too annoying.
Results
Internal delivery tracking showed a sixty five percent reduction in delivery time across fifteen or more enterprise banking projects, confirmed on the client side. The onboarding drop-off reduction of up to thirty percent was reported by the client.
​
Deployments include 15+ banks in the VeriPark's portfolio. Twelve visual concepts were produced, three available for live switching during client presentations and the rest presented as a catalogue.
What I would do differently
-
Dark mode existed but was not fully aliased when I left. A brand colour change propagates through Standard and Projection, but not through Dark.
-
Four neutral families is too many. A single ramp with per-mode aliases would have given the same result with far fewer names.
-
Governance lived in conversations and reviews, not in a written customisation policy. That works while the person holding the model is in the room.
-
Delivery speed was the only system-level number I had, and it came from team reports, not instrumentation. I have no adoption data, so I could not tell which components went unused or how often teams built outside the system.