Case Study — GPB · Finance system
GPB is the finance system of a Brazilian business group, replacing an old MS Access setup. The finance staff use it every day: payables and receivables, bank reconciliation, cash flow, month-end close and taxes. I ran the UX round straight in the code. The app below is GPB itself in demo mode: click around.
This is the real app, with fictional data generated in your browser: you can post entries, settle and reconcile. Nothing leaves the page, and reloading starts over. The interface is in Portuguese, as it is for the team.
Names, amounts and accounts are made up.
Screens
01 — The problem
The first web version rebuilt Access screen by screen: twelve loose tabs in a strip that scrolled sideways, a column locked at 672 px even on a large monitor, and every form sliding up from the bottom, on desktop too. No screen said what needed attention today.
The people using it work in finance, not tech, posting and reconciling all day. Entries opened on "everything", with thousands of items inherited from Access (some open since 2015). The rule for the round: usability over flourish, and every change is measured in clicks and doubts for the day’s task.
To open Entries, downloading everything again on every tab switch. Now it loads once and the other screens use it right away.
02 — Before and after
The same fictional data in both versions. What changes is the order: first what needs action, then the rest.
01 — On desktop
What improves: The whole screen at work
The menu moved to the side and is grouped by task: Overview, Day to day, Month-end close and Settings. Payables opens on "Pay now", with the total, overdue and next 7 days above the list, and a notice about old items with a button to review them one by one.
Visibility of system status
People see what is going on before they have to ask.
02 — On the phone
What improves: Feels like an app
The sideways tabs became a ☰ menu: the daily routine as cards, month-end and settings as a list. Forms and alerts open as bottom sheets or full screen, never in a cramped modal.
Is the recommended minimum touch target. On GPB, every target on the phone is at least that.
03 — Decisions
The right tool for each task: a wizard for work with a start, an end and several decisions in order; a checklist for a cycle that spans several screens; triage for a queue of similar items; and a quick form for what people do with their eyes closed.
Error prevention
Better than a good error message is a design that keeps the error from happening.
04 — On the phone
A round just for responsive: modals became bottom sheets or full screens, the ☰ opens the routine as cards, and a phone kit went into every screen (a numbers strip, lists grouped by day, a fixed action bar and the + button). From 360 to 1440 px, none of the 13 screens scrolls sideways.
Jakob’s law
People expect a system to work like the apps they already use every day.
The routine
Sheets and wizards
Delivery · Design engineering
No Figma in between. I read the 13 screens in the code, wrote the analysis, and each decision went straight into the product’s React, on a branch, in commits by topic, with the tests passing.
To review without touching production, the app got a demo mode with fictional in-memory data. That is what runs at the top of this page.
13screens read in the code and mapped
Each screen was tied to the Access function it replaces, with who uses it, how many clicks the daily task costs and the problems by severity. The round started from that list, not from taste.
5new pieces for the phone
KpiStrip, GroupedList, ParamSummary, BottomActionBar and Fab joined the shared kit, next to the bottom sheet, the wizard, the triage and the panel stack. Every screen uses the same pieces and behaves the same way.
0 pxof sideways scroll, 360 to 1440 px
A Playwright script walks the 13 screens at several widths and measures sideways scroll, type under 12 px and targets under 44 px. Whatever showed up became a task, until the list was empty.
77commits by topic, on a branch
Every change has a commit with the why, and the decisions that depended on the client stayed flagged in the code until they were settled, one by one. Merging is the reviewer’s call.
Outcome
Tools
I can walk you through the decisions and what is behind each screen.