Momentum Financial Services Group · 2025–2026
Director of product design
I moved product design from fragmented requests and late-stage review toward a shared operating model with clearer intake, ownership, customer evidence, decision rights, handoff standards, and product-quality controls.
The goal was to make design easier to work with, less dependent on individual relationships, and better connected to product, engineering, operations, compliance, and business priorities.
9
workflow states
6
partner functions
7+
experience surfaces
Design work was happening, but the system around it was fragmented
The design team supported a growing financial-services ecosystem across digital, assisted, and operational channels. The problem was not a lack of work. It was a lack of shared structure around how that work entered the team, how priorities were set, where decisions were recorded, when partners needed to participate, and how quality was protected through implementation.
Requests arrived through direct messages, email, meetings, Figma comments, and individual relationships. Feedback and approvals could live somewhere different from the original request. Designers worked across different product areas with limited shared visibility. Engineering did not always have a consistent definition of development-ready design.
As the organisation and product portfolio grew, that model would increasingly depend on coordination rather than clear ownership.
My mandate
My responsibility was to create the conditions for a small product design team to support a complex product organisation without every request, decision, quality question, or escalation depending on me personally.
Operating structure
Define how work enters, gets prioritised, moves through design, receives decisions, and reaches implementation.
Decision clarity
Clarify where product design has authority, where partners contribute, and when business, technical, regulatory, or operational decisions sit elsewhere.
Quality
Introduce review, handoff, development-readiness, accessibility, and design-QA standards.
Team capability
Create enough structure, context, coaching, and ownership for designers to operate with increasing independence.
I created one operating layer for design work
The first problem I addressed was visibility.
I established a shared product design workflow in Asana so requests, status, ownership, dependencies, decisions, feedback, and approvals could be traced in one place. New work entered through a structured intake rather than depending on someone knowing which designer to contact.
Backlog → Triage → Ready to start → In progress → Design review → Stakeholder review → Building handoff → Done
*Blocked sits outside the normal flow when a dependency stops progress.
Asana
Task context, status, blockers, ownership, decisions and approvals.
Figma
Design-specific feedback attached to the actual interface.
Intake form
Official starting point for new work.
People no longer needed to know the design team’s internal relationships to understand where work stood or what needed to happen next.
I stopped treating design quality as something checked at the end
Better intake alone would not solve implementation quality. I introduced clearer review and handoff expectations so product quality had checkpoints before work reached customers.
Product designers began reviewing work with each other through recurring critique. Stakeholder review became a distinct decision point rather than an informal collection of comments. Engineering teams were onboarded to work from approved Figma frames, inspect components and states directly, and keep implementation questions connected to the source.
Design QA then created a final product-quality check before release rather than assuming that functional QA alone meant the experience was ready.
| Control | Purpose |
|---|---|
| Design critique | Improve judgement before stakeholder commitment |
| Stakeholder review | Capture the decision and material cross-functional input |
| Ready for Dev | Define when engineering should begin implementation |
| Figma Dev Mode | Give engineering direct access to design specifications and states |
| Design QA | Catch experience discrepancies before production |
I made customer evidence part of the operating model
I did not want design maturity to mean better internal process while teams continued making product decisions from assumptions.
We began building recurring ways to observe the experience beyond project-specific usability tests, including branch shadowing, frontline employee research, structured product research, and a repeatable FSR satisfaction programme.
The aim was to connect recurring evidence to prioritisation rather than let research disappear into individual project files.
Quarterly branch shadowing
Recurring observation of real staff and customer behaviour.
Biannual FSR satisfaction
A repeatable baseline for measuring employee experience with tools, communication and operational support.
I separated design authority from cross-functional authority
As product design became involved in more complex and regulated work, “everyone contributes” was no longer a sufficient governance model.
I defined decision boundaries so teams could distinguish a design recommendation from a business decision, technical decision, regulatory approval, operational constraint, or brand decision.
The principle was simple: one role owns the design recommendation. Other functions contribute expertise and retain authority over the decisions they are accountable for.
| Decision type | Accountable function |
|---|---|
| Product experience and interaction quality | Product design |
| Product strategy, scope and commercial priorities | Product |
| Technical architecture and implementation | Engineering |
| Regulatory interpretation and approval | Compliance / Legal |
| Operational policies and constraints | Operations |
| Foundational brand strategy | Marketing |
Design decisions should happen as close to the work as possible. I step in when there is unclear ownership, material customer risk, accessibility risk, compliance risk, a significant business trade-off, or unresolved cross-functional disagreement.
The model had to work without me becoming the bottleneck
Early in the transformation, a significant amount of intake, prioritisation, review, coordination, and standards work flowed through me. That helped create structure quickly, but it was not the model I wanted to scale.
I began shifting ownership toward designers responsible for customer and operational problems rather than simply assigning work by platform familiarity. I also defined clearer role charters, decision rights, shared foundations, and specialist capability needs so more decisions could happen inside the team.
The next operating-model evolution
Director of product design
Experience foundations
- Principal product designer
- Dedicated
Design system engineering partner
Content and communication
- Content designer / UX writer
Product experience
- Senior product designer,
Lending & servicing
- Product designer,
Omnichannel experience
- Product designer,
Assisted & operational experiences
- Product designer,
Growth & acquisition
From: “Who knows this platform?”
To: “Who owns this customer or business problem?”
What changed
Design work became visible.
Partners gained a shared place to understand requests, status, ownership, decisions, blockers and approvals.
Design gained a defined lifecycle.
Intake, internal review, stakeholder decisions, handoff and quality checks became explicit parts of delivery.
Design and engineering gained clearer working agreements.
Development readiness, source-of-truth expectations, in-file collaboration and design QA reduced ambiguity around implementation.
Customer evidence became more systematic.
Branch observation and frontline feedback developed into recurring evidence sources rather than isolated research exercises.
Decision ownership became clearer.
Design, product, engineering, marketing, compliance/legal and operations gained clearer boundaries for recommendations, approvals and escalation.
The team model became less platform-centred.
The direction shifted toward ownership of customer and business problems, supported by shared foundations and clearer capability roles.
What I learned
A process is not an operating model.
The model only became useful when intake, ownership, evidence, decisions, quality and escalation worked together.
Visibility reduces coordination cost.
Teams should not need private conversations to understand where work stands or what decision is required.
Research needs cadence.
Customer and frontline evidence has greater organisational value when it continuously informs priorities rather than appearing only inside individual projects.
Governance should distribute judgement.
The objective is not to bring more decisions to the Director. It is to give people enough context and authority to make the right decisions themselves.
The organisation needs to evolve with its product scope.
The model that works for a small generalist design team will eventually constrain a larger, more specialised product organisation.