Momentum Financial Services Group · 2025–present
Director of Product Design
I turned fragmented brand and product standards into a shared experience foundation spanning Money Mart’s digital and assisted channels. I established the design language, accessibility standards, governance, documentation, and design-to-code model needed to make product quality more consistent and reusable across teams.
4 customer channels
6 system foundations
3-component coded pilot
One brand was being rebuilt differently across products
Money Mart operates across digital products, marketing experiences, assisted channels, vendors, and technology stacks. Over time, different teams had developed their own interpretations of the brand, interaction patterns, components, accessibility requirements, and implementation standards.
The cost was larger than visual inconsistency. Teams repeatedly solved established problems, engineers lacked dependable implementation references, accessibility depended too heavily on individual project knowledge, and product quality became harder to maintain as delivery scaled.
I reframed the design system from a library of UI assets into a shared experience capability.
My mandate
My responsibility was not to personally design every component. It was to establish the direction, ownership, standards, investment model, and cross-functional relationships needed for the system to become dependable organisational infrastructure.
Experience direction
Define what should remain consistent across Money Mart channels and where products need flexibility.
Product quality
Establish accessibility, interaction, content, component, and implementation standards.
Governance and adoption
Define who owns changes, how teams contribute, how decisions are documented, and how the system evolves.
Engineering investment
Build the case and operating model for reusable coded components rather than relying on each product team to implement established patterns independently.
I defined one experience system, not another design library
The organisation already had design assets. The larger problem was that visual components alone could not create a consistent Money Mart experience.
I defined the system around six connected foundations: brand, design language, reusable components and patterns, content and voice, accessibility, and governance. That allowed teams to understand not only what something should look like, but how it should behave, communicate, and be maintained.
The source of truth became an experience standard for decision-making, not simply a place to copy components from.
One Money Mart experience across channels.
I removed the handoff document from the centre of delivery
A reusable experience system has limited value if engineering receives it through fragmented specifications, tickets, chats, and one-off documentation.
I established Figma Dev Mode as the shared design-to-development workspace. Engineers work from approved “Ready for Dev” frames, inspect tokens and component states directly, keep implementation questions attached to the design, and validate the experience before code review.
I moved the system from design reference toward production infrastructure
The next constraint was structural. Product teams could share the same Figma component and still implement it differently in code.
I partnered with engineering leadership to define a design-to-code model connecting Figma, semantic tokens, ZeroHeight documentation, coded components, testing, and production implementation. Rather than committing immediately to tooling or headcount, I created a controlled pilot to test whether the model was viable.
Figma
Visual specification + properties + tokens
↓
ZeroHeight
Usage + behaviour + accessibility
↓
Reusable code
Technical behaviour + APIs + testing
↓
Product implementation
Website first, then evaluate broader channels
The pilot
We selected three common form components, text field, checkbox, and radio, to test whether documented design standards could move into reusable code without product-specific corrections. The pilot is deliberately small so we can measure the contract before scaling the library.
| Measure | Target |
|---|---|
| Components implemented | 3/3 |
| Documented states supported | 100% |
| Accessibility checks passed | 100% |
| Product-level CSS overrides | 0 |
| Hard-coded design values where tokens exist | 0 |
| Material visual defects at first QA | ≤3/component |
| Unresolved system ambiguities | 0 |
| Components reusable by a second engineer | 3/3 |
A shared system needs shared ownership
The experience system exposed an organisational issue rather than a design issue. Product Design could define standards and maintain design assets, but reusable production components required sustained engineering ownership.
I developed the investment case and cross-functional operating model for experience foundations, with Product Design accountable for the experience standard and Engineering accountable for implementation architecture, testing, releases, and technical maintenance.
| Product Design | Shared | Engineering |
|---|---|---|
| Experience standards | Roadmap | Component architecture |
| Design language | Priorities | APIs |
| Accessibility requirements | Governance | Automated testing |
| Component behaviour | Adoption | Versioning |
| Documentation | Quality | Releases |
| Contribution model | Measurement | Technical maintenance |
Shared roadmap. Distinct professional accountability.
The capability is already changing how teams work
One experience foundation
Money Mart now has a documented system connecting brand, product behaviour, accessibility, content, components, and governance rather than relying on scattered standards.
One design-to-development workflow
Engineering teams have been onboarded to work directly from Figma Dev Mode instead of depending on separate specification documents and fragmented conversations.
A shared design-to-code contract
Design and engineering are aligning semantic tokens, component states, accessibility expectations, implementation responsibilities, and reuse criteria before expanding coded components.
A funded decision path
The system now has an explicit engineering-capacity and ownership question supported by a pilot and measurement model rather than an informal request for “someone to build Storybook.”
What I am measuring next
The experience system is still being built. I do not want to claim efficiency or quality improvements that we have not measured.
The current pilot establishes the baseline needed to measure whether reusable coded foundations reduce implementation variation and repeated effort as adoption grows.
Reuse
Percentage of eligible interfaces consuming governed components.
Quality
Implementation defects, accessibility defects, and design-to-code discrepancies.
Efficiency
Engineering clarification cycles, one-off implementation effort, and design-related rework.
Adoption
Teams, products, and vendors consuming the governed system.
Maintenance
Product-specific overrides, duplicate components, and breaking changes.
4 channels
connected through one experience standard
3 components
in the first design-to-code pilot
Faster generation makes standards more important
AI-assisted design and development can produce interfaces and code faster. Without governed foundations, it can also reproduce inconsistency faster.
Part of the investment case for the Money Mart experience system is therefore to make approved tokens, components, accessibility requirements, and implementation standards consumable by both people and AI-assisted workflows.
What this work reinforced for me
A design system is an operating model.
Components only create leverage when ownership, governance, documentation, contribution, engineering maintenance, and adoption are defined.
Accessibility belongs in the contract.
If accessibility is not documented, implemented, tested, and maintained alongside the component, it remains dependent on individual knowledge.
Shared standards need distinct accountability.
Product Design should define the experience standard. Engineering should own how reusable production infrastructure is built and maintained.
Scale should be earned through evidence.
A small measurable pilot is more useful than committing an organisation to a large component programme before the implementation model has been validated.