Logibiz
A payments back office where one wrong field costs money.
I designed the Merchant dashboard for Logibiz, a London payments company, and the design system it runs on. It is where merchants set up businesses and terminals, take payments, send invoices and control who can do what.
Visit live site
The 20-second read
The product
The back office of a London payments company. Merchants take payments, set up terminals, send invoices and control access.
My part
UX, UI, flows and the design system for the Merchant and Client dashboards.
Where it stands
Live and used by Logibiz’s teams. Merchant setup went from about 9 minutes to about 4 min 17 sec, per its technical support manager. Redesign about 30 to 40% built.
03 / The business
A company that builds the infrastructure behind card payments.
Logibiz Technologies is a London fintech. Its customers are payment gateways and merchants, card issuers and acquiring banks. According to its CEO in October 2026, Logibiz has 230 customers, 189 of them active.
It works to PCI DSS, PSD2 and EMVCo standards, in the cloud or on a customer’s own servers.
Why the dashboard matters
When a company sells infrastructure, the dashboard is the part its customers touch. People judge the product by how safely and quickly they can set up a merchant, take a payment and find one later.
Where Logibiz sits in a card payment
- PaybizWhite-label payment gateway
- Paybiz3DSEMVCo-certified 3-D Secure server
- PaybizACSAccess control server for issuers
- PaybizSDKMobile authentication
- Simbiz3DS3-D Secure test simulator
04 / The problem
The domain is hard, not the pages.
Logibiz built its first dashboards when it was a small startup, and they did the job. Then the company grew. The pages had been drawn one by one, so the sidebar, tables, forms and buttons looked alike but were not the same thing. Every new page meant redrawing them, and every handoff meant developers guessing.
A deep chain of setupThe order of work matters
- Business details
- Contacts
- Address
- Settlement accounts
- External connection
- Payment instruments
- Action codes it may process
Example action codes: AUTH, PURC, CRED, INQ, VAUTH
- Merchant and terminal
- Action code, amount, currency
- Card data and instrument
- Reference IDs
- 01
Forms where one wrong field costs money
Entering a payment takes merchant, terminal, action code, amount, currency, card data, instrument and reference IDs.
- 02
Very different users in one product
Some staff set merchants and terminals up, some take and look up payments, some only read reports. Each role needs a different slice.
- 03
Volume and traceability
People search payments by merchant, terminal, date, card brand, status and 3-D Secure, then export them. The dashboard keeps login history and audit trails.
- 04
Development in parallel
Developers build while design continues, so every page has to be made from parts they can reuse.
Design once, reuse everywhere, and give developers rules instead of pictures.
05 / My role
I own the design, and I set the order it was delivered in.
I own UX, UI, flows and the design system for the Merchant and Client dashboards. Logibiz now has a second designer, and we work in the same component library. While Logibiz’s developers build, I stay in touch with the team and answer their questions about the designs.
Order of delivery
- 1Merchant dashboard and design system first, so development could start.
- 2Client dashboard designed in parallel.
- 3Developers were never waiting for design, and the project took less time.
End-to-end flows
Every task, from sign-in to outcome
Merchant dashboard
Set up, take and find payments
The order the flows enforce
Merchant→Terminal→Payment
Client dashboard
Message, manage and approve
Each flow is mapped in full: steps, decisions, error paths and outcomes.
06 / Six decisions in the Merchant dashboard
Six decisions that made a payments back office easier to use.
Each one is about the same thing: keeping a person from making an expensive mistake, and keeping the page quick for the person who does it all day. These are real pages from the dashboard.
Decision 01
Setting up a merchant in four small steps
Adding a merchant needs a lot of information, so I split it into four tabs: Merchant, Contact, Address and Account. Each tab is one small job, and the user can see what is still missing. A merchant with more than one bank account can add more on the Account tab.
Decision 02
Choosing what each terminal can do
A terminal is the point where a merchant takes card payments, and each one needs rules about which actions it may run. I showed the rules as checkbox cards with a Select all button, so setting up a terminal takes a few clicks, not a long form.
Decision 03
Taking a payment: the important fields first
I put the fields that decide everything first (which merchant, which terminal), then the amount and card details. Reference numbers, used only for matching and follow-up, come last.
Decision 04
Finding a payment fast
The search page filters by merchant, date, card brand and status, and has a switch for 3-D Secure, the extra security check on card payments that is Logibiz’s main product. Card numbers show only the last four digits, and results can be exported.
Decision 05
Billing a customer again and again
A subscription is a bill that repeats, so the page works like a bill: who is paying, what they are buying, how they pay, then when it repeats. It feels like an invoice, not a one-time payment form.
Decision 06
Giving each person only the access they need
An admin creates roles, then ticks what each role can see, add, edit or delete on one page laid out like the menu. Login history and audit trails show who did what.
07 / The design system
One system under every page.
Every dashboard page in both products is built from one system, now being extended across the whole company. It replaced a set of screens designed one by one with shared variables, text styles, components and templates.
A / Two layers of tokensDesigners only use layer two
Layer 1 / Raw values
- brand/50
- brand/100
- neutral/100
- neutral/200
- neutral/300
- danger/600
Raw values are never used on a page.
Layer 2 / Meaning, aliasing layer 1
- text/brand→ brand/600Links, active tab, selected nav label
- bg/brand-subtle→ brand/50Selected nav item, icon bubbles, selected tree row
- border/default→ neutral/100
- text/disabled→ neutral/300Disabled text and dates outside the month
- text/danger→ danger/600Errors and destructive labels
A brand change is made in one place: layer 1.
B / Pick the template firstFive templates cover every page
- List pageA set of records.
- Form pageCreate or edit one record. Long forms split into steps, not scrolled.
- DialogA short question or confirmation, always on top of the page that opened it.
- DashboardStat cards first, then charts, then the latest records.
- AuthThe only template without sidebar and top bar.
This removes the question “how should this page look?”. Add, edit and view open as form pages or dialogs, never inline.
C / Status badges
SuccessWarningDangerInfoNeutral
Used across payment lists and webhooks, so a red or green pill means the same thing on every page.
D / Components
- Inputs in every state
- Buttons: primary, secondary, ghost, danger
- Toggles
- Checkboxes
- Radios
- Tabs
- Tables with toolbar, row actions, pagination
- Dialogs
- Menus
- Date picker
- Organisation tree
Foundations: colour tokens, a type scale in Inter, one icon set, one scale for space and shape, and effect styles for cards, menus, dialogs and focus.
E / How developers receive itRules instead of pictures
1Figma file
Every page, built on the system.
2PDF documentation
Tokens, components, templates, written rules, a changelog in five phases and a list of known gaps with next steps.
3Figma library
Components live in the Assets panel, so designers pull them instead of copying screens.
Rules written downNaming conventions, do and don’t examples, and one documented exception: chart series may use colours outside the status tokens.
F / From the Figma fileReal pages from the system
08 / One system, two dashboards
The Client dashboard runs on the same parts.
The Merchant and Client dashboards share the same foundations and the same template names, so a developer who builds a list page once can build it again.
The Client dashboard is a bulk-messaging platform with SMS, email and push, templates, contacts, an organisation hierarchy, quota and request approval. It has its own parts, such as messaging and contact patterns, built from the same tokens.
09 / Outcome
From screens drawn one by one to one system the team builds on.
Before, every page was drawn on its own, so the sidebar, tables and forms looked alike but were not the same thing, and developers guessed at handoff. Now the Merchant and Client dashboards are built from one design system. The whole team works from it, whatever has been developed so far uses it, and developers get rules instead of pictures. Logibiz asked me back for this, and I work with its developers and a second designer in one shared library.
Redesign built, early Oct 2026about 30 to 40%
Reported by the technical support manager
Approximate figures as relayed to me, not measured by me. The figures in the Figma file are sample data.
- Merchant and first terminal set up: about 9 minutes before, about 4 min 17 sec now.
- Failed or abandoned Enter Transaction forms: about 1 in 9 before, about 1 in 20 now.
- A developer building a new list page: about 2 days before, about half a day now.
- Still to track: support questions about permissions and access.
- Still to track: how many new pages are built without a new custom component.
10 / What I would do next
Three things I would fix next.
In October 2026 I reviewed the dashboard against public documentation and standards. This is a review after the fact, not research behind the original design.
11 / What I learned
A design system is mostly decisions written down. The templates did more for consistency than the components, because they stopped people debating layout.
- Role
- Product designer on a freelance retainer
- Client
- Logibiz Technologies, London
- Dates
- May 2022 to Nov 2025, then 1 July 2026 to present
- Worked with
- Logibiz’s developers and a second designer
- Status
- Live. The redesign is in development.