SecuritEase: Introducing product thinking to a 25-year-old financial infrastructure company
Role
Senior Product Designer
Duration
1 year
Context
25-year-old fintech platform, mid-transformation
Gallery
In progress
Product
Wealth management, clearing, settlement & post-trade software
Challenge
No user research. No product strategy. A feature factory.
Clients
Wealth managers, stockbrokers, investment banks
Design leadership
The head of product design prioritised novel interactions over usability or scalability. Interactions that couldn't be developed consistently were treated as wins.
Strategy
Two CTOs held the role simultaneously. A third of the company was devoted to "new technology" with no clear product direction for what it would enable.
Research
None. Features were scoped based on what industry experts believed clients needed, without speaking to the clients themselves.
Engineering
Developers received minimal direction and maximal blame. When products failed to land with clients, engineering absorbed the consequences. Most left and were replaced.
The environment
SecuritEase builds mission-critical financial infrastructure — clearing, settlement, wealth management, and post-trade services — for stockbrokers, investment banks, and wealth managers across multiple global markets. The technology was mature. The product culture was not.
When I joined, the product team operated as a feature factory driven almost entirely by a small group of "industry experts" — people with deep domain knowledge but no formal product management training, no research practice, and no interest in user validation. Their instincts substituted for evidence. Their opinions substituted for strategy.
The products were complicated, hard to sell, and impossible to scale — built for one industry expert's mental model and one client's operational structure. New clients weren't willing to restructure their entire business to fit the software.
What I set out to change
I identified two parallel problems that needed solving simultaneously: the research and strategy problem (we didn't know what clients actually needed), and the UI consistency problem (even when good ideas existed, the design system couldn't deliver them reliably at scale).
Neither could wait for the other. I ran both tracks in parallel.
Track 1 — Building a research culture from nothing
Partnering with sales and business development
User research had never been done. Rather than start with a formal research programme that the culture would have rejected, I embedded research into the conversations already happening. I partnered with the BD and sales teams — who were speaking to potential clients constantly — and built a lightweight framework to capture what those clients were actually trying to accomplish, not just what features they asked for. This made research feel like business intelligence, not a design formality.
Reframing the product from features to objectives
The industry experts weren't going anywhere — and they had genuine domain knowledge that was valuable. My goal wasn't to replace them; it was to change how they contributed. I spent significant time coaching them on product management principles: what a problem statement is, what a user need looks like versus a feature request, and most importantly — how to say "I don't know, let's find out" instead of defaulting to their own instincts. Getting that phrase into the room regularly was a genuine milestone.
Involving engineering in problem definition
Developers at SecuritEase were being handed solutions and asked to build them. Unsurprisingly, they felt no ownership of what they shipped, and left when things went wrong. I worked to pull engineering earlier into the process — sharing research findings, involving them in problem framing sessions, and giving them space to propose solutions rather than just receive them. The change in engagement was immediate and visible.
Track 2 — A design system that could actually be built
The existing UI was inconsistent across products, violated basic heuristic principles, and had been built around interaction patterns that couldn't be developed consistently at scale. Documentation was essentially non-existent.
Fluent as the foundation
Rather than build a design system from scratch — which would have taken too long and lacked credibility in an engineering-led culture — I chose to build on Microsoft's Fluent design system. Fluent had the benefit of being well-documented, developer-familiar, and proven in complex data-dense application contexts. It gave the system instant legitimacy with both engineering and leadership.
Documentation as a cultural shift
The absence of documentation wasn't laziness — it was a symptom of a culture where institutional knowledge lived in people's heads and was guarded, not shared. I introduced documentation as a first-class deliverable on every piece of design work: component specs, usage guidelines, rationale for decisions. Over time this changed what "done" meant for the design team.
Three-layer architecture: tokens → complex components → product modules
I structured the system as three layers: a token layer (colour, typography, spacing, elevation), a complex component library built on top of Fluent for SecuritEase-specific patterns, and product modules that assembled those components into the specific workflows each product required. This meant changes at the token level propagated automatically, and product teams could build consistently without understanding the full system.
What landed — and what didn't
✓ What shifted
The research framework was adopted by BD and sales teams and became part of new client conversations. Engineering engagement in problem definition increased noticeably. Several industry experts began framing problems rather than dictating features — a genuine cultural shift. The design system's token layer and component library shipped and were used across new product work.
↻ What remained stuck
The structural issues — unclear technology strategy, misaligned leadership incentives, a CEO who rewarded novelty over rigour — were above the waterline I could reach. The product system improvements were in progress when I left; full adoption required organisational changes that hadn't happened yet.
What I'd do differently
I'd identify my executive sponsor earlier and more deliberately. The changes I was driving required top-down permission as much as bottom-up momentum — and I underestimated how much energy I'd spend on the latter without enough of the former. In a company where the CEO's instincts set the culture, the most important design work sometimes isn't a component library. It's a thirty-minute conversation with the right person, framed the right way.