All work
Purse · 2026 · rolling out

Two designers, one back office, one logic

Rethinking how we design the Purse back office: who owns what, and who we design it for.

Before

One designer for the whole back office
Product Designer A
Available capacity
  • Checkout
  • SDK
  • Design system
Shipped, stable
Product Designer B
  • Payments
  • Reconciliation
  • Analytics
  • Onboarding
  • Technical setup
  • Orchestration
  • Monitoring
  • Automations
8 features, diverging patterns

After

Two designers, four journeys
Product Designer A
Payment & reconciliation
  • Payments
  • Reconciliation
Orchestration
  • Rules
  • Routing
2 end-to-end journeys
Product Designer B
Home & analytics
  • Analytics
  • Monitoring
Onboarding & setup
  • Onboarding
  • Technical setup
  • Automations
2 end-to-end journeys
Shared design system · Cross reviews
Design capacity moves from stable products to the back office, split into journeys.
ROLE
Lead Product Designer (vision, team organisation, product trade-offs)
SCOPE
The Purse Payment back office, used by our clients and internal teams
TEAM
2 Product Designers, 1 PM, the Head of Product
STATUS
Approved by the Head of Product and the CPO, rolling out
In short

The back office is the shop window of payment orchestration: it’s the only part our clients see and use. One designer carried it, facing an ambitious roadmap and journeys that had drifted apart. I proposed a new setup with two designers, split by business journey, and an internal mode inside the same product rather than a separate tool.

  • 4business journeys, each with an owner
  • 1product, 2 modes: client and internal
  • −30%Targettickets escalated to devs (6-month target)
Context

For our clients, the back office is the product

Payment orchestration is invisible by nature. What our clients actually see of it is the back office: tracking activity, opening a payment’s details, reconciling with the bank, adjusting a few orchestration settings.

Internally, the same tool is what Purse teams use to create a client’s environment and entities, set up payment methods technically, put automations in place and monitor activity.

At the same time, my own workload was dropping: Checkout and the SDK had shipped, and the design system was stable. On Identity, design work was mature: PMs prototype there themselves with the design system, and we run journey reviews.

THREE SIGNALS CAUGHT MY ATTENTION
  • A roadmap picking up speed on a scope carried by a single designer, still junior.
  • Inconsistent journeys: each feature designed as it came, with its own patterns.
  • Recurring feedback from support, tech and integration teams, who were using a tool designed for someone else.
The problem

Design capacity sat where the product was already stable, and was missing where the product was most visible.

Decision 1

Splitting the back office by business journey

Moving to two designers wasn’t enough. We had to decide how to share the back office, and several splits made sense.

Split optionUX consistencyPattern reuseDomain expertiseBig pictureScore
By personaTwo screens for the same object2/8
By productOversized on Identity3/8
By featureEveryone boxed into their screens1/8
By business journeyChosenOne expert per end-to-end journey8/8

  • By persona (client / internal)

    Rejected

    Support, clients and integrators look at the same objects: a payment, an entity, an orchestration rule. Splitting them means designing the same screen twice and letting two visual languages drift apart. It also breaks what saves support the most time: seeing what the client sees.

  • By product (Payment / Identity)

    Rejected

    Identity is mature and self-sufficient, with lower stakes and a lighter workload. A dedicated designer there would have been oversized. What Identity needs first is instrumentation, to understand the real journeys.

  • By feature

    Rejected

    Too granular: each designer gets boxed into a few screens and loses the big picture.

  • By business journey

    Chosen

    Each designer becomes the expert of an end-to-end journey, one that runs through several key features of the product, for every profile that takes it.

The split is based on the back office user journey map.

  • Onboarding & technical setupProduct Designer B
    • Support
    • Dev / integrator
    1. Create the entity
    2. Set up the environment
    3. Activate payment methods
    4. Put automations in place
  • OrchestrationProduct Designer A
    • Client
    • Support
    • Dev / integrator
    1. Define the rules
    2. Route payments
    3. Handle fallbacks
  • Payment & reconciliationProduct Designer A
    • Client
    • Support
    1. Track a payment
    2. Open the details
    3. Reconcile with the bank
  • Home & analyticsProduct Designer B
    • Client
    • Support
    1. Overview
    2. Analyse activity
    3. Monitoring
A payment method activated during onboarding is routed by orchestration, then opened in the payment details: journeys cross, owners stay clear.

The boundaries are porous on purpose: a journey always crosses another one. To keep the two halves from drifting apart, two guardrails:

  • A design system with shared ownership: everyone contributes, nobody keeps it to themselves.
  • Cross reviews: each journey is reviewed by the other designer before development.
Payment & reconciliation
Product Designer A
Orchestration
Product Designer A
Home & analytics
Product Designer B
Onboarding & technical setup
Product Designer B
Decision 2

An internal mode inside the same back office

Purse teams don’t think like our clients. A merchant starts from a need: tracking payments, reconciling, analysing. We start from an entity and its configuration. Same data, different mental model, so a different navigation.

To decide, I interviewed internal teams and studied other tools on the market. The conclusion:

  • Merchant mode: navigation by features and needs

    It’s the standard for payment back offices, so it’s what our clients already know.

  • Internal mode: navigation by entities

    You pick the client and the entity first, and everything else follows from that context: configuration, payment methods, monitoring, payments.

A deliberate choice: no innovation on the merchant side

The temptation was to reinvent the navigation to stand out. I ruled it out: our clients already use other payment tools, and every departure from the standard costs them learning time without giving them anything back. The innovation effort goes where it creates value, the internal mode, where no standard matched the way we work.

Not this: a custom merchant navigation, more distinctive in a demo but more costly to learn day to day.

Internal interviews + benchmark of market tools
MERCHANT MODE

By features / needs

Market standard“Where are my payments at?”
  • Home
  • Payments
  • Reconciliation
  • Analytics
  • Orchestration
  • Settings
  • 1 level
  • 1 entry per need
INTERNAL MODE

By entities

From internal interviews“What’s going on with this client?”
CLIENT
Client A
ENTITY
FR entity
  • Environment
  • Payment methods · technical setup
  • Orchestration rules
  • Automations
  • Monitoring & logs
  • Entity payments
  • 2 levels
  • Everything starts from the entity
Same API · Same environment · Same version

Two options were on the table:

  • A separate internal back office

    Rejected

    Two products means two codebases to maintain, two versions drifting apart, and a support team that no longer sees what the client sees.

  • An internal mode inside the same product

    Chosen

    Same environment, same API model, same version. Only the experience changes: navigation starts from the entity, the UI is denser, and extra data and actions appear for admins, support, devs and integrators.

CLIENT READConsult
€1,240.00Captured
Payment method
Card •••• 4242
End customer
j.martin@example.com
Timeline
  1. Created
  2. Authorised
  3. Captured
Refund
INTERNAL READConfigure · diagnose
€1,240.00Captured
Payment method · end customer · timeline= client view
RoutingVisible by role
PSP used
PSP A
Rule applied
Rule 12 · card fallback
Raw PSP responseVisible by role
{ "status": "captured", "psp_code": "00", … }
Technical IDsVisible by role
Entity
ent_8F2K
Transaction
txn_51QX
Webhook historyVisible by role
payment.authorized
500 · replayed
payment.captured
200
Replay the webhookView the entity configuration
Same payment, same screen. Internal mode keeps the client read and adds the technical blocks, shown by role.

What this mode forced me to decide:

  • Roles and permissions

    Who sees the internal mode, and who can act.

  • Level of detail

    For a payment: what helps the client, and what only matters internally.

  • Navigation

    By entities internally, by features on the merchant side.

  • Primary actions

    Consult on the client side, configure and diagnose on the internal side.

Making the case

Framing the project as a business issue

I argued for this project on business grounds. The back office is our product’s shop window, what our clients buy without realising it, and that’s where design capacity was missing. The Head of Product, then the CPO, approved it.

Impact

What we’ll measure

First effect the team sees: we deliver better and faster. The rollout continues, and these figures are still targets, not results yet.

  • Screens compliant with the design system
    6-month target
  • Support tickets escalated to devs
    6-month target
  • Time to set up a new client (entity + payment methods)
    6-month target
  • Back office satisfaction (SUS)
    6-month target
  • Components shared between client and internal modes
    6-month target
What I took away

I’d been thinking about it since I joined Purse: it was the repeated conversations with the teams that gave me the arguments to push it through.

What I’d do differently: launch it sooner. The intuition was right. What I lacked was the habit of documenting it from the first signals, so I could defend it faster.