Jannyne Perez | UX Designer
Jannyne Perez

Case Study: Email to bills

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.

Project kick-off

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.

Agile story mapping session to divide work into shippable phases

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 seamless 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 very subtle. A popover to draw attention the new feature and secondary text to differentiate a forwarded bill from one a user has created manually.

Initial designs used for the first and second round of user testing

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 text.

  • That our customers were very good at checking fields for errors.

  • Missing fields were seen as annoying and provided little value if they still had to do more work to finish the draft bill.

Five 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.

Our research participants had missed the incorrect value on the bill’s unit price – it did not match the amount on the attached invoice

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.

Running a Design Loop – a session for non-designers to generate ideas, potential solutions or areas to look at for the problem

From grouping themes to idea generation and iteration

The most up to date design based on feedback, iteration and experimentation

The flow



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.