Building a new financial-services mobile ecosystem
Helping shape a new mobile platform across multiple financial-services businesses — aligning customer experience, product direction, technology constraints and launch readiness inside a complex regulated organisation.
- Organisation
- Sanlam
- Industry
- Financial services / fintech
- Scope
- Product strategy · Customer experience · Mobile · Launch readiness · Design leadership
- Environment
- Multi-business-unit · Regulated · Legacy systems · Partner ecosystem
01 — The context
One app. Many businesses underneath it.
Creating a single mobile experience across a diversified financial-services organisation is not primarily a screen-design problem. Different business units have different products, systems, data maturity, operating models and customer relationships.
Some products can integrate cleanly into a shared mobile ecosystem. Others still depend on legacy platforms or on data that is not yet available to the app. The challenge was to create a coherent customer experience while the underlying organisation was still fragmented.
02 — My role
Working between product, experience and organisational reality
My role ran across the programme: the end-to-end mobile experience, feature prioritisation, customer research, onboarding and authentication, product discovery, launch readiness, design-system alignment and cross-business-unit consistency.
This was a large programme with many contributors. My contribution was connecting those layers — holding the customer experience together while product, technology and business realities moved.
03 — The complexity
The difficult part was underneath the interface.
Multiple businesses
The app needs to represent products and services from different businesses while still feeling like one coherent experience.
Legacy systems
Some businesses do not yet expose the data or capabilities needed for full mobile integration.
Regulation and customer trust
Financial-services journeys introduce legal, compliance, disclosure, identity and customer-due-diligence requirements that directly affect experience design.
Organisational dependencies
Product, technology, design, content, marketing, legal, data and multiple business units all influence what can launch, and when.
04 — Prioritising the product
Not every valuable feature belongs in the same release
Part of my work was helping the programme separate what the platform needed to launch credibly from what could follow once the organisation and systems were ready.
05 — Private beta
Private beta turned assumptions into evidence.
Beta exposed friction in notifications, guidance, terms and conditions, identity and customer verification, and other legally sensitive steps.
The response was not to polish the interface. Each signal had to be diagnosed: what was a content problem, what was a journey problem, what was a legal requirement, what could be simplified, and what needed further testing.
06 — Incomplete data
A coherent experience, even when the data is incomplete
Some business units rely on legacy systems that cannot yet provide complete product data to the mobile app. That is a customer-experience problem before it is a technical one: the app has to communicate clearly without implying that a customer holds no other products with the organisation.
07 — Scaling across teams
A shared platform needs shared rules and shared context
Many feature teams building one ecosystem is a scaling problem before it is a design problem. Design-system alignment and tokenisation gave teams a common foundation so consistency did not depend on individual review.
The same held for people. The product depended on Sanlam teams, partner design and technology teams, product owners, business units, content, data, marketing, legal and compliance, and design leadership. My role was to hold context across those groups — surfacing inconsistencies, challenging gaps and protecting the coherence of the customer experience.
08 — Launch readiness
Shipping required more than finished screens
Launch readiness meant coordination across product experience, development, legal, marketing, content, app-store requirements, brand, analytics, customer support and business-unit readiness.
= a customer-ready launch
09 — Strategic decisions
The value was often in what we chose to clarify, challenge or sequence
Clarifying product language
Customer-facing terminology had to work across different financial products and business units. Decisions about terms such as credit, loans, transfers and beneficiaries carried implications beyond copy — terminology shapes customer understanding and product expectations.
Distinguishing launch needs from future vision
Some future capabilities could not be represented as though they already existed. Product communication had to balance ambition with what the organisation could genuinely support at launch.
Designing for trust
Legal language, guidance, identity journeys, data accuracy and product visibility were treated as trust problems as much as interface problems.
10 — What this work demonstrates
Complex platforms need product judgement, not just product design.
A unified customer experience can sit on top of a fragmented organisation — but only if the fragmentation is understood.
Launch readiness is an end-to-end product responsibility.
Good product strategy includes knowing what not to ship yet.
Customer trust depends as much on accuracy, clarity and organisational readiness as it does on usability.
Design the ecosystem, not just the journey.
Treat organisational constraints as product inputs, not background noise.
A strong launch is the result of many disciplines becoming ready at the same time.
Status
A platform still evolving
This is an active product programme. The platform continues to evolve as more capabilities, business units and customer needs are integrated into the ecosystem.
Because the work is ongoing, this case study focuses on strategy, decision-making and launch readiness rather than claiming final commercial outcomes that are not yet available.