Product Designer, 2+ years in fintech and 3+ years in business consulting. I make complex financial data feel trustworthy and simple to use.

Starting out

Reports are the first product Flanks ever built: dashboards that turn the financial data we aggregate from clients' custodians into something they can actually read and use. I joined Flanks as a junior, entry-level designer, and Reports was one of the first things I worked on, adapting the brand and visual design to what users needed, and building the design system as variables and tokens so the reports could adapt quickly rather than being rebuilt from scratch each time.

The scaling problem

Back then, every report was custom-built per client. That worked when we were small, but it didn't scale as the client base grew. Every new client meant another one-off design and build. I didn't have direct access to end clients, so I gathered their needs indirectly, interviewing our sales team as a proxy for what clients were asking for, and running repeated working sessions with PMs to define a path forward. That research stretched over months, running alongside my work on Flanks' other products rather than as a single, contained project. That's broadly how most projects at Flanks have unfolded.

Trying modularity, then standardizing

The first idea I tried was modularity: letting clients mix and match report blocks to build their own configuration. It made sense on paper, but it didn't land with users. There was too much choice and not enough clarity. So I pivoted to standardization instead: four fixed report types, each building on the scope of the last.

Impact

Standardizing meant these four reports could be generated automatically instead of custom-built, and they ended up becoming a pricing driver for the company, tied directly to how Flanks packages its offering commercially. Today, a growing number of clients are on one of the four standardized reports, and once a client finds the right one, churn on that report has been zero, a result I see as a benchmark to maintain for future clients as much as a win already achieved with current ones. That said, this is still a transition in progress. Because standardization is recent, we're still selling fully personalized reports in parallel.

Documentation for transparency

Standardizing the reports created a second problem: sales and support had no consistent way to explain how a given figure was calculated when a client asked. I built a platform documenting each report in detail: the components and widgets available within each type, and the underlying documentation and calculations behind every figure shown to clients. It's live today, and sales and support now point clients to a single source of truth. It's a direct extension of the standardization work: not just building consistent reports, but making sure the people explaining them to clients can do so with full transparency and confidence.

Where it stands now

I started this project working alongside my colleague in the UX/UI team, but as my workload across Flanks' other products grew, we split responsibilities. Since January, I've owned Reports on my own, staying the main design point of contact with engineering, PM, and sales. It hasn't been a clean, linear build: technical implementation issues repeatedly slowed the rollout, and the automation we have today only covers financial data. Non-financial wealth data, like real estate or other assets, still resists automation. That's the problem I'm working on next, alongside designing new dashboards for each non-financial asset type and expanding coverage to more markets.

From report to platform

The first version of the platform, which we called the Investor Platform, was built as a dynamic alternative to the physical Report: instead of a fixed, report-style snapshot, it gave users a live view of their aggregated wealth data that could be filtered by date and by investor. Like the early Reports product, it was a tailor-made solution built for one client at a time, which meant it couldn't be replicated for others and didn't scale. This has been one of the most collaborative projects I've worked on at Flanks: engineers, developers, PMs, and our in-house financial professionals were all directly involved in defining the final platform, alongside myself and the other designer on the team.

Finding the real need

Because the Investor Platform was built tailor-made per client, it faced the same scalability problem as the early Reports product, so we had to go back and identify what users' real needs actually were. We ran several rounds of interviews with financial advisors, and what came out of that research reframed the problem entirely: users didn't just want to view their data; even with the flexibility the Investor Platform offered, they needed to manage it, consolidating it across custodians, entities, and asset classes, and acting on it rather than just observing it. That shift, from viewing to managing, is what pushed the evolution from the Investor Platform into a full Portfolio Management Tool.

A costly pivot

After more than six months of work, we realized what we'd built, even with that dynamic filtering, still wasn't valuable enough for the people actually using it day to day: financial advisors managing wealth on behalf of family offices. An aggregated, filterable view of wealth data wasn't the same as a tool they could actually manage a client's finances with. That was a difficult outcome after half a year of work, but it reset the direction of the project and shaped how we approached the rebuild.

Building with Claude Code

That shift began in January, when the priority became shipping something genuinely valuable built for the AI era, rather than continuing to iterate slowly on the old model. Speed mattered: we needed to design, validate, and iterate as fast as possible. We started working in Claude Code and rebuilt the product into what is now Flanks' wealth management platform for family offices, the PMT. It gives financial advisors a single consolidated view of all their clients' wealth, across custodian banks, legal entities, asset classes, and currencies, along with performance analytics, private market tracking, and client-ready PDF reports. Working this way let us validate the design of many screens quickly inside the company, running usability tests and A/B tests at a pace that wouldn't have been realistic with a traditional design-to-development handoff.

Within the design team, the work was split by feature: I owned Report management and Balances, while my colleague in the UX/UI team led the rest. Research and analysis were done together, but once we moved into designing in Claude Code, we each wrote prompts for our own sections in parallel, building on a design system my colleague in the UX/UI team directed and that I helped develop further as we went.

Designing this way demanded a different kind of precision. Padding, sizing, typography, and color all had to be explicitly defined and confirmed screen by screen, since Claude Code needed those details spelled out rather than inferred the way a developer might infer them from a Figma file. That discipline paid off beyond this one project: because design led the process from the start, everything the team eventually built had already been designed and signed off on by us. Claude Code was only ever meant to get us to a validated version quickly, not to become the platform's final build. Once the design was validated that way, engineering brought development of the platform in-house, inheriting a design system and a working reference instead of a blank handoff.

Validating internally

All validation on the PMT so far has happened internally, drawing on the experience of Flanks' in-house financial professionals. We ran A/B tests and usability tests specifically to check whether the platform's more complex user flows, covering multiple custodians, entities, and asset classes at once, were actually understandable, not just complete. I personally ran three rounds of usability testing focused on portfolio management, the feature clients care about most, since it needed to feel simple and smooth despite the complexity behind it. That testing led to concrete changes: several screens were reworked to cut down the number of clicks and streamline the flow. Going forward, what I'm most focused on validating is whether users experience these complex processes as genuinely simple, and whether that simplicity is compelling enough that it could lead a family office to move their portfolio management over to Flanks' PMT.

Why this tool matters

The Reconciliation tool exists to give clients an accurate view of their own wealth. When an investment movement or account transaction isn't recorded correctly, or contains a discrepancy, the resulting picture of a client's wealth stops reflecting reality at that point in time. This tool lets the people managing that data, typically financial advisors or a client's backoffice team, correct those movements directly, so the reported wealth stays accurate.

The problem

Before this existed, Flanks had no tool to address it. Discrepancies in investment or account movements meant the wealth figures we showed clients didn't fully reflect reality, and reconciling them fell entirely on the client's backoffice team, working manually to adjust numbers until each report balanced. We identified this as a genuine problem through internal feedback: clients were explicitly requesting a way to fix it.

The work

The project started as a team effort. In discovery-phase interviews, the goal was to understand how advisors and backoffice teams were already handling reconciliation, whether through current workarounds or past experience, so the flows we designed reflected a real process rather than an assumption. We defined those flows and iterated on the screens through multiple rounds of feedback, refining each proposal until we reached a final version. Handoff sessions included both the backend and frontend development teams and the in-house financial specialists who'd helped define the tool, so the design was validated from both a technical and a domain-expert angle before it shipped.

We aimed to cover every reconciliation need we'd identified, but for the first release we had to prioritize: given the team's resources and what clients needed most urgently, we launched with a defined subset of functionality rather than the full scope. I carried the project through to completion, taking ownership of account movement reconciliation specifically, distinct from investment movement reconciliation, and ran that piece end to end myself, from discovery through ideation, definition, and the design of the final solution.

Where it stands now

The project ran from January to April, with the first version reaching production in May. Investment movement reconciliation launched first; account movement reconciliation, the piece I owned, followed last. It hasn't stopped at that first release: we're in constant iteration to add functionality clients have requested since launch, including a reconciliation audit trail.

The tool captures every movement tied to the portfolios a financial advisor manages, covering all accounts within a portfolio and enabling a complete aggregation of a client's wealth. Because it can be used by either backoffice staff or financial professionals, the view adapts to whichever type of user is working in it.

Every client using the tool has run into relatively few scenarios that required reconciliation, a sign that the underlying data has stayed clean. But every time reconciliation has been needed, it's been executed correctly and resolved without issue.