Rock Gomes

Financial Back-office

Bigbank · 2018 · internal tool

Bigbank's accountants used a generic third-party tool that was slow and hard to use. The goal was to build a Financial Back-office in-house and replace it. I studied the old system and designed the new one together with the accountants who use it.

role
Product Designer at Bigbank. I also designed the Baltic loan applications, their back-offices and partner systems.
context
Bigbank, a bank specialised in loans in several European countries, mainly Nordic and Baltic. The users were the bank's own accountants.
made
The screens of the new Financial Back-office: lookup values, transactions, incoming invoices and cost reports.
tools
Figma, InVision

problem

The accountants used a generic third-party tool. It had many features they did not use, and that made it slow and hard to use. They needed a system made for their work.

decision

Build it in-house. Design it with the accountants: talk to them often and get their feedback on new ideas early.

result

The new system went live. It shows the accountants the data they need, the way they want it.

Screens of the Financial Back-office at an angle on orange and yellow bands: Lookup values with and without the search panel, an invoice, a cost report and the Transactions table.
Screens of the Financial Back-office: lookup values, an invoice, a cost report and transactions.

What I made

the main screens

lists

Every list works the same way

Lookup values, transactions and the other lists share one layout. Active filters show as chips above the table. Page actions are top right, row actions are on the selected row, and page numbers are at the bottom.

The Lookup values screen: filter chips above a long table, Add, Export to CSV, More actions and Search buttons top right, view, edit and delete icons on one row, and page numbers at the bottom.

search

Search opens beside the table

The search button opens a panel on the right. The accountants wanted to see all the data at once, so the panel never covers the table.

The Lookup values table with a search panel open on the right: lookup code, code, name, additional info, valid, and a green Search button.
Search open: the fields are next to the table.

forms

Long documents in clear groups

A cost report or an invoice has many fields. Each document is split into labelled groups. The totals and the main actions are always visible.

A cost report in three groups: Personal info, Use of personal car, and Costs, with editable rows, an Upload document button on each row, totals, and a bar at the bottom with the amounts to pay.
A cost report: three groups, a document upload on each cost row, totals at the bottom.

transactions

Many transactions on one screen

The accountants wanted as many rows on screen as possible, so the rows are compact. Each transaction takes two rows: D for debit and C for credit. Light and white bands separate one transaction from the next.

The Transactions table: a two-line blue header, rows in pairs marked D (debit) and C (credit), with amounts, customer, ledger, business code, account code and balance.
Transactions: two rows per transaction, D for debit and C for credit.

How I got there

the process, short

team

Working with the accountants every week

I worked closely with developers, analysts and PMs. The users were our own accountants. We met them in person every week. They tested the new system step by step and got used to it. They also told us what should or should not be there.

  • developers
  • analysts
  • PMs
  • accountants

What changed

the outcome, and what I learned

outcome

  • The new system fully replaced the old third-party tool.

what I learned

  • People see their work in very different ways. A simpler, cleaner design can make a system worse for them.
  • The accountants did not accept my first clean designs. They wanted all the data on screen. Seeing many numbers made them trust the system.
  • I learned to understand how users think about their work before I design for them.

next case study