Designing an invoice correction tool free of human error and audit risk
September 2021 - January 2022
Freenow is a ride-hailing and multi-mobility app in 9 european countries. This project was solving an internal tooling process.
​
​
Context
Problem
Freenow has been facing an audit risk for a long time: Invoice corrections and refunds aren't done in a compliant way. Furthermore, correcting invoices takes a toll on Customer Care Agents. They face high error rates and response time.
The invoicing and payout team wants to create an automated process where the manual work of updating collateral refunds and payouts is no longer needed.
I aimed to host all the invoice editing cases into one flow and design a solution to be the foundation of a new internal tool.
My role
I was the only UX team member in the Invoicing and Payment department. I had a double role: Product Designer and UX Researcher. I worked hand in hand with the PM of Invoicing and Payments, a UX writer, and sporadically collaborated with the EM.
The Invoicing and Payment team was historically a backend team. They were in the midst of hiring a front-end developer. In the meantime, the development team was fully emerged in another project, so collaboration with them was on an ad-hoc basis.
​
Tools
​
-
Figma, Notion, Miro, UzerZoom
​​
UX artefacts
​
-
User journey maps, task flows, wireframes, interactive prototypes
​
UX Research
​
-
Shadowing for discovery and remote Usability testing for validation, Usability Severity Problem analysis
Situation
The Finance team continuously flagged that invoice corrections weren’t done compliantly at Freenow. Meaning that accounting information doesn't match 1:1. By the time I joined the Invoice and Payment Team, the PM had made a lot of discovery in the matter:
-
Defined the regulated steps to mark an invoice correction as compliant.
-
Agreed with the Development team on how the new backend architecture would create compliance invoices.
-
Found out the highest errors committed by customer care agents.
-
Determined the use cases we should include in the MVP based on the most common requests for invoice corrections.
There was a lot of information to digest. Initially, I saw the need to translate all the requirements, implications, and collaterals that each invoice correction request entailed into user stories to understand our users' needs.
Current situation and proposed automation
Finding the right problem
1. Shadowing customer care agents
The PM had already done an excellent job identifying the most common requests that needed an invoice correction and where the most human errors from the agents were happening.
But I still needed to see this in action. We contacted several Customer Care Agents and shadowed them while they were resolving a passenger complaint.
The problems that stand out most were the following:
-
High response rate due to having to navigate through four tools (Zendesk and CRM tool, two internal tools called PMT and BOMT).
-
Each country would have a different way of documenting the changes.
-
Sometimes agents don’t know what additional steps each invoice correction scenario triggers.
Current Customer Care Agent's process
2. Use cases alignment
As multiple reasons and types of invoices were involved, we had to compromise on which errors we would solve first.
Together with the project manager, we decided to work on invoices issued on the passenger side first, as they created the most problems for our agents. Once I listed out all the user stories, we prioritized the use cases in a matrix where we assessed the user need and the design effort. This exercise helped me establish a priority and a good overview of all the tasks I needed to include in the flows of searching, editing, and correcting an invoice.
3. Constraints by following an invoice compliance practice
To be financially compliant, we had to follow a set of rules when editing an invoice. We would have to create additional steps depending on the data to be changed.
​
For instance, we had to issue two invoices: the voided one and the corrected one, where the information that needed to be altered involved amounts (full or partial). The driver's payouts would need to be withdrawn, and driver invoices would also be impacted.
Other situations, such as those using cosmetic information (passenger's name, surname, address, and email), required fewer parallel procedures. Driver invoices or payout won't be impacted in this scenario.
All this meant that the agents' decisive step was to decide which invoice changes belonged to which scenario to create the additional materials accordingly. Therefore, we had to prioritize this step in the solution.
All collaterals per topic
Finding the right solution
1. One visual language for all our internal tools
Although I had to create a new internal tool, I wasn’t starting to define the visual style from scratch. The company already had a Design System in place called WAVE DS.
Furthermore, the Design team was already trying to unite the different visual styles from various tools in the same UI direction, so I had a style guide to adhere to.
2. Converting a PDF invoice into an editable form
I had to translate all the invoice information into an editable format to construct a new corrected invoice.
3. Same user flow for different editing reasons
Considering that the editing reason was the essential part, I worked on iterating on the flow until I reached a point where all the editing cases were solved using the same steps.
4. Iterating on the flow's usability
After I outlined the overall flow, I needed to focus on the individual phases. There were two critical points in the flow when the risk of making an error would prompt the user to update incorrect information in the invoice.
​
Getting feedback from my peers is essential for me. It helps me unblock doubts and brings me new perspectives. Apart from having 1:1 sessions with some of them, I also took advantage of one of our rituals of showcasing our work to get feedback from different disciplines inside UX.
1. How can we prevent the user from making a mistake?
I brainstormed on finding the best approach to show the reason to correct an invoice. I decided to go for the progressive disclosure, which helps sequence the information. I collaborated with the team's UX Writer on the phrasing.
Option 1: List, from most to least used case
Option 2: Grouped by type of data to be corrected
Option 3: Progressive disclosure - Winner solution!
Option 4: Is a dropdown needed?
2. Confirmation step: Improving scannability
​​Another critical stage in editing an invoice is validating all changes. We were at risk of making incorrect payments if this step was not completed correctly.
I played around with various elements from our Design System to indicate those changes and assist the user in reading them correctly.
Usability testing
How will the agents react to this new process? Do the agents find the editing and correcting process intuitive? Is it truly adding value to their workload and allowing them to work faster?
To answer these and other problems, I proposed conducting a remote usability test. I was in charge of organizing everything:
1. Recruitment Pool for Passenger Care Agents
One of my intentions was to bring UX Research methods closer to the Fintech and Marketplace domains by making it simple to recruit internal employees for PMs or new UX team joiners.
As a result, I established a User Recruitment Pool. I sent an opt-in survey to all of our internal tool users, asking if they wanted to participate in any user experience research activities the department would need feedback on.
I used this pool to recruit eight agents.
2. Resembling a real case scenario
The interviews were conceived so the user would read a task resembling a real case scenario. I would create different emails with the data the agent has to look for during the flow.
3. One-hour remote in-depth interview
I facilitated all eight interviews and invited my project manager and UX writer to participate as notetakers.
​
You can find some of the findings in the below section of Results :)
Constraints and trade-offs
The development team was unavailable
Historically, the development team was only a backend team due to the nature of the department. This project was their first front-end focused. When I first joined the team, they were looking for a front-end developer, but the process took longer than expected, and I didn't have a coworker to check in with on a frequent basis to see if all of the envisioned flow was realistic to accomplish.
The team's EM filled the gap in between, but we couldn't have component-level conversations.
Results
Unfortunately, the project was put on hold due to a shift in company objectives, and implementation was not prioritized. I was only able to present and document the results of the usability test.
Severity Ratings for Usability Test Issues
I applied Norman Nielsen's rating of the severity of usability problems to determine what issues I should target for the next iteration of the designs. This classification is based on three factors:
-
How frequently the issue occurs.
-
How much it will cost the user to resolve the issue.
-
If the problem remains over time.
​
I classified the issues I discovered as significant, minor, or cosmetic. Find below some examples.
1. Major usability issues
It is critical to fix because the user is prone to make mistakes.
2. Minor usability issues
Issues that cause discomfort to the user but do not block them.
3. Cosmetic issues
Problems that do not prevent the user from doing an action
4. New findings
During the usability test, we discovered new things and noted them as potential improvements.
Learnings
1. Customer care service ecosystem
Through this project, I could interact directly with Customer Care Managers and Agents and gain their insight into the value of maintaining timely connections with our customers.
​
They were excited to show me their procedures. This overview expanded my understanding of the user experience from the perspective of the entire service.
2. Consequences of mental models
The key finding from the usability testing was that customer service agents already have a mental model in mind when they correct an invoice. So we weren’t starting from scratch.
​
We learned that customers anticipated the refund to be the main course of action rather than choosing which kind of error they wanted to repair in the invoice. Therefore, the problem selection process I designed needed to be revised.