Transactions
The first image shows the original design. Even experienced operators complained that the information was organised illogically, the filters were awkward to use, and it was difficult to find and copy data. I completely rethought the filtering mechanism, created an interactive prototypes of 3 filter options, carried out corridor testing, and settled on what you can see in the second image.
Below is a table I compiled whilst studying the existing interface and documentation. As you can see, I still had quite a few questions at this stage, and the answers to them helped to identify weaknesses in the organisation and storage of information.
| Data type | All | Payments | Card transactions | Questions |
|---|---|---|---|---|
| 24 or 36 chars | Transaction ID | BaaS UUID | BaaS UUID | Are Transaction ID and BaaS UUID two different names for the same thing? |
| Is All simply Payments and Card transactions taken together? | ||||
| 36 chars | CBS Consent ID | In Payment editing it is called CBS Trx ID – better to use one name | ||
| 11-36 chars | SV transaction ID | What does SV stand for? | ||
| 12 chars | SV card ID | |||
| Transaction Type | Type | Type | Are Transaction Type and Type two different names for the same thing? | |
| Transfer | Transfer | PIN changed | Where can I see the full list of types? | |
| Funding | Funding | Electronic operation | Where can I see the full list of categories for Card transactions? (Category: purchase SV Code: 668) | |
| Exchange | Exchange | POS operation | ||
| Empty | Invoice | Manual purchase | Why can a cell be empty in the All interface? | |
| CBS Type | Core Banking Solution? | |||
| Domestic | ||||
| Incoming | ||||
| International | ||||
| Exchange | Is the value Exchange always set when Type is Exchange too? | |||
| Amount | Amount | Amount | ||
| Fee amount | Fee amount | Account amount | In All the field is sometimes empty. How should it be read? In Card it has another name | |
| Cleaning amount | What does an empty cell mean? | |||
| Currency | Currency | Currency | ||
| Exchange rate | ||||
| 21-28 chars | Account from | Account from | ||
| 21-28 chars | Account to | Account to | ||
| 36 chars | Card UUID | Is Card UUID similar in meaning to Account from? | ||
| 10-14 chars | RRN | What does this stand for? | ||
| Is relevant? | Relevant to what? The wording is unclear | |||
| false | ||||
| true | ||||
| Status | Status | Status | Status sits nearer the start in Card transactions, but nearer the end in All and Payments – does that make sense? | |
| Success | Register | Transaction completed | Aren’t Success and Register the same thing? | |
| Processing | Processing | Incorrect CVV2/CVC2 | ||
| Pending | Pending | Transaction declined | What categories are there? (Category: decline SV Code: 802) | |
| Booked | Booked | What is SV Code? | ||
| Rejected | Where can I see the full list of statuses for Card transactions? | |||
| Canceled | ||||
| Failed | ||||
| Draft | ||||
| Financial Status | The Card transactions filter has Financial Statuses, but no Status | |||
| Unknown | ||||
| On hold | ||||
| Cleared | ||||
| Unhold | ||||
| In progress | ||||
| Reversed | ||||
| Processed | ||||
| Declined | ||||
| Partial reversed | ||||
| Partial cleared | ||||
| Non financial | There is a Show only financial transactions filter – does it count Unknown? | |||
| Priority | Priority | Do Card transactions have no priority or its equivalent? | ||
| Express | Express | |||
| Empty | Empty | The filter settings say Standard – is that the same as an empty cell? | ||
| Payment standard | Payment standard | Payment standard | In Payment editing it is called Trx Payment Standard – better to use one name | |
| Internal | Internal | Internal | ||
| SWIFT | SWIFT | SWIFT | ||
| SEPA | SEPA | SEPA | ||
| Target | Target | |||
| Target/SEPA | Target/SEPA | How does it differ from Target and SEPA? | ||
| Sepa_ | Sepa_ | How does it differ from SEPA? | ||
| CORRESPONDENT_ | CORRESPONDENT_ | Looks like a variable name | ||
| Clearing | Clearing | |||
| Spei | Spei | |||
| Created at | SV date time | Card transactions use two date formats: 2024-04-01 09:38:04 and 2024-03-05T06:20:50Z | ||
| Partner | Partner | Present in the filters. Which table field does it relate to? | ||
| Account UUIDs | Present in the filters. Which table field does it relate to? | |||
| Account types | Present in the filters. Which table field does it relate to? | |||
| Card account | ||||
| Current account | ||||
| Master account | ||||
| Corporate account | ||||
| Common account (Card+Current) |
Partners list
The first image shows the original design. Even on a wide screen, the Partners table did not fit across the width. It was unclear which sub-section of Partners the operator was currently in. To change the status, you need to click on the eye icon, which might not even fit on the screen. I analysed and documented the project’s information architecture and identified ways to optimise it (for example, the ‘PCI DSS Compliant’ and ‘PCI DSS Type’ columns could be merged). Whilst analysing the information architecture, I had some questions for the analyst, and this helped us to identify errors present in both the database and the interface. I also conducted a user survey to find out how they use IDs – it turned out there is no point in displaying them in separate columns, because nobody ever sorts the table by the values in those columns. You can see the result of my interface optimisation in the second image.
Partner’s details
The Partner details were the most confusing part of the interface. The controls didn’t even fit on the screen. I had to get to grips with all the finer details and completely reorganise the information. In situations like this, if designers aren’t sure what to do, they use the ‘card sorting’ testing technique, asking users to group pieces of information into meaningful categories. But in this case, users were glad to hear the designer’s suggestion – it was that difficult for them to get to grips with the subject. Fortunately, science has answers to most questions, and, drawing on design theory, I carried out the work, the result of which satisfied everyone.
You may have noticed that the height of the input fields and drop-down lists varies. This is because the screen was built using the old UI Kit. A universal design system was subsequently developed, which resolved all consistency issues.
