Case study · 04 / 07 · 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 transactionsNo lift claimed

At a glance

  1. The problem

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

  2. What I did

    Argued for the research and tested a stepped modal against the long form with eight people. 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. These are throughput numbers. There was no measured before-state and no control, so none of it is lift.

01Scope

  • Fees collected through the flow

    Throughput

    A new capability with no baseline to beat. The $1.4M moved through a flow I designed. It is not money the design created.

  • 13

    design iterations, give or take

  • 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's Add Fee form had no way to automate one, so people were doing it by hand. Manual workarounds led to errors and support tickets.

The form had no hierarchy, fields piled in one after another as different people asked for them. Veterans tolerated it, newcomers got it wrong, and it had to work for both. The business case was smoother payment operations with no loss of 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.

04The goal

How might we make adding a fee easier?

Copy that read as adviceA disclaimer that clarifies

Simplify the language and add an inline disclaimer that clarifies and does not advise. It stayed inside compliance.

One dense formA stepped modal

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

New tooling for one modalThe patterns the team knew

Work inside Bootstrap and the native form patterns instead of handing the team new tooling. Keep the usability gain.

Mistakes caught on the invoiceMistakes caught in the preview

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

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 aim was to challenge the default without alienating the people attached to it, so stakeholders saw previews and walkthroughs early.

Eight participants in two groups, one group per build, matched as evenly as I could with a first-time user in each, so nobody used both and order did not need balancing. Each rated their build per task on a five-point scale and gave open-ended feedback. The test was checking whether the tasks weighed the way we assumed, on a feature so ingrained in how a shop builds an invoice that clarity mattered more than polish.

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 gap is in setup, first time through, when nobody knows what the fields mean yet. Progressive disclosure is for that moment. Alpha shipped.

Editing was the task the shops already did every day in a very full program, so both builds had to be at least that clear, and they were. The means are exact arithmetic on four ratings each, so the third decimal in the table carries nothing.

That was not a foregone conclusion. Stakeholders were still uneasy about moving to a new pattern well into the final presentation. The scores moved the stakeholders where the mockups had not.

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, shown and not enforced.

06What I dropped

  • A hard block on the fee rate above the processor's ceilingA hard block on the rate would be a legal position. Rate caps differ by processor and by jurisdiction and they change, and enforcing one means giving tailored advice to every locality. The ceiling is shown and not enforced, and a shop that sets a rate above it carries that itself.
  • Bravo, the long-form modal, the way the team already workedit tied on editing and lost on setup.

07The impact

ImpactEvery figure with what it is not
Transactions processed through the flow47,517up
Fees collected through it$1.4MupRoughly $30 per transaction.
Shops using the feature412upAcross 298 entities, out of a few thousand shops on the product.
Overclaims$0.00

Corrections & caveats

Variables
Automation was a new capability, so there is no earlier automated flow to compare against: the design is the whole change.
Cohort
Post-launch usage, measured on the shipped feature and reported at a company all-hands. The period the figures cover I do not have any more.
Confidence
High on adoption, and silent on lift. These are throughput numbers, with no baseline I could have beaten and no conversion improvement to claim.
Not measured
  • No before-state for automation to compare against, because fees were added by hand before it
  • How much of the adoption is the design versus 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, and it is still how decisions get made there, from what the PMs I keep in touch with tell me.

08What I would measure next

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