XactFlex

Most customers reached XactFlex from a phone. Every flow was designed for one thumb and a vertical scroll, then adapted for desktop, never the other way around.

Every tick of the draw slider recomputes the cash advance fee, the repayment plan, and the first payment date. The budget was 60 milliseconds per tick. Slower than that, the numbers lag the thumb and the customer stops trusting them.

The payment flow had to complete as a plain form submission if JavaScript failed or a screen reader was driving. Progressive enhancement on the one step that moves money.

Cash advance fee, APR, repayment terms. These are regulatory disclosures, and they had to be visible during the decision, not in a Terms modal after it. Compliance reviewed the inline placement.

The launch surfaces and the later payment surface had to read as one app, not two flows stapled together. Same palette, same density, same primitive interactions.

On the draw surface the slider is the input. Under it, a small table updates in place: cash advance fee, repayment plan, first payment date, total cost. The customer reads the consequence of the amount before committing to it. There is no type-a-number-then-discover-the-cost step, because the cost is on screen the whole time.

Both tracks compress to three surfaces. Draw: Account, a read-only summary with a utilization donut; Draw, the slider with its live table and inline disclosures; Review, the commit. Payment: Method, Type, Date, then Review. One question per surface. The legacy payment wizard asked all of them at once.

Both flows end on a review screen that looks different from everything before it: different ground, larger type, the amount restated. Committing takes two deliberate actions, Authorize and then Submit. It read as redundant in design review. The drop in payment-status calls is the argument for it: two taps when real money is moving is cheap insurance.

The payment Type step leads with Minimum, Payment Plus, and Pay-off as one-tap choices, with the numeric field below for anyone who needs a specific figure. The custom field stays in place as the fallback, not the front door.

Other-amount payments do not apply toward the next scheduled payment, which is exactly the kind of distinction that generates a support call after the fact. The Other path carries an inline note saying so, where the customer is already reading, before they can submit and be surprised.

A thin persistent banner at the top of each flow shows 1 of 3, 2 of 3, 3 of 3, and tapping a step walks back without losing state. It got a name and a spec, and it ships on both the draw and the payment flows.

Defined what the slider reads, what the table renders, and what the review restates before drawing anything. A revolving line of credit reduces to a balance, a limit, and the option to draw. Pinning that made the UI tractable.

Built the slider behavior in Adobe XD with snapping increments and tuned the step until it matched the product's price points. Engineering took the spec, including the 60 millisecond recompute budget, into the build.

Walked the inline placement through compliance. It held because the disclosures are continuously visible during the decision rather than behind a tap. The full terms stay one expander away.

Went through the legacy flow step by step and marked where customers were dropping or calling: amount entry, date selection, and an unlabeled “apply to” choice. Each had to land somewhere in the new flow or be cut on purpose.

Took the slider-and-table pattern, the three-surface compression, and the two-action commit from the draw flow into the payment redesign. The surfaces read as one product because they are built from the same primitives.