I'm a Senior Digital Product Designer based in Utrecht, with 7+ years primarily in B2B SaaS and some experience in e-commerce. My focus areas are design systems, interaction design, usability testing and accessibility considerations. I'm increasingly using AI to optimise design and product workflows.
Led product and design on the first full UI modernization of Mambu's core banking engine, migrating a legacy GWT front end to React and MUI under a 100% feature-parity, zero-workflow-change mandate.
Built three custom Claude Code workflows to extract requirements from a legacy codebase, draft and post Jira stories, and automate accessibility and usability audits, built to keep pace with AI-assisted delivery across the Mambu redesign.
Rethinking permissions, actions and feedback in tables
Designed a reusable table pattern that gives compliance officers clear, contextual feedforward on what they can and can't do before they act, closing 5 client tickets at Fenergo.
Led UX research across analytics, session recordings, heuristics and sales-agent interviews to find why applicants were dropping out of a document upload & signing flow, then redesigned it end to end.
Assessed what discontinuing a regulated lending product would mean for Santander's loan funnel, then ran two sequenced A/B tests reshaping the homepage around personal loans, landing a €7.5M annual boost in requested loan amounts.
Leading the end-to-end redesign of Mambu's core banking engine UI, from requirements gathering through engineering handoff and active development support.
Runs moderated usability testing with internal and external users at every stage of the redesign
Builds and maintains a new design system with Claude Code, including Storybook docs and an npm package for company-wide adoption
Embeds WCAG 2.2 AA guidelines directly into component docs, giving engineers and AI agents clear accessibility guardrails
Drives cross-environment design strategy and a scalable design process across the organization
Apr 2023 – Apr 2025
Senior Product Designer, Fenergo
Led the end-to-end integration of the Sentinels Transaction Monitoring product into Fenergo's KYC/CLM platform, from discovery through delivery.
Owned the full design process behind merging two products into one platform
Kickstarted a scalable design system initiative with engineering, fully documented in Storybook
Dec 2021 – Apr 2023
Product Designer, Sentinels
Improved the UX of the Sentinels platform, used by Anti-Financial Crime and Compliance teams to detect, monitor and report financial crime.
Lead designer across two agile squads building Sanctions Screening and Anti-Money Laundering workflows
Ran extensive usability testing to validate decisions for high-stakes compliance workflows
Contributed to a new UI component library, documented in Figma for consistent implementation
Improved the UX of the company's website and digital environments across the Netherlands and Belgium.
Implemented A/B tests to drive conversion rate improvements
Coded new UI elements in HTML & CSS to support rapid iteration
Embedded user-centred thinking into cross-functional processes, lifting UX maturity org-wide
Foundations
UX Strategist, MediaMonks & early research
Started in research and strategy: as a UX Strategist at MediaMonks, and earlier as a research assistant at Utrecht University. It's the range that shapes how I approach new problems today.
Ran interviews, competitive research, usability testing and heuristic analysis for clients including Shell, Senseo and Heineken
Coded and analysed behavioural data for a psychology research project as a research assistant at Utrecht University
Rebuilding fifteen years of legacy without breaking a single workflow
Leading product and design on the first full UI modernization of Mambu's core banking engine, migrating a legacy GWT front end to React and MUI under a strict no-workflow-change, no-backend-change, 100%-parity mandate.
Company
Mambu (Core Banking SaaS)
Period
Aug 2025 – Present
Role
Senior UX Designer, Product & Design Lead
Impact
−56% usability issues
Context
A wide variety of research activities.
Mambu's core banking engine platform ran on GWT, a front-end technology that predates most of the team currently building on top of it. The UI hadn't had a structural revamp in fifteen years, and by the time this project started it was carrying real usability, security, and performance debt. By then, 200+ customers were relying on the interface daily, likely representing far more individual users than that figure alone suggests, generating 1M+ daily interactions on the platform, according to Grafana.
Leadership sponsored a full front-end modernization, and I led it end to end from a product and design perspective, the first person dedicated to owning that scope across the platform. The mandate was deliberately narrow: fix the front end, don't touch what it does. That left four hard constraints:
Scope boundary: every screen rebuilt without changing what it did or how users worked, for the thousands of financial institutions already running on Mambu.
Legacy stack: React sitting in front of a backend never designed for a modern front end.
100% feature parity: roughly 100 feature toggles and their permission logic, carried over unchanged.
100% data parity: every customer's data, on every plan, had to migrate without loss.
Research
Reverse-engineering a product with no spec.
01Codebase requirement mining
Reading the GWT source directly to recover intent no one had written down
02Demo environment testing
Working through live flows to see actual behavior, not assumed behavior
03Customer focus groups
15+ calls surfacing pain points directly from daily use
04Usability testing
30+ sessions with internal and external users validating new patterns
05Engineering & PM validation
Checking every recovered requirement against the people who built it
Approach
Building on a foundation, not just a palette.
Chose MUI as the foundation, together with engineering and product, for its component richness, flexibility, and accessibility scaffolding already built into the primitives.
Built the Mambu theme on top of MUI, running explicit colour-contrast and type-scale accessibility checks rather than trusting the defaults to be correct out of the box.
Chose component variants collaboratively with engineering, weighing what looked and felt right against what the legacy backend could realistically support without new APIs.
Designed directly against the live demo environment, translating recovered requirements into new patterns with as little added scope as the parity mandate allowed.
Mapped every legacy pattern to exactly one new equivalent, so 100% feature and data parity held without re-solving the same problem screen by screen.
Before / After Example
Fifteen years apart, side by side.
One of the patterns this redesign replaced: a menu with dozens of unlabeled items and no way to search it, rebuilt as a searchable, ownership-aware view picker.
A note about the before/after examples
Mambu's production interface is proprietary, so the real screens can't be published here. What's embedded below is a faithful recreation built with Claude Code — same interaction pattern, same information architecture, placeholder data standing in for real customer records.
Results & Impact
Measured against the legacy UI, screen by screen.
Two independent comparisons, a WCAG 2.2 AA accessibility audit and a Nielsen Norman 10-heuristics usability review, were run against matched pages in both UIs to track the migration objectively rather than by feel.
+25 pts
average WCAG 2.2 AA score gained across audited pages (34 → 59 / 100), with projected scores above 80 once the identified quick wins ship.
−56%
usability issues found in a Nielsen Norman heuristics review (61 → 27), with zero catastrophic issues remaining, down from two.
100%
feature and data parity held across roughly 100 feature toggles and their full permission logic, with zero workflow changes for any customer.
+288%
increase in positive usability findings recorded on the same pages (8 → 31), evidence the rebuild fixed root causes, not just symptoms.
Reflection
The hardest project I've led, and an honest look at its ceiling.
I've never worked on a project this constrained: every decision had to satisfy design, a fifteen-year-old backend, and a parity mandate that left almost no room to simplify.
What made it tractable was treating the audits as a compass rather than a scorecard: the accessibility and usability numbers above show a foundational rebuild, not a finished one, and the issues remaining in the new UI are refinement-level (missing ARIA labels, thin contrast margins), not the structural failures the legacy screens were full of.
One heuristic actually regressed during the rebuild: contextual help, present in GWT, was dropped from part of the new UI. It's a useful reminder that a front-end-only project can only rebuild what the backend and the old screens already modeled: it can't invent affordances that were never there to begin with. That gap is now a tracked follow-up, not an afterthought.
Case Study 02
How I used AI in my product design workflow
How three custom Claude Code workflows let me extract requirements, draft Jira stories, and audit accessibility and usability across the Mambu redesign.
One design lead, a hundred feature toggles, and a faster way from Figma to Jira.
The Mambu UI modernization (covered in full in the companion case study) had no existing product spec for most of the app, roughly 100 feature toggles, and permission logic layered deep enough that it lived only inside the code itself. Working at the speed of AI meant the usual design-to-spec handoff was too slow to keep up, so I picked up a good part of the product-owner-style work myself: mining requirements, writing the stories, and pushing them from Figma to Jira faster than that handoff would normally allow.
Approach
Three systems, built to close the gap.
Skill 01
Redesign-to-Jira: from codebase to backlog-ready story
I built a Claude Code skill that takes a section of the app as input and extracts everything that governs it: permission rules, feature toggle behavior, functional goals, and anything else a manual pass through the demo environment would likely miss.
From there, the workflow runs as a loop, not a handoff: I design against that extracted context, adding as little of my own interpretation as possible. The designs go back to Claude, which drafts a Jira story and holds a conversation with me to close any gaps, especially requirements I couldn't answer myself from the codebase alone. Once I approve the story, Claude posts it to Jira and messages the team on Slack that it's ready to pick up, or ready for refinement if open questions remain.
A second skill takes an app section and drives a Chrome extension through both the legacy GWT screen and its React rebuild, checking each against WCAG 2.2 AA. The output is a full comparison report: scores, severity-ranked issues, and a set of suggested remediation stories.
I review the suggestions, and approved ones get posted straight to the accessibility backlog in Jira. The reports this skill produces are the same ones behind the Results & Impact numbers in the redesign case study. A similar skill runs the same comparison for usability, scoring both UIs against the Nielsen Norman heuristics.
A design system built to be read by AI, not just engineers
I build all of the following with Claude Code. The Mambu Design System repository is the technical foundation that connects Mambu's design language with production code. It brings together design tokens, themes, reusable UI components, Storybook documentation, and development tooling into a shared source of truth for Mambu's products.
The system starts with the design tokens defined in Figma, representing Mambu's visual language: colors, typography, spacing, and other visual properties. These tokens are translated into Mambu themes and reusable components built on top of MUI. This allows product teams to build consistent interfaces without recreating common UI patterns from scratch.
The repository also provides a component library and CLI, allowing engineers to discover and add Mambu components directly to their product repositories. Storybook provides an interactive way to explore and document the components, while automated testing helps validate the system as it evolves.
Accessibility is built into the component foundation, with WCAG 2.2 principles considered from the start and automated accessibility testing integrated into Storybook and CI using Axe/Core. This helps catch accessibility issues early and prevent regressions as components evolve.
A particularly important part of the repository is DESIGN.md. It provides a structured, machine-readable description of Mambu's visual identity, combining design tokens with human-readable guidance. This creates a foundation for AI coding agents to understand and follow Mambu's design rules, rather than generating UI based only on generic patterns.
Who it helps
Designers get a stronger connection between Figma and the coded design system, helping ensure that design decisions can be translated consistently into production.
Engineers get reusable components, themes, tokens, documentation and tooling, reducing duplicated UI work and making implementation more consistent and accessible.
AI coding agents get structured design rules and existing components that can guide them when generating or modifying interfaces.
Product Managers and product teams benefit from a shared UI language and reusable patterns, making it easier to build new experiences consistently and avoid reinventing existing solutions.
Overall, the repository is more than a component library. It acts as a bridge between design, engineering, product and AI, creating a shared foundation for how Mambu interfaces are designed, built, tested, and evolved.
The design-system repo: component library, DESIGN.md, and CI governance
Results & Impact
What the workflow actually shipped.
20+ Jira stories
Generated through the skill, each grounded in requirements pulled directly from the codebase.
90%+ stories
Shipped first pass, with only 2 of those 20+ coming back with open questions before engineering could start.
1 in 4 stories
Needed no new Figma work at all, since existing designs or the component library already covered the pattern.
Reflection
Why the accessibility bugs happened, and why that's the point.
The honest question is: if accessibility guardrails were built into the stories and the component library, why did the audit skill keep finding new issues after screens were already shipped? Because Claude-assisted development doesn't always follow its own guardrails. Requirements baked into a story or the design system's documented patterns were sometimes missed or subtly hallucinated during implementation.
Rather than treat that as a reason to trust the workflow less, I built the audit skill specifically to catch it: a compensating control that assumes AI-assisted development will occasionally drift, and checks for it systematically instead of hoping it doesn't happen. The issues it finds get fixed as bugs, the same way any other regression would be.
Case Study 04
Reducing dropouts for Santander's loan portal
How extensive UX research turned a leaking document-upload flow into approximately €600K in additional monthly revenue from booked loans, and cut the manual work behind it.
Company
Santander Consumer Finance Benelux
Period
Aug – Nov 2021
Role
UX Research & Product Design
Impact
+€600K monthly revenue
Context
A portal built to remove friction was creating its own.
Santander Consumer Finance Benelux had already launched a Personal Loan request portal for document uploads and e-signing: a self-serve flow meant to make applying for a loan faster for the customer, and cheaper to operate for the business.
But conversion was underperforming. In lending, that isn't just a UX metric: every applicant who drops out mid-flow is a loan that doesn't get booked, interest income that doesn't materialize, and, if the friction is bad enough, trust in the brand that erodes. Significant resources had already gone into building and promoting the portal, so I was brought in to find out, from a UX perspective, exactly where and why people were leaving.
Constraints
What shaped the solution space.
Sunk Cost
The portal was already live and promoted, so this had to be a redesign of a shipped product, not a clean-slate rebuild, which meant every fix needed to justify its engineering cost against a working (if leaky) baseline.
Regulated Content
Loan and signing instructions couldn't just be rewritten for clarity. They needed sign-off from legal and communications teams too, since this is regulated financial content (including explaining documents like the SECCI).
Two User Types, One Flow
Joint applications meant designing for both a main applicant and a partner inside the same portal, without either one able to tell, at a glance, which documents were theirs to upload.
Brand Alignment
The existing UI hadn't kept pace with Santander Consumer Finance's updated brand, so any redesign also had to bring the portal back in line visually, not just functionally.
Research
Triangulated five sources.
Rather than guess at what was broken, I pulled evidence from wherever the portal left a trace: quantitative, qualitative, and from the people fielding the fallout every day.
01Usability heuristics audit
Against the 10 principles of UI design
02Google Analytics
To find exactly which steps bled the most users
03Hotjar session recordings
400 recordings reviewed over 3 months
04Sales agent interviews
3 agents who talk to applicants every day
05Wireframe prototype test
Early solution tested with 2 users
A breakdown of insights
Hotjar recordings showed applicants repeatedly confusing which uploads belonged to them versus their partner. Sales agents confirmed it from the phone-support side: both applicants landed on the same page, with upload elements mixed together and no way to tell them apart.
Google Analytics showed heavy back-and-forth navigation inside the upload modals, with a 30% drop-off between step 1 (instructions) and step 2 (the actual upload) in the Dutch ID dialog alone.
Original mobile modal: Dutch ID upload, steps 1 & 2
Sales agents reported frequent upload errors and repeat calls asking for clarification, tracing back to overly complex portal instructions. Several applicants didn't understand what the SECCI document was for at all, which risked reading as suspicious rather than routine. Joint-account signing differences added another layer of confusion.
Recordings showed users repeatedly tapping example document images expecting some kind of response. Those images were also too small to read on mobile. The heuristic audit confirmed why: no progress indication anywhere in the flow, no immediate feedback on whether an upload had succeeded or failed, and no help text on accepted file types or sizes.
Visual and interaction design lacked consistency, the colour palette didn't match Santander Consumer Finance's current brand, and UI elements had no defined states, so people couldn't always tell what was clickable, loading, or done.
Design Solutions
Six changes, each tied directly back to a finding.
Ask up front: main applicant, or partner? People can switch views at any time, so each person only ever sees their own documents.
Rewrite signing and document instructions for clarity, developed jointly with legal and communications so accuracy wasn't traded for simplicity.
Add an FAQ section to absorb the most common questions before they became phone calls.
Consolidate every upload dialog onto a single page with a clear visual hierarchy, plus a zoom feature so example document images are actually legible.
Add a progress indicator, with microcopy and contextual feedback guiding people through each step instead of leaving them guessing.
Bring the portal in line with Santander Consumer Finance's current branding, closing the gap between the product and the brand it represents.
Mapping the new user flow
Final Designs
The redesigned flow, screen by screen.
Scroll to see the full flow →
Results & Impact
Measured four months after launch.
Operations agents tracked the monthly volume of incorrectly uploaded documents; working with the marketing team's analyst, we tied the redesign directly to conversion.
8.9%↓ in incorrectly uploaded documents
A steady drop that meant operations agents had far fewer files to check by hand.
3.5%↑ in conversion rate
Measured on the loan request flow, over the same four-month window as the drop in incorrect uploads.
~€600K↑ in additional monthly revenue
The monthly impact of that conversion lift, from booked Personal Loans.
Reflection
Why triangulation mattered here.
No single source in this project would have been enough on its own: analytics showed where people dropped off but not why, Hotjar recordings showed confusion but not how often it led to abandonment, and sales agents had the pattern-recognition from hundreds of calls but no visibility into the data.
It was only by holding all five sources against each other that the real, fixable causes, not just symptoms, came into focus.
Case Study 03
Rethinking permissions, actions and feedback in tables
How a new table pattern gave compliance officers clear, contextual guidance on what they could and couldn't do, before they acted rather than after, across a platform used to detect and report financial crime.
Company
Fenergo (FinTech)
Period
Feb – Jun 2024
Role
Product Design & UX Research
Impact
5 client tickets closed
Context
A permissions system nobody could see, until it blocked them.
The Fenergo Transaction Monitoring app (formerly Sentinels) helps compliance teams at payment service providers, banks, and other financial institutions detect, monitor, and report financial crime such as money laundering and terrorism financing. Given the sensitive nature of the data and the critical responsibilities of its users, mistakes and inefficiency can have serious consequences: undetected financial crime, inaccurate reporting, or the company facing fines after an audit.
To manage that pressure and complexity, the product includes a strong permissions system controlling which actions different types of users can take and which information they can access. This project focused specifically on a new table pattern I designed to help users understand what actions they can or cannot perform within a table, and why, before they take that action.
Research
Understanding a permission system nobody could see.
To get to the bottom of it, I ran three research activities:
01Desk research
Competitor apps, plus the pros and cons of disabled vs. hidden interface states
02Assumption validation
Talked to SMEs, Customer Success, and worked through the JIRA backlog
03Usability testing
Final concept tested with 8 users, then refined on their feedback
What the research uncovered
Four overlapping permissions, invisible in the interface
Anti-Money Laundering Officers can only investigate the first 2 stages of an alert.
Compliance Officers can strictly investigate the last stage of the alert, when financial crime is much more possible.
An Anti-Money Laundering Officer cannot investigate both of the first 2 stages of an alert because there is a standard maker-checker policy.
Anti-Money Laundering Officers and Compliance Officers cannot work on an alert if another team member is working on that alert at the moment.
Buttons disabled, hid, or failed silently until you tried
Before the new solution was implemented, users received no clear feedback explaining why certain actions were unavailable based on their current selection of table items. The interface relied on either disabling buttons or having buttons appear and disappear dynamically (see prototype below). In some cases (such as permission #4), feedback was only provided after the user attempted an action, via a toast.
This icon appears & disappears depending on the selection1
Design Solutions
Feedforward before the click, feedback after it.
Never hide or disable an action button. People select first and learn why an item is excluded second, instead of guessing beforehand which buttons even apply to them.
Add a dedicated warning column: a new, narrow column in the table surfaces an icon next to any selected item the action won't affect.
Explain on hover, with a tooltip on each warning icon stating plainly why that specific item is non-actionable.
Confirm before it happens: a popover summarizes exactly what will and won't happen if the user goes ahead, before they commit.
Preserve context after confirming. The table keeps the non-actionable items selected, then shows success and error toasts so the outcome is unambiguous.
Mapping happy and unhappy paths · click to zoom
Final Designs
The feedforward moment, before and after.
New warning-icon column flags non-actionable items1
Tooltip explains why an item is non-actionable2
Popover previews what will and won't happen3
Feedforward, before the click
Non-actionable items stay selected after confirming1
Success and error toasts make the outcome clear2
Feedback, after confirming
Results & Impact
5 Jira tickets closed
by the Product and Client Services teams, opened by 5 different clients frustrated by the old pattern.
1 reusable pattern
across every complex table in the product afterward, so the design team never had to solve this problem twice.
Reflection
Why feedforward, not feedback, mattered here.
A warning icon, a tooltip and a confirmation popover weren't extraordinary elements on their own. What mattered was sequencing them so people understood the consequence of an action before committing to it, not after.
In a compliance tool where the underlying permission logic is genuinely hard to hold in your head, four overlapping rules stacked on role, stage, and a maker-checker policy, that shift from feedback to feedforward is what actually closed the support tickets.
Case Study 05
Removing revolving credit to protect consumers
How driving user focus toward Santander's personal loans, in place of a lending product regulators were phasing out, led to a €7.5M annual boost in requested loan amounts.
Company
Santander Consumer Finance Benelux
Period
2020
Role
CRO & UX Research, Marketing Team
Impact
+€7.5M annual loan volume
Context
A regulator's decision meant one product had to disappear.
The VFN (Association of Financing Companies in the Netherlands) protects consumers against excessive lending and unnecessary financial risk. When it tightened its lending standards in 2020, during COVID, many banks, Santander Consumer Finance Benelux included, stopped offering revolving credit altogether.
As part of the marketing team, I was asked to assess what pulling revolving credit off the website would mean, not just for the informational pages that had to come down, but for how the rest of the site steered people toward personal loans instead. Beyond removing those pages, we identified three areas that needed redesign and A/B testing: the product comparison cards, the loan purposes section, and the loan simulation page.
Research
Short survey results.
I ran a survey directly on the website, using the Hotjar Feedback Widget, to understand what actually drove the loan decision.
Simplicity wins
28% of participants named the simple process as the most important factor in their loan decision.
Expectations matter
22% of participants pointed to a need for expectation management before applying.
A/B testing experiments as a sequence to isolate the effect.
Two things stood out from the survey that pointed straight at specific experiments:
A hidden USP
The homepage led with "Arranged in 3 steps" as a selling point, but nowhere else on the site said what those 3 steps were.
An opening, not just a loss
Removing the comparison cards was a chance to let loan purposes do more of the work of guiding people toward personal loans.
The hypothesis: emphasising loan purposes on the homepage, and surfacing the 3-step USP on the loan simulation page, would set clearer expectations and offset any dip in applications from revolving credit disappearing. At worst, conversion would hold flat; at best, it would improve.
Experiment #1: simplify the comparison. Removed the personal loan vs. revolving credit comparison cards, kept only the loan purposes tied to personal loans, and updated their icons to the brand's current icon set.
Removed: comparison cards1
Kept & updated icons2
Experiment #2: surface the 3-step USP. Removed all revolving credit copy, moved personal loan copy into its former slot, placed the "in 3 steps" USP and its icons where personal loan copy used to sit, and gave the section a heading: "Your loan in just 3 steps."
Removed: revolving credit copy1
Added: 3-step USP2
Results & Impact
3.9%↑ in conversion rate
A positive but not statistically significant trend, suggesting the removal of revolving credit reduced doubt and confusion between the two products rather than adding friction.
€7.5M↑ in annual requested loan amounts
The projected increase, and the figure that greenlit the design solutions for full rollout.
Reflection
This project didn't start with a UX problem, it started with a regulatory one: a product was being switched off, and the business needed the rest of the funnel to absorb that loss without users noticing the gap.
The survey gave me just enough evidence to make two small, targeted changes rather than a redesign, which mattered because every change still needed sign-off and engineering time.
Sequencing the two experiments also meant that if something went wrong, I'd know exactly which change to undo, instead of guessing across several changes made at once.
100%
Scroll or pinch to zoom · drag to pan · Esc to close