Role
UX & UI Designer (User Research, Visual Design & Testing)
Date
August 2020
Platform
Web
One of the core responsibilities of an organization’s accounting team is to process incoming invoices and check if they should be paid or not. This is done with a process known as 3-way matching, which involves checking information on an invoice, purchase order and packing slip all match up. Having the right tool to do it with efficiency and accuracy is vital.
For this project, I worked with a team to redesign the invoice processing experience in Procurify, to help finance teams save time and have more trust in their data.
In early 2019, I worked with a development team on an integration that sent bills (created from invoices in Procurify) over to QuickBooks Online, a popular accounting system. However an adoption blocker we identified was that the Invoice Processing module was not meeting customer needs to create Bills efficiently.
With the average user processing on 329 invoices per month with an average of 3 minutes to process per invoice, this lengthens their day-to-day operations. In addition, the completion rate per bill was only at 55%, which meant the module’s issues were causing a lot of our users to dropping off midway.
Digging further into this, we learnt that the module was also a blocker for product adoption and caused a lot of issues for different teams. Members of our Sales team said they avoid showing customers the Invoice Processing workflow because it felt “clunky” and lacked key features.
Customers directly expressed similar complaints, saying the workflow is disjointed where they would have to continually switch context (via 4 different modals and pages). This increases confusion, frustration, and could result in users not wanting to use the invoicing process. As finance teams typically have strong influence in a contract decision for Procurify, it was important to satisfy their needs to both close and prevent churn.
“I’m not comfortable selling our invoice processing module because it does not meet the customer’s expectations of a 3-way match process.”
- Procurify Sales Team Member
“I cannot adopt Procurify’s invoice processing workflow because it’s too confusing to use and takes too much of my team’s time”
- Procurify Customer
To help better understand the full experience, we created a user journey map based on our learnings from interviews with customers and internal team members. By mapping the user’s feelings at each point of the journey, we determined the experience had 3 major pain-points where the most frustration was experienced:
Problem 1:
It takes too long to know where to start processing an invoice
Problem 2:
It takes too long to process invoice data into a payable bill
Problem 3:
It is difficult to find the right information to validate if an invoice's information matches my purchase records
Solving these would allow finance teams to successfully validate company spending with less fraud, and more efficiency.
Throughout the ideation process, I communicated frequently with both internal and external stakeholders to understand if the solutions presented aligned with their values. I also heavily relied on my development team to discuss the feasibility of the solutions and what sort of scope they would entail.
In order to ensure we were delivering consistent customer value, we split the work up to work on each problem separately. This would help us ship features quicker, receive feedback and iterate on them.
To address the issue of users not knowing where to begin their invoice processing, one chosen idea was to number each step of the user workflow and include instructions that explained what to do. This not only helped users better understand the system but also guided them through an ideal workflow.
One thing we repeatedly heard from our customer interviews was that the Invoice Processing layout was not ideal. Users typically had a setup with Procurify and their invoice open in two separate windows. They would use this to alternate between them to copy over invoice information into their system.
This workflow was very time consuming and required a lot of manual effort. They also expressed they wished to be able to view their invoice within Procurify, similar to other Invoice Processing programs.
To address this, users needed to be able to see both an invoice document and the form at the same time to efficiently view and enter their data. I created a page layout to allow for an invoice to be viewable on the left side and the Bill creation form on the right.
Another issue we wanted to address was adding purchase order items to a Bill, which users had to manually select one by one. This required a lot of clicks from our users and required a lot of time and effort.
To address this we came up with a way for users to type in their Order number and have all the items added to a Bill. Collaborating with the development team, we ensured that orders needed to fit a certain criteria to be able to add them to a Bill. This was in order to not only play nice with the system but also to avoid confusion for the customer. With the average Bill containing 8 items, we aimed to reduce the steps needed so our users could save time and effort.
The final problem is the issue around finance teams not being able to make payments to the vendor as efficiently because of a lack of purchase data in the accounting module. Previously, customers had to dig through other internal and external areas, such as emails, to find out the history for the discrepancy.
After speaking with customers and our internal team members, I found out what sort of information they would need to resolve mismatching discrepancies. This primarily included knowing who was involved with the item’s history, important dates and attachments.
To address this, I proposed an idea to have a modal for each item to provide the typical information users need to resolve discrepancies. This also included a link to the pages that the user would need to visit if the information was not enough.
Before development work began, I worked with the Project Manager to validate these solutions with customers to ensure we were hitting the mark. From our initial research phase, we established a list of beta customers that we frequently communicated with. Once the designs were finalized, we ran them through the solutions and received a lot of positive feedback. With this validation in place, I worked with the development team to help bring these solutions to life.
Once development was complete, we rolled out the new module to our beta customers. During the 2 week beta period, I frequently communicated with these customers to receive feedback. Despite minor issues and bugs found, they found the new workflow significantly easier to use and reduced their processing times.
After our beta period was over and we addressed all the raised issues, we released the new change to our entire customer base. However one issue not brought up in our beta period was more space for the Bill form to see more information without scrolling. The issue was brought up by 12 customers in the first week of release.
From this feedback, I developed a solution to expand and collapse the form to allow for more flexibility in the page. Thanks to the development team, we were able to quickly build this solution and deliver value to our customers.
Since our release, we were able to achieve two key metrics:
We also received positive comments directly from customers:
“I am enjoying the new bill module. It’s really nice to be able to have the invoice on the left and coding on the right. Having the PO total in the dropdown is also helpful.”
“LOVE IT! The split invoice/entry screen is one thing I liked about bill.com, so glad to this in Procurify now! I love the purchase order drop box that brings the PO over.”
“I really like the new create bill module. It certainly gives us the functionality to move to a more paperless process.”
For a high fidelity prototype, click here.
Overall this project was a great experience to see from start to finish, and leading the design efforts helped me learn how to best communicate with stakeholders.
One main learning I got from this project was thinking about the sizing the project, and dividing the solution up into incremental releases rather than big portions. Though we were able to successfully ship our final product, smaller releases would have helped us deliver value faster to our users and allowed us to learn what improvements we could make quicker.
Another learning was to think about who is included in an initial rollout. Had we included more power-users in our beta program, we would have uncovered issues earlier and had a smoother rollout to the wider customer base.