Taking care of the manual data entry of bills
I was a product designer for a data science and automation project for Xero. I worked closely with a team of 6-7 developers, a product owner, a data scientist and user researchers.
Depending on the volume of bills they receive, small business owners can spend hours a week manually entering their bills into Xero. This is a painfully tedious experience that can become a barrier for them to keep an accurate and up-to-date record of their outgoing transactions, which in turn affects how they manage their cash flow.
What we set out to do
By automating parts of their current workflow, we aimed to save our customer’s time so that they can focus on what they loved doing instead – running their business.
How it works
Each Xero organisation has a unique email address that they can forward their PDF bills to. Once it arrives, it then creates a new draft bill (marked as a forwarded bill) with the PDF attached. Depending on the organisation’s pricing plan it’s also possible to have fields filled-in automatically using our machine learning algorithm.
I joined a data science team and together we went through the agile process of project inception and story mapping to divide the work into three chunks: proof of concept, MVP, and phase one.
While the rest of the team were working on the proof of concept, I learned how machine learning worked (on a high level) and worked mainly on feature discoverability and trying to create a seamless experience that felt right. Initial designs were based on learnings from user research and quantitative data from similar areas in Xero. During the process, I also frequently had feedback sessions with other designers.
This was a challenging project for every member of the team because the feature was planned to be built on one of the older pages of Xero that interconnected back to other parts of the product.
For me, this meant I had to work with the constraints of delivering an experience that didn’t rely too much on bells and whistles. I had to be mindful of what was technically possible in the time we had and have ongoing conversations with people in my team and outside of it. If anything needed to be built on the UI, it had to be validated with user testing first.
Design, test, iterate, repeat
We had always set out to make sure that the experience felt as pleasant as possible, to help our customers enter their bills faster but not replace their role in this process . Because we were aware of the limitations of what the machine learning model could do, we actively avoided situations that would take control away from the user.
For example, a forwarded bill going straight to an approved status would mean that we would have removed an essential part of the review process for our customers that is necessary to spot mistakes.
At first, I kept the UI elements minimal. A popover to highlight the new feature and subtitle text to let the user know that they had a forwarded bill in their draft bills that they need to act on.
In the first round of testing, I worked with our user researchers and planned a session using lo-fidelity InVision prototypes as the team was still in the process of building the feature and training the model. From there we learned that the feature needed work in the clarity of the popover copy text and that our customers were very good at checking fields for errors. We also learned that missing fields were seen as annoying and provided little value if they still had to do more work to finish the draft bill.
On the second round of testing about 5 months later, the feature was now available to a percentage of our customers so we had an opportunity to test with a live prototype. It is impossible for our machine learning algorithms to always get the correct value so we wanted to create a test scenario that would mimic what would eventually happen with continued use of the feature: it would populate a field with the wrong value.
Here we unearthed a new set of usability issues, mainly around how our customers were missing errors when they had high expectations of the populated fields and how they became genuinely disappointed and embarrassed when they realised what had happened.
After running through the user research with the the team, I ran an ideation session with a focus on addressing the main usability issues. One of these was reframed into a question: How might we help customers understand when suggestions are less certain so they can avoid errors?
This gave the team an opportunity to collaborate with me on the design process and give me refreshing angles to approach this problem. I then grouped the ideas into themes, designed different solutions and presented back to the team. Together we selected the idea that we thought was the most appropriate for the problem. It was technically difficult to build but the research indicated that it was necessary to help manage our customer’s expectations so it was pulled into the following sprints.
Around 800,000 bills were created in the month of April 2019, with about 63% of those with populated fields. The latest round of testing has indicated that customers who use the feature find it valuable because it saves time for them in three aspects: it removes it from their inbox as a task to do, it keeps a record of their bill in one place and it gives them fewer fields to fill in.
The changes to the UI were assumed by customers that it is Xero indicating that they need to “check if these values are correct” but were generally ignored if they have already set their expectations by using the feature repeatedly. Our customers were optimistic that the feature would “learn over time” and were generally forgiving of errors because of the time the feature has given back to them.