Case study · 02 / 04 · 20254 min read
  • Conversion
  • Research
  • A/B testing

Add a Fee

Should you change a workflow everyone has already adopted, for the better?

Where
Fullbay. Automated credit card fees across the payments workflow.
Role
Sole designer. Research, A/B design, usability testing, stakeholder case
Alpha, the winning multi-step fee modal, beside its usability scores.
47,517 transactionsThroughput, not lift

At a glance

  1. The problem

    Adding an automated card fee was a dense one-page form that veterans tolerated and newcomers got wrong, and the company had never run a usability test to prove either.

  2. What I did

    Argued for the research, tested a stepped modal against the long form with eight people, and shipped the stepped one inside the Bootstrap patterns the team already knew.

  3. What happened

    47,517 transactions and $1.4M in fees through the shipped flow. Throughput, not lift: there was no before-state and no control.

01Scope

  • 13+

    design iterations

  • 2

    versions tested head to head

  • 412

    shops using it

02The problem

Shops wanted to automate credit card fees. A flat amount or a percentage, applied per shop or per customer. Fullbay had no native support, so people were doing it by hand. Manual workarounds meant errors, and errors meant support tickets.

It had to work for veterans and newcomers alike, and it could not sit behind a paywall. The business case was straightforward: smoother payment operations without losing compliance or trust.

03The two real constraints

  1. 01The dev team had little experience beyond Bootstrap, so the UI had to stay technically simple and cheap to implement.
  2. 02Formal user testing did not exist at Fullbay yet. I had to argue for the research before I could run it, so stakeholder education was part of the design problem, not a side quest.

04The goal

How might we make adding a fee easier and more intuitive?

ConfusingClear

Simplify the language and add an inline disclaimer, not to advise but to clarify. Confidence up, still inside compliance boundaries.

OverwhelmingStepped

Move from a dense one-page form to a stepped modal, so the load is progressive and setup finishes without errors.

Legacy UIModernized

Work inside Bootstrap and native form patterns rather than handing the team tooling they had not used, without giving up the usability gain.

PassiveIn control

Flat or percentage, by shop, by entity, each choice labelled, with a preview summary before confirmation so mistakes get caught before they are made.

05The test

Two builds, tested head to head. Alpha was a multi-step modal with progressive disclosure. Bravo was a traditional long-form modal, consistent with the UI Fullbay already had. The point was to challenge the default without alienating the people attached to it, so stakeholders saw previews and walkthroughs early rather than a verdict at the end.

Eight participants rated each version per task on a five-point scale and gave open-ended feedback. Enough to quantify the preference while still surfacing where people got stuck.

Alpha and Bravo, rated per task on a five-point scalen = 8

Alpha: the Add New Automated Fee modal broken into Basics, Automation, Settings and Summary steps.
Alpha, the multi-step modal that shipped.

Both scored identically on editing an existing fee. The whole gap is in setup. First time through, when nobody knows what the fields mean yet. That is the moment progressive disclosure is for, and it is why Alpha shipped.

That was not a foregone conclusion. Stakeholders were still uneasy about moving to a new pattern well into the final presentation. The scores are what moved them, not the mockups.

The Settings step of the Add New Automated Fee modal: Rate and Per Item Fee fields, each with a Recommended ceiling printed under it, 3 percent and 30 cents.
The inline disclaimer, on the Settings step. A recommended ceiling under each rate field: the number the processor allows, stated, not enforced.

06What I dropped

  • Bravo, the long-form modal: everything on one surface, fewer clicks, every decision visible at onceit tied Alpha on editing and lost on setup, and setup is the moment that matters, first time through. The safer thing to ship, and it lost fair.

07The impact

ImpactEvery figure with what it is not
Transactions processed through the flow47,517
Fees collected through it$1.4MRoughly $30 per transaction.
Shops using the feature412Across 298 entities.
Overclaims$0.00

Corrections & caveats

Variables
Design was the only thing that changed.
Cohort
Post-launch usage, measured on the shipped feature.
Confidence
High on adoption, and deliberately silent on lift. These are throughput numbers, not a conversion improvement. The capability did not exist before, so there is no baseline I could have beaten. The $1.4M is money that moved through a flow I designed, not money the design created, and presenting it as the latter would be dishonest.
Not measured
  • No before-state to compare against, because there was no before
  • How much of the adoption is the design versus simply the feature existing
  • Whether support tickets about manual fee workarounds actually fell. I never got that number

The result I am most pleased with is not on that list. This project introduced the company's first formal user testing process, and the stakeholders most resistant to the wizard became its advocates once they watched people use both versions. That changed how the next decision got made, which outlasts the feature.

08What I would measure next

  • Support ticketsmanual fee workaroundsThe number that says whether the flow removed the problem or moved it. I never got it.
  • Before-statea week of the old formUnder the same instrumentation, before the new one ships. Next time.