Getting four surfaces to mean the same thing by “available.”

Form at Oakline Business Banking.

Form was the cash-planning workspace inside Oakline Business Banking. I began with the overview and stayed through a shared-interface programme covering banking, invoices, commitments, and forecasts. The most consequential design decisions were often about a label, a decimal, or what happened when a value was missing.

Three products disagreed about the same money.

The banking view showed the account balance. The planning view called its estimate “Available.” The invoice view included expected payments in a similar-looking total. Business owners reasonably assumed the same visual treatment meant the same kind of money.

Sixteen interviews and nine observed planning workflows showed people subtracting rent, payroll, and tax in a spreadsheet before trusting any headline number. Forty-two support conversations made the language mismatch visible across products.

The implementation mirrored the product split. Squads maintained their own amount inputs, badges, and table rows. A fix to keyboard focus in planning did not reach invoices. A new library had to reduce that drift without becoming a year-long rewrite.

Start with the amounts, then draw the components.

Claire and I wrote a definition sheet before a component inventory: account balance, confirmed commitment, expected income, manual amount, and available after commitments. We named the data source, date, precision, and missing-value behavior for each one. That sheet resolved more disagreements than the initial dashboard concepts.

I designed the planning surface and worked with Ben on the corresponding components. We used tabular numerals, aligned amounts by decimal position, reserved fixed space for negative signs, and kept source labels in text. Red was never the only way to identify an overdue item.

Eva brought the invoice workflow into review and exposed a weakness in our compact table. The target for opening a row was too small when every field became a link. We kept rows dense for scanning but gave the primary action its own focusable control.

We migrated incrementally: planning first, commitment forms next, then invoice lists and the banking summary. Each adoption included keyboard and zoom review. Old components stayed until their last production use was removed, with an owner and a retirement date.

A financial interface with its assumptions exposed.

Review the keyboard path, not only the screenshot.

Twelve business owners completed planning tasks in the first product study. Later library reviews used representative flows from all four surfaces with keyboard navigation, 200% zoom, missing data, long labels, and validation errors. Component adoption and product usefulness were tracked separately.

The useful outcome was a smaller maintenance burden.

Adoption and maintenance, not financial performance.