Checkout.com is a B2B payments platform that enables enterprise businesses to accept, process and optimise digital payments – across markets, currencies, payment methods and channels.
It handles the entire journey: from the moment a customer hits pay, through fraud screening, authorisation, currency conversion, and settlement, to the reporting and analytics that help merchants understand and improve every transaction.
Unlike most providers who piece together third-party tools, Checkout.com built everything itself – one platform, serving over 1,000 enterprise merchants, processing $300B in 2025.
In 2020, the business was scaling quickly across markets, products and teams, but Design had not scaled with it. There was no established Design organisation, no clear coverage model, no shared operating rhythm, and limited influence in product decision making.
I joined for the opportunity to build a Design function from the ground up – team structure, rituals, quality systems and cross-functional trust – so Design could become a natural part of how Product and Engineering shaped better outcomes.
Leading the designers was only part of the role, because the bigger job was building the conditions for good Design to happen consistently, at speed and at scale. That meant building the team, the standards and the operating model that allowed Design to shape better product decisions, raise quality across the experience, and connect its work more clearly to customer and business outcomes.
The Design org timeline
2 product designers, no processes or infrastructure
Mapped coverage gaps across all product areas
Made the case for 4 disciplines: Product Design, UX Research, Content Design, Technical Writing
Built the function’s operational backbone
Skills mapping and tooling standardisation
Design Systems training budget secured
Career frameworks drafted and launched across all levels
Operating rituals embedded: Town Halls, crits, socials, learning and development initiatives
Jira workflows standardised across disciplines
Design system work begins: component library and contribution model
Grew to 44 designers, writers and researchers.
Design organisation moved to centralised partnership model
Sign-off governance built with Product and Engineering
Design System built: tokenised, dark mode, WCAG 2.2
Dashboard consistency baseline established
Design metrics established: 5 functions, 15 objectives, 37 KRs tied to business outcomes
Live reporting: Design impact visible to the business
Jira → Airtable pipeline for cross-discipline capacity planning
Dashboard consistency score automated across 36 product teams, from a custom UI crawler into Airtable and live dashboards
AI workflows embedded: Cursor + Figma MCP → GitHub
First-ever designer code commits to production
Dashboard consistency goal of ≥90% exceeded, reaching 93.1%
400% increase in Design System contributions
Debt backlog reduced 20%
Before changing the team, I needed to understand where Design was missing, where quality was breaking down, and where trust needed to be built.
Checkout had two Designers and no shared Design process. Work was reactive, coverage was patchy, and Design had little presence in the conversations that shaped what got built.
What became clear was that Design was not yet understood as a strategic product function. It was too often seen as a downstream resource for finishing work, rather than a partner in understanding customers, framing problems and improving product decisions.
Merchants needed more than Product Design alone, so I built UX Research, Content Design and Technical Writing alongside it as one organisation, with each discipline solving a different part of the customer experience.
Influence at Checkout was never going to come from asking to be involved earlier, so Design had to show that working with us made the work better and more connected to customer outcomes. In practice, that meant joining planning, discovery and problem framing while direction was still open, and helping teams understand the customer problem and see trade-offs before decisions settled.
That way of working shaped the team I built, because designers needed to be strong collaborators as well as strong practitioners, able to build trust, challenge constructively and improve outcomes before the work was locked.
Craft matters, but it wasn’t enough to build the Design function Checkout needed.
With 36 product teams, constant organisational change and an increasing level of product and technical complexity, I hired for the behaviours that would change how Design showed up in the business. I hired strong design practitioners who could also coach others, earn trust, influence direction and scale Design’s impact across Checkout.
Hiring was paired with clear expectations, feedback and development systems so all designers raised the quality of the team around them, not just their own output.
As the team grew, I wanted quality to be owned by every designer – not just in their own work, but in the work of the team around them. The rituals I introduced gave designers regular ways to share work, challenge openly, spark healthy debate, support each other and build a shared understanding of what good looked like.
The goal was not more meetings. It was quality discussed openly, raised collectively and owned by everyone.
Critique was one of the clearest ways to raise quality across the team, but only if designers felt safe bringing work before it was finished.
Too much work was coming in late, polished and already defended. Designers were worried that unfinished thinking would be judged as bad work, so critique became more of a presentation than a place to shape the work.
I wanted critique to become a working ritual – a place where designers could bring rough thinking, ask questions, expose uncertainty, challenge each other properly and build shared judgement of what good looked like without fear that early work would be used against them.
Show-and-tell, not critique
Work was shared for visibility, but not always challenged deeply enough.
Too polished, too late
Designs often came in when the direction was already hard to change.
Siloed feedback
Teams were solving similar problems without enough cross-team visibility.
Comment-heavy feedback
Figma comments were useful for detail, but they did not replace live discussion and shared reasoning.
Build psychological safety
Set the expectation that early thinking, rough flows, sketches and open questions were expected.
Frame the ask clearly
Designers came with the problem, context, constraints and the decision they wanted help with.
Challenge the thinking, not
the person
Feedback focused on rationale, trade-offs, behaviour, content, accessibility and system fit – not personal preference.
Build shared judgement
Crit became a way for the team to define quality together, not just improve one person’s work.
Real critique forum
Active challenge, not passive review
Better thinking, earlier
Designers got input while the work was still evolving.
Stronger rationale
The team became better at explaining decisions, trade-offs and reasoning.
More connected work
Patterns, duplicated effort and cross-product issues surfaced earlier.
Shared judgement of quality
The team defined what good looked like together, so quality became something designers could discuss, challenge and apply consistently.
I wanted development to be a deliberate part of how I managed the team, not something that only happened during review cycles. I wanted every designer to understand where they were strong, where they needed to grow, what kind of scope they were moving towards, and how their current work connected to the next level of impact. In 1:1s, we revisited development plans, talked through feedback, connected growth areas to live work, and made sure each person had a clear path to increase their impact through the work they were already doing.
I wanted senior designers to use their experience, judgement and craft to make the team around them stronger – raising quality, building confidence and helping others make better decisions through the work.
That meant senior ICs had to operate beyond their own projects, with coaching, critique, visible standards, unblocking decisions and trust-building with Product and Engineering becoming part of how leadership showed up in the craft.
Leadership extended well beyond people managers and was built through real scope, so senior designers increased the quality and confidence of the wider team, not just the quality of their own work.
As the team grew, the challenge shifted from having enough designers to keeping them connected.
The bigger risk was fragmentation – designers becoming isolated in product teams, teams solving similar problems in different ways, quality depending on who happened to be involved, and Dashboard slowly turning into a collection of disconnected experiences.
The challenge was to keep Design close to the work without losing the benefits of a single function – embedded enough to understand the problem, connected enough to raise the quality of the whole product.
I moved the Design organisation to a model that kept designers close to product work without losing the benefits of a single connected Design function. The Centralised Partnership model kept designers committed to specific product areas to build context, understanding of the roadmap, the problem space and the people they were working with, while the Design function stayed centrally connected through shared standards, rituals and leadership.
Keeping Design connected as a central function also gave visibility across the wider product ecosystem, so we could see where support was needed and focus it on the highest-impact work.
As trust with Product grew, Design moved upstream into roadmap planning with pillar leads and PMs.
Instead of receiving briefs after direction was already set, Design helped teams understand priorities and customer needs, sequence Design effort around real delivery milestones, and decide where UX Research, Content Design and Technical Writing could support the highest-impact work.
Roadmap planning became a place to influence direction, not just plan resourcing. Design could challenge unclear problem framing, spot overlaps across teams, connect related work, and make trade-offs visible before decisions became fixed.
If Design was going to have more influence, it could not depend on individual relationships or designers being pulled in at the right moment, so the partnership model built Design into the way product work moved through the organisation.
Designers were involved in planning, discovery, problem framing, delivery decisions and launch rather than only when a team needed screens, which gave Design a voice while important decisions were still open. Product gained clearer trade-offs, Engineering had better context, and designers stayed accountable well beyond the design file.
Dashboard had become a shared product surface, with multiple teams adding new pages, features, services and journeys into the same experience.
It was carrying the symptoms of a product built by many teams. Reasonable local decisions still created fragmentation – journeys behaved differently, patterns did not always connect, content explained similar things in different ways, data states were handled inconsistently, and edge cases made the product feel less considered.
I led and authored the Dashboard design and development sign-off process with Product and Engineering to add clearer governance around significant Dashboard work so new work felt like part of one coherent product surface rather than another team’s feature added onto it.
The process was designed to help teams ship into Dashboard with the right product context, system alignment, design quality and engineering readiness, rather than to slow them down.
Design Sign-off made design readiness explicit before work moved formally into build.
It was a key go/no-go step in the Dashboard process, used to decide whether the work met the bar for quality, consistency and user experience before implementation.
The important part was that Design Sign-off was not just a Design review. The governance group brought together Design, Product and Engineering so the end-to-end experience could be assessed from more than one angle before handover.
Teams had to bring the full journey, prototype, content in context, relevant states and edge cases, a Design System linter score, success metrics and any decisions they needed the group to make.
That made Design Sign-off a collective quality gate, not a taste review. It gave Product, Design and Engineering a shared moment to confirm what was moving into build, what still needed to change, and whether the work met the quality bar for Dashboard.
Is the experience clear?
Is it coherent with the wider Dashboard experience?
Are the right states and edge cases covered?
Does the content work in context?
Is the Design System used correctly?
Do we know how success will be measured?
Are Product, Design and Engineering aligned on what is moving into build?
As the Design function matured, I wanted to move beyond measuring activity and start measuring whether Design was improving the quality and performance of the product.
Very few Design decisions map neatly to a single business metric, so the aim was to build a system where Design quality could be tracked, improved and connected back to customer and business outcomes over time.
Design work was happening across teams, tools and product areas, but it was hard to see the health of it as one system. Measuring design work properly meant moving beyond activity tracking. I needed Design and Product to see what was moving, where effort was going, where work was blocked, where QA was dragging, and where quality checks were missing before those issues became delivery risk.
We built an integrated workflow that pulled roadmap items from Jira into a custom Airtable dashboard and gave leads a live view of current work, backlog, workload, QA status, upcoming crits, upcoming sign-offs and delivery health.
This dashboard became part of the team’s weekly operating rhythm. We used it to review priorities, identify pressure points, make trade-offs visible, and decide where Design effort needed to shift.
This gave the team a clearer way to manage operational health, connect design effort to product delivery, and make quality more measurable than a set of opinions or late-stage escalations.
Dashboard had grown across multiple product teams, with each team owning its own micro front-end. That made consistency hard to judge from design files alone. Teams could ship screens that looked acceptable in isolation while still adding variation, maintenance cost and friction to the wider product.
The first approach was manual. We audited the live Dashboard by screenshotting components, red-lining inconsistencies and grouping like-for-like patterns. That turned inconsistency into evidence Product, Design and Engineering could act on.
The audit gave us a baseline for where the Design System needed to improve, where teams were creating unnecessary variation, and where quality was breaking down in the live product.
Manual audits gave us the baseline, but they were too labour-intensive to keep pace with the rate of change across Dashboard. I led the move from periodic visual audits to a purpose-built UI Crawler, working with Engineering to turn Design System usage in the live product into a recurring quality signal.
The conversation changed from “we think the system is being adopted” to “we know what is happening in production, what changed since the last scan, and where the next improvement should happen.”
That made quality legible beyond Design. Product and Engineering could see where Dashboard was aligned to the system, where deprecated components remained, where overrides were creating inconsistency, and where design debt needed to be prioritised.
Once Design System adoption was measurable in production, quality debt could be managed like product work.
The crawler showed where Dashboard was aligned to the system, where deprecated components remained, and where overrides were creating inconsistency in the live product. Product, Design and Engineering could work from the same evidence, decide what needed fixing, and track whether the product was becoming more coherent over time.
The result gave teams a practical way to improve the live Dashboard, reduce unnecessary variation and treat consistency as a shared product quality metric, with Dashboard consistency rising from 5% to 93.1% by Q2 2026.
When teams used the right components, tokens and patterns, Dashboard became more consistent for merchants, easier to maintain and faster to improve.
When they did not, complexity kept accumulating in the product, even when individual screens looked fine.
That gave Design a more credible way to connect craft to product performance. Coherence, content quality, journey clarity and system adoption became signals that showed where the experience was helping merchants, and where it was still creating friction.
I wanted leaders to understand Design through the same lens as any other strategic function, so we set Design OKRs across 5 functions, with 15 objectives and 37 key results tied to business outcomes.
Instead of reporting activity, headcount and project updates, we reported on consistency, quality debt, QA time, documentation quality and customer understanding at the product level, and on whether designers were moving closer to production, whether AI was becoming part of deep work and whether Checkout Design was becoming more visible externally at the function level.
Once that was visible, design debt could be prioritised because it showed up in the product, QA issues could be discussed before they became release problems, and consistency could be tracked over time rather than debated subjectively. That gave Design a stronger voice in business conversations, because quality, clarity and consistency became part of how we discussed product performance.
Design impact became clearer when what customers said was read alongside what they did and the outcome the business needed to move. NPS, CSAT, usability feedback and customer comments helped us understand perception, confidence and pain. But on their own, they were not enough to measure Design impact.
Pairing sentiment with behaviour and outcome data helped Product, Design and Engineering understand whether the experience was actually helping merchants move through the product more successfully.
AI gave designers a practical way to work closer to production, reducing the gap between a design decision and the experience that eventually reached customers, because they could prototype with production components, test realistic flows, understand implementation trade-offs and defend quality further into delivery.
I grounded adoption in real work, giving the team protected time to experiment with Cursor, Figma Make, Gemini and Claude on actual product problems instead of productivity theatre, so confidence in where the tools helped was honest and earned.
Learning was shared across the wider organisation through write-ups, Product Jams, Brown Bags and external design community events, and Design became one of the teams showing the rest of the company what practical AI adoption looked like when it was connected to real systems and real constraints.
We’ve spent a lot of the last decade designing pictures of interfaces in tools like Figma. They gave us incredible control over visual craft, but much of the behaviour between those screens – state, transition, response, responsiveness and edge cases – was still described through prototypes and annotations, then interpreted with Engineering later.
AI-assisted coding tools are changing that by letting designers build working prototypes much earlier, using the same components, tokens and patterns as the product itself. Instead of another sequence of static frames, designers could work with something they could run, interact with and change, shaping states, responsive behaviour and edge cases while the experience was still being designed.
At Checkout, we worked with Engineering to give designers access to those production foundations and connected Figma with tools like Cursor through MCP, making it much easier to move from interface design into a working prototype without starting again.
For me, that gives Product Designers back an important part of the craft, allowing us to apply judgement to more than how an experience looks and spend more time shaping how it actually behaves and feels to use.
Coded prototypes gave us much better fidelity between design intent and the product that would eventually ship. Designers could move from Figma into coded prototypes that used the same Design System components, primitives and tokens as Dashboard, using Figma MCP to bring design context into Cursor and generate prototypes from real product foundations.
That meant teams were no longer reviewing static screens and imagining how the experience might behave later. Designers could test interaction and behaviour earlier, researchers could run more realistic flows, Design Sign-off could happen against something closer to the final experience, and Engineering received work with clearer intent because the prototype already reflected the components, tokens and interaction patterns used in production.
We set this up with Engineering using secure tooling, scoped packages, documentation, office hours and hands-on support, so designers could work closer to implementation without needing deep technical knowledge or being asked to become engineers.
Interaction design does not only happen in Figma. It shows up in behaviour, states, edge cases, implementation detail and whether the product still feels coherent once it is live. Once audits and the UI crawler made quality issues more visible, the next step was giving designers a practical way to act on the debt sitting between design intent and the shipped experience.
Many of the fixes were small but still visible to merchants. Incorrect token usage, outdated components, inconsistent states, layout drift and patterns moving away from the Design System all weakened the overall Dashboard experience, but were difficult for Engineering to prioritise against roadmap delivery.
Cursor gave designers a way to move from identifying the issue to proposing the fix. They could inspect the relevant part of the codebase, understand how a component, token or state had been implemented, make a small scoped change, and push that change through the normal GitHub review process. Engineering still reviewed production changes, so this did not bypass the normal standards of build, but it did mean designers could close small gaps between intent and implementation, instead of relying on every issue becoming another backlog request.
We had a lot of valuable insight about merchants, but it was hard for anyone outside the research team to find and use. Interview transcripts lived in a separate per-seat platform, while synthesis and findings often sat in separate research documents or old Slack threads.
The team created a research repository in Google Drive, with transcripts, notes and findings organised more consistently to centralise that knowledge base. Sessions had cleaner metadata, findings were easier to browse, and product areas, customer problems and recurring themes were tagged so insight could be reused. Gemini gave anyone in the organisation a practical way to query the repository. People could ask questions across existing research, find relevant themes, pull supporting material and understand what we already knew before starting new work, just by asking.
AI also helped the research team with slower operational tasks, including transcription, PII removal, tagging, synthesis and finding patterns across sessions.
This made research insight easier to use across the organisation, while giving researchers more time for judgement, interpretation and influence.
Some of the most useful AI work was in the everyday running of the Design function, where small recurring tasks were important but easy to drop when everyone was busy.
Crits needed scheduling. Sign-offs needed booking. Town Halls needed preparing. Reminders needed sending. The team needed to know what work was coming up, what needed attention and where the operating rhythm was slipping.
We built “Critter Bots” that connected Google Calendar, Airtable, Zapier and Slack, then pushed reminders and updates into the places the team already worked.
That removed recurring coordination work, made the rhythm more reliable and reduced the amount of Design Ops effort needed to keep the team moving.