Sometimes the best UX has no UI

FastPay offered a feature for clients to “automate” payments by requesting recurrent funding for outstanding invoices on the 15th and end of each month. Sadly, like many enterprise features, it was not automatic. In fact, behind the scenes, it was a time-intensive manual process.

Users would indicate in their preferences in the software which debtor accounts they would like funded, and which adtech revenue portals to use to determine the level of funding available.

Twice a month, operations staff would go through this manual process for “automatic” funding:

1. Log into the operations portal
2. Go to the downloads section
3. Download a CSV file of all clients with “automatic” funding set up
4. Open the spreadsheet
5. Go to the view on the portal to create a payment
6. Specify client
7. Enter payment date
8. Open browser
9. Go to client’s advertising revenue portal
10. Enter login credentials
11. Navigate to view that shows available revenues
12. Take a screenshot of the page
13. Navigate down several levels to the client folder on the shared Windows drive
14. Create new folder with today’s date
15. Save screenshot to drive
16. Print screenshot
17. Highlight amount payable on printed page
18. Enter new adjusted funding amount into payment view of portal
19. View past payments for the month
20. Reduce funding amount according to a various formulae calculated using a desktop calculator
21. Enter adjusted amount
22. Create dummy blank PDF invoice (the system required a PDF for funding even if one was not actually necessary)
23. Upload the dummy PDF
24. File the paper screenshot printout
25. Submit the funding request
26. Funding request is routed for approval
27. Supervisor approves funding
28. Payment is processed

I may have forgotten a few steps.

My charge was to “bring this process into the portal,” meaning each step would become a form field in a single online form.

Was that really necessary? Were all these steps really needed? After all, the CSV that was downloaded and the internal users were copying and pasting from had a wealth of data that already existed in the system. Why would we be inputting data that the system already had, just for a different use case?

Why would we require the user to input data that already exists in the system?

After consultation with various stakeholders, interviews with the internal users, discussions with the product team, and reviewing the data from the spreadsheet, I discovered that the above process could be streamlined:

1. The system creates a payment on the 15th and end of the month for each automated revenue client, logs into the ad revenue portal, takes a screenshot, and calculates the final amount according to specific formulae.
2. The payment is routed for approval.
3. Payment is processed.

As an interim solution until the automated screenshot process could be built out, the process was:

1. The system creates a payment on the 15th and end of the month for each automated revenue client with all available information except amount
2. Operations user logs into payment portal and takes screenshot of amount
3. User enters amount
4. User attached screenshot
5. System calculates all adjustments
6. Payment submitted for approval
7. Payment processed

Imagine the surprise of executive stakeholders who asked for this process to be integrated into the portal. A presentation was scheduled to show them the UI for the multi-step process. Instead, they were presented with an option that ultimately required no UI and minimal staff action.

Because the job of software is to do things that humans don’t need to do.

Image: Unsplash, Omer Rana