Bancor Business Cards · Santiago Castillo

15,000businesses managing employee card extensions

7 → 3screens in the core flow

7 → 1screens to download a statement

What changed

Bancor's corporate card section was built as a sequence: seven screens, each one gating the next, ending in the single action anyone had come to perform. Analytics said the sequence was solving the wrong problem. Almost nobody was there to transact.

I rebuilt it as a dashboard with the critical figures on the first screen, moved statement downloads into a drawer that opens where the user already is, and brought statement payment into the cards module instead of sending people to a separate feature to finish the job.

Sole designer on this flow, working with functional analysts, product owners and the development teams. Roles and permissions themselves are a shared platform system I worked on with two other designers.

The problem

Seven screens to download one PDF

Bancor Empresas serves around 15,000 businesses that issue card extensions to their employees, between 2 and 75 per company. Administrators monitor spending, download monthly statements and track limits across ARS and USD. Before interviewing anyone, I walked the existing flow myself and documented every screen.

7screens to download one PDF

The single action anyone actually needed sat at the very end of a long flow, and the financial figures they came to read sat several screens deep.

1Products
2Account list
3Account detail
4Card list
5Card detail
6Recent statements
7Periods
8Download the statement

The legacy flow, redrawn from the original user flow. Seven screens gate the one action anyone came to perform.

Unclear entry point

It was ambiguous whether the section led to account detail or to the card list. People guessed, clicked, and backtracked.

The one action came last

Downloading a statement appeared on screen seven. Anyone who only wanted a PDF passed through six screens they had no use for.

Critical figures buried

Total spending in ARS and USD, and available limits, were not visible up front. Users drilled down several levels for numbers they needed at a glance.

Payment lived elsewhere

Paying a statement meant leaving the cards module, finding a separate payments feature, and re-entering the account details from memory.

98%of interactions: viewing information

2%of interactions: taking an action

Consultative · scanning numbersTransactional · one action

The old architecture treated every step as equally important, which buried both the information and the action under navigation nobody had asked for. That imbalance became the brief.

The flow does not have one ending

Bancor Empresas has three roles. Administrators see and sign everything, and decide what everyone else can do. Consultants can look and nothing else, so the pay action is not rendered for them at all. Operators are where the complexity lives: an administrator sets independently whether they can sign, which functionalities they can enter, and how much they are allowed to transact.

Two people with the same job title at the same company can reach different endings on the same screen, and neither of them chose that. I could not enumerate the operators. I could only design a flow that ends correctly for any of them.

Operator

Select card→ Enter amount→ Confirm→ Pending signature→ Notified on each signature

Signatory

Email per pending signature→Counted card on the home→ Review→ Sign→ Executed

The task changes hands at pending signature. The two people are never on the same screen, and often not in the same session, so email carries the handover in both directions: one per pending signature going out, one per completed signature coming back.

The old flow reported success to everyone. The redesigned one ends on the state that actually happened, and when signatures are missing the last screen says so. Its job is not to apologise for an unfinished task. It is to hand the task over.

Where the operator can see what happened

Before the redesign, someone who submitted a payment had nowhere to check on it. I built the payment history inside the cards flow so the person who started the task could follow it without asking anyone.

Realizada · completed No realizada · did not go through Pendiente de firma · waiting on signatures

Three states, deliberately kept apart. Pending signature and did-not-go-through both mean no money moved, but one needs somebody else to act and the other needs you to act again. Collapsing them would make an operator conclude their payment failed and start a second one.

Where the queue actually lives

A card payment waiting on signatures does not get its own queue. It joins the platform-wide authorisation list, alongside payroll runs, supplier payments, transfers and cheques. Pending balances are split by currency rather than merged, and the running total updates while the signatory selects, not after they commit. This queue is shared platform surface, not part of the cards flow I owned.

Most companies never see any of this

Most businesses here are small. In a single-person company the owner is administrator, operator and signatory at once, and the whole authorisation apparatus is weight they will never carry. At the other end are the municipalities, where dozens of people work under separated duties and the authorisation queue is the product.

The same interface serves both with no configuration in between, because the signature path appears only when it applies. No banner warning that it might happen, no setting to switch on.

Payment history with the three states — Payment history inside the cards flow. Completed, not completed, and pending signature, kept apart.

Platform authorisation queue — Where the task lands for the signatory. The running total is visible while the selection is being made, not after.

Platform home with the counted pending authorisations card — The platform home. The pending authorisations card carries a count, not just a flag, so the signatory knows the size of the job before opening it.

Three rules I held to

1

Surface critical data immediately

Total spending in ARS and USD, and available limits, are visible without any navigation. If a number is the reason someone opened the section, it does not get a screen of its own.

2

Make the primary action instant

Downloading a statement should not require navigating seven screens. It should be one click from wherever the user already is.

3

Respect the 98% case

Most interactions are consultative. The architecture optimises for scanning, and depth exists one layer down for the minority who need it.

The redesign

From seven screens to three

A dashboard-first architecture that puts the numbers up front, the download one click away, and detail behind progressive disclosure.

1 · Dashboard→ 2 · Employee detail→ 3 · Transaction detail

Metrics up top, the employee list as drill-down instead of a wall of table.

Four decisions

Decision 01

Dashboard-first approach

Before

Navigate through multiple screens to find aggregated spending and limits.

What I did

Screen one became a dashboard, grouped by card product. Each product shows its account, total ARS and USD spending, and available limits, with the two onward paths sitting beside the figures rather than behind a menu.

How I validated it

I asked administrators what they needed to see first. The answer was unanimous, so totals and limits now own the top of screen one.

Metrics up top, employee list as drill-down.

Decision 02

A drawer for statement downloads

Before

Navigate to screen seven, find the download option, select a month, download.

What I did

A download button on screen one opens a drawer with the last twelve months. Users select and download without ever leaving the landing screen.

Why a drawer, not a screen

Analysts confirmed downloads were the most frequent action and account executives stressed speed. A drawer gives immediate availability while keeping focus on the dashboard.

Statements drawer open over the dashboard, twelve months listed

Twelve months, one click from the landing screen.

Decision 03

Progressive disclosure for detail

The principle

Depth stays available but never in the way. Each level reveals only what the previous one implied, which is what let seven screens collapse into three without losing anything.

1Dashboard. Aggregated figures and the employee list.

2Employee detail. Card number, spending, limits.

3Transaction detail. Recent activity, authorisations, instalments.

Card list, level two of the disclosure — Level two. The card list with per-employee spending in both currencies, searchable by name.

Card detail, level three of the disclosure — Level three. Limits, movements, authorisations and instalments, each in its own collapsed section.

Decision 04

Paying without leaving the module

The decision

Bring statement payment into the cards flow instead of sending administrators to a separate feature to finish the job.

How I approached it

A pay action sits on each card account header, beside the statement and the card list entries. Consulting the data, downloading the statement and paying now live on one surface.

Why it mattered

Payment previously meant abandoning cards, finding the payments feature and re-entering account details from memory. That hand-off was the single largest source of drop-off in the task: a break in context, not a missing capability.

View, download, pay. One flow, one context.

Pay the statement in the same flow

The first question is not how much, it is which balance. A corporate card here carries ARS and USD spending at once, so the flow opens by asking what part of the statement you are settling. Everything after that is phrased in the currency you chose.

Choosing which balance to settle — **Which balance.** Pesos, dollars, or both, each with its amount already shown.

Amount options with the debit account selector — **How much.** Outstanding balance or a custom amount, with the debit account and its balance in view.

Custom amount entered — **Custom amount.** The field only appears once it is the chosen option.

Confirmation screen — **Confirm.** One review screen, nothing editable, fast to read.

Request created, pending signature — **Handed over.** When signatures are missing, the result screen says so instead of reporting success.

Receipt carrying the pending signature state — **The receipt carries the state.** Same document, reporting what actually happened rather than asserting success.

Users scanned the table but did not engage with it. They looked past it, to the empty space at the top.

Cognitive walkthrough, first version of screen one

Step 1Audit

Before interviewing anyone, I walked the legacy flow myself and documented every screen and every point of confusion.

Step 2Interviews

Four business administrators, three account executives and one session with business banking leadership.

Step 3Walkthroughs

Three cognitive walkthroughs on the redesign, with the administrators who use the section weekly.

The iteration that reshaped screen one

Initial design: Screen one showed all employee data in a traditional table: name, card number, ARS and USD spending.
Observation: Users scanned but did not engage. They looked for summary numbers at the top and did not find them.
Realisation: Tables compare items well, but a consultative flow needs high-level figures first.
Final design: Screen one became a dashboard. Metrics up top, a simplified employee list below for drill-down.

What I decided not to build

Two decisions where the interesting part is not the design. It is what I chose to give up, and why.

Twelve statements, not the full archive

The service that retrieves statements bills per request. An unlimited archive meant paying for depth close to nobody used.

The honest caveat: that demand was measured on a system where statements sat seven screens deep and only 14% of administrators ever downloaded one. Now that the last year is one click away, requests for older periods are worth watching. If they climb, twelve is the wrong number and the decision gets revisited.

Not building a notification I could not honour

The obvious idea was a badge on the cards section counting payments waiting on a signature. I dropped it. Signature state is owned by the platform authorisation service, not by the cards module, and mirroring it locally means two sources of truth for the same fact. A counter that lags by a few minutes on a payment worth millions is worse than no counter.

The circuit is already instrumented on both ends: the signatory gets an email per transaction awaiting them plus a counted card on the platform home, and the operator gets one per signature completed. The cards module points at that, instead of competing with it.

The outcome

What shipped, and what I would not claim

+8%more statements paid on time, one month after launch

Paying a statement used to mean leaving the cards module and locating the payments feature somewhere else on the platform. Many administrators never found it. They learned about the balance when their account executive called, or when a home screen notice told them the statement had already expired. The architecture had handed a product responsibility to human agents.

What that number cannot carry. One month is a single billing cycle, and a single cycle is not a trend. The measurement window overlaps a commercial campaign, so I do not attribute the change to the redesign. It is reported, not claimed.

On the account executives. The goal was never to remove them. Businesses on this platform value that relationship and say so in interviews. What the redesign removed were the navigation calls, so the contact that remains is the one clients actually want.

Bancor Business Cards. From seven screens to three.