Ed is 41 years old and has his own bicycle repair shop in Great Britain. He repairs the bicycles and takes care of the business management himself. He is already using an invoicing app to send invoices to his customers on the go, but he’d also like to be able to register both his paid and unpaid (future) expenses, so he can have an overview of them and eventually share them with his accountant. With the given scenario, it is defined in bold what are the user needs for this task.
CAPABILITIES
Interface design, Visual design, Prototyping
TOOLS
Figma, Principle
Ed is 41 years old and has his own bicycle repair shop in Great Britain. He repairs the bicycles and takes care of the business management himself. He is already using an invoicing app to send invoices to his customers on the go, but he’d also like to be able to register both his paid and unpaid (future) expenses, so he can have an overview of them and eventually share them with his accountant.
How could Ed organize his receipts, keep track of his expenses and share them with his accountant in an easy way using his mobile phone?
In this exercise I set a time limit (one week) to work on it. Each screen was designed on a superficial level, however, I mention thoughts that I had on features not designed and other nice-to-haves. What will be covered:
My research started with understanding the basics of how does the accounting business works. From that, I looked into solutions that are already solving the problem in order to learn and get inspired to design the right thing.
OCR (Optical character recognition) was present in the solutions, meaning that users take a picture of the receipt and the data is automatically added.
If there something that was not able to be extracted, it is possible to add data manually.
Most of them lacked a more informative overview screen, that was only available on their web platform.
Expenses in most of the cases needed to be first added to a report to then be ready for sharing.
After analyzing references it came the fun part: to explore a solution and put it into paper and consequently digitally.
The video shows all the screens covered in the final design solution: getting an overview of the expenses, taking a picture and adding a receipt, and finally sharing with the accountant.
In the upcoming paragraphs, I will describe in more detail how I came to design each screen.
This screen is the core of the app. Here, is where the user can get an overview of expenses over the months, take actions like add and share expenses.
In the first block, the user gets data regarding the total amount spent on a selected month and the amount comparing with the previous month.
Below the first block, the bar graph helps to visually identify in which months the expenses are higher or lower, as well as easily navigate among previous and upcoming months.
The next block is the expenses list. The list is divided based on the date of the receipt (not the date it was added). In the first line is shown the merchant name together with the total amount, while the second shows the category of the expense and the type: bill, which is for future expenses (they can be marked as open and later changed to paid once the payment is confirmed), or receipt, for expenses already paid.
The blue button at the bottom adds a new expense, that opens a modal for the user to choose between uploading a bill or receipt. In both cases, it will open the camera to take a picture of the expense.
Not covered in the solution:
Food for thought: How would it look like if an uploaded receipt could not be scanned due to an error? Would it be useful to enable to manually add expenses instead of scanning them? Additional options when swiping left over an item, for example, enable the possibility to remove an expense? Would it be useful for the user to know the total amount of open bills? What KPIs are important to display in the overview?
Although the solution was designed using data in a British scenario, the receipt used as an example in the mockups was from a Danish merchant, since it was the only one I could get around.
For expenses marked as open bills, the user should be able to change the status to paid. In case of errors in the OCR, it is possible that the user can correct the wrong data on the fly by directly pressing on the field.
The “show more” button hides additional details and features, making the screen less polluted and focusing on the core information only. Once opened, the user would be able to see a full description of the expense; history (when was it added, what was corrected); remove or share with someone.
Not covered in the solution:
Food for thought: Integration to add payment details to directly pay open bills?
The key interaction of the share screen is that the user can choose to send single expenses or in bulk, by selecting months using the bar graph, since it would be cumbersome to individually select many expenses in a busy month.
In the send modal, the user should be able to add one ore more emails to send the expenses. A button on the right edge of the email field allows selecting saved emails from a list.
Not covered in the solution:
Food for thought: If the user sends the expenses always to the same accountant, which I believe would be the case, how about having this email by default in the field?
The interactive prototype shows how the navigation between screens behaves. As expected, only some items have links, so press anywhere on the screen to get hotspot hints.
The interaction below was inspired by Revolut’s expenses list. If you have a chance to install their app you will understand how seamless it is the experience: the user can scroll vertically through the list while updating the horizontal date graph at the same time. It gives instant feedback on where you are located.
This task was very exciting to work on and challenging at the same time. A lot of questions arise during the process since I was not that familiar with the accounting world. Definitely questions would be asked on a daily work basis when working with a team that has more knowledge on the accounting area and know more of their customer’s pains. Having feedback if this was the right track would be pretty much appreciated for more rounds of iterations.