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.
My job was not just to lead Designers. It was to build 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: custom UI crawler > Airtable > Live dashboards
AI workflows embedded: Cursor + Figma MCP → GitHub
First-ever Designer code commits to production
Consistency score goal of ≥90% achieved: 93.1% coherence
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.
Checkout did not just need more Product Designers.
It needed a Design organisation with the skills to understand merchants properly and improve the experience at every point where complexity showed up.
That meant building the right capabilities around the product: Product Design, UX Research, Content Design and Technical Writing.
The important decision was to build these disciplines as one organisation, not separate teams orbiting the product from the outside.
Each discipline solved a different part of the customer experience, but they shared the same responsibility: reduce complexity, raise quality, and help Checkout build products merchants could understand, use and trust.
The decision was not just to add specialist roles. It was to connect the disciplines around the same product context, so each team helped reduce complexity, raise quality and build products merchants could understand, use and trust.
Design was not going to gain influence at Checkout by asking to be involved earlier. It had to prove that working with Design made the work better and more connected to customer outcomes. This meant getting involved while direction was still open – in planning, discovery, problem framing and early decision-making. The value was not in adding more process, but in helping teams understand the customer problem, see trade-offs earlier and make clearer product decisions.
That way of working shaped the team I built. Designers needed to be strong collaborators, not just strong practitioners. They needed to build trust, challenge constructively and help improve outcomes before the work was already 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 not just strong design practitioners – but those who could 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.
If Design was going to have more influence, it could not depend on individual relationships or designers being pulled in at the right moment. I needed to make Design part of the way product work moved through the organisation.
That meant creating clear points where Design could add value – in planning, discovery, problem framing and roadmap conversations – before teams had already committed to a solution.
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. That meant treating development as part of how I managed the team week to week. 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 was not reserved for people managers. It 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, scale brought a different problem. It was no longer just about having enough designers.
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 keeps 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.
The partnership model changed where Design showed up in the product delivery rhythm. Design was no longer brought in only when a team needed screens. Designers were closer to planning, discovery, problem framing, delivery decisions and launch, giving Design more influence while important decisions were still open.
Product had clearer trade-offs, Engineering had better context, and designers stayed accountable 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.
This was not red tape. It helped teams ship into Dashboard with the right product context, system alignment, design quality and engineering readiness.
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.
The point was not to pretend every Design decision maps neatly to one business metric. It was to build a system where Design quality could be tracked, improved and connected back to customer and business outcomes.
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 was not just better reporting, it gave teams a practical way to improve the live Dashboard, reduce unnecessary variation and hold consistency as a shared product quality metric, with consistency improving 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, showing where we were improving product quality, increasing delivery confidence, strengthening customer understanding, building new capability and raising Checkout's reputation as a design organisation.
Instead of reporting activity, headcount and project updates, the OKRs gave us a clearer way to show whether Design was improving the product, strengthening how teams worked, and building capability that could compound over time.
At the product level, that meant reporting on coherence, quality debt, QA time, documentation quality and customer understanding. At the function level, it meant showing whether designers were moving closer to production, whether AI was becoming part of deep work, and whether Checkout Design was becoming more visible externally through events and published content.
The point was to make Design part of the business operating rhythm, so quality, clarity, customer understanding, delivery confidence and reputation could be discussed as measurable inputs to company 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.
The point of measurement was not to create a Design dashboard. It was to make quality visible enough that Product, Design and Engineering could make better decisions together.
Once operational health, Design System adoption and delivery quality were visible, the conversation changed.
Design debt could be prioritised because it was visible in the product. QA issues could be discussed before they became release problems. Coherence could be tracked over time rather than debated subjectively.
It also gave Design a stronger voice in business conversations. Instead of reporting activity or relying on opinion, we could show where quality was improving, where the product was still carrying debt, and where investment would help merchants move through Dashboard with less friction.
That made Design more accountable and more useful to the business, because quality, clarity and coherence became part of how we discussed product performance.
The strongest opportunity AI gives Design is not productivity. It is getting designers closer to production, making the gap between a design decision and a shipped customer experience smaller.
AI tooling is changing what is possible. Designers can prototype with production components, test realistic flows, understand implementation trade-offs, and defend quality further into delivery.
I grounded adoption in real work. The team had protected time to experiment with Cursor, Figma Make, Gemini and Claude, not to generate productivity theatre, but to solve actual product problems and build honest confidence in where the tools helped.
Learning was shared across the wider organisation through write-ups, Product Jams, Brown Bags and external design community events. 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.
The goal was never to turn designers into engineers. It was to reduce the distance between the design decision and the customer experience, and to protect quality further into delivery.
The most useful shift was not faster prototyping, but 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 was coming up, what needed attention and where the operating rhythm was slipping.
We used LLM-generated JavaScript to build "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.