B4

B4 was Ratiodata’s internal platform for departmental budgeting, forecasting and plan-versus-actual comparison. It replaced a patchwork of Excel files that made budgeting slow and hard to trust.

The catch: the planners who had to adopt it liked Excel. They had years of muscle memory in it and full control over their own files. My job was to design something they would choose over a tool they already trusted.

Budgets lived in scattered Excel files with no shared structure and no single source of truth. Consolidating across departments was manual and slow. Numbers disagreed between planners, controllers and leadership. Errors surfaced late in the budget cycle, and mismatched budgets contributed to avoidable financial losses every year.

Sole UX and product designer on B4, owning the experience end to end for a small, senior user base. I structured the core planning flows (create, edit, review, delete) inside a compliance-heavy, SAP-integrated system, then designed and moderated two rounds of in-person usability testing with real finance planners across business units.

I used SUS and task-completion scoring to turn “people don’t like it” into a ranked list of specific interface problems, and turned session notes and quotes into concrete redesigns of the core interaction model. Part of the job was pushing back on stakeholders who wanted Excel-parity features that would have weakened accuracy and the audit trail.

A small cross-functional squad: me on design, a product owner and business analyst, backend and SAP integration engineers, and a controller-turned-product-owner. End users were roughly 30 to 35 finance planners, department heads, controllers and executives.

The constraints shaped everything. SAP and ERP integration meant data structures and terminology arrived inherited, including terms like Innenauftrag and Kostenart. Compliance and audit-trail requirements applied to every edit. The IT environment was legacy and inflexible. And the user base was small, senior and vocal, so any friction was noticed and escalated immediately.

Six core tasks per session, tested in person across business lines: create a plan, extend a multi-year contract, edit values, check history, delete an item. Participants had mixed technical comfort. Scoring combined SUS with task completion.

This came up session after session, unprompted, which is why it went to the top of the redesign list rather than into a backlog.

The vocabulary worked against users too. SAP and controlling terms assumed domain knowledge that not every planner had. Field-level confusion was just as costly: several users didn’t know which fields were required, some guessed based on asterisks, and one planner typed their own name into a “Name” field meant to record the customer, because the label didn’t distinguish “your name” from “customer name.”

The cost-center hierarchy nested seven levels deep, mirroring the organisation’s real structure. A breadcrumb reading SDS > 350100 > 000 > 765 > 500 > 420 > 500404 shows the actual depth planners navigated to reach one planning item. Once inside a leaf node there was no reliable way back to a newly created sibling.

The System Usability Scale is a validated 0 to 100 benchmark used across the industry, not a number invented for this project. A score of 59.7 sits in the “OK” band: usable, but well short of “Good,” which starts at 68.

Combined with a 29% task failure rate, this told us the problems were structural rather than cosmetic, and justified redesigning core interaction models instead of making surface-level tweaks. It also gave stakeholders a defensible number to sign off against.

Every fix below touched the core interaction model. None of them were polish.

A teal outline and label mark the field being edited, so the edit state is visible at a glance, and small arrows on adjacent cells show which values changed and in which direction. This detail work is what made it possible to keep a dedicated edit view without losing the safety planners asked for.

At the year level, an Income, Cost and Profit margin rollup replaced the scattered per-department Excel totals. Controllers get a defensible, auditable number before they drill into detail.

Same six-task protocol, re-run with a comparable group of planners after implementing the redesign.

For planners, task abandonment dropped from 29% to 3%. Save state became explicit, so nobody had to guess whether an edit went through. Newly created items could be found again without moderator help, and the dedicated edit view stayed available alongside inline editing for the power users who wanted speed.

For the organisation, reported adoption went from roughly 30% to roughly 90% of the 30 to 35 person user base. Mismatched budgets had caused avoidable losses every year; with one auditable source of truth replacing scattered Excel files, that stopped. Planners, controllers and leadership finally worked from the same numbers, with a visible change history behind every value, and budget consolidation across departments got faster and cheaper.

Evidence-driven design. Raw usability sessions became a prioritised, defensible redesign, and that evidence is what let me hold the line when stakeholders pushed for different tradeoffs.

Designing for trust, not just efficiency. The biggest wins came from making state visible (saved or unsaved, changed or unchanged), not from making anything faster.

Working inside real constraints. SAP integration, compliance requirements, legacy systems, and senior users with strong habits.

Closing the loop. The project didn’t stop at shipping the redesign. A second measurement round proved the changes worked.

Note: any visual representation of B4 uses mock data, and participant names, where mentioned, are not their real ones. Some details were generalised for confidentiality.