How to ease accounting for small business owners

The goal

Several studies suggest that small and medium businesses (SME) around the world contribute to more than half of the domestic GDP to their respective countries. Although the SME have to bear the weight of the neo-economy, oftentimes the business owners find it challenging to integrate digital tools into their businesses, mainly due to the lack of digital literacy, availability of cheap internet, and most importantly, the difficulty of using digital tools, among many other factors. Providing the small and medium business owners and entrepreneurs with easy to use and useful digital tools is the need of the hour. That mission starts with enabling those business owners to efficiently manage their workflows, transactions, and services.

The goal of this project is to create a handy, accessible, useful and usable solution to bookkeeping for small business owners so that they can record their transactions easily and manage their workflow better.

Foundational research

Before we dive into the project, let’s crunch the numbers first.

A research by Thomas et al. (2004) [1] suggests that 99.8% of all firms in the European Union are SMEs. In South Africa, the contribution of SME to the GDP is between 52% and 57% (Adeniran & Johnston 2016; Cant, Wiid & Hung 2016; Gono, Harindranath & Berna Ozcan 2016; Mavimbela & Dube, 2016) [2] [3] [4]

In the United States, 57% of small businesses believed that their lack of familiarity with digital tools is a challenge, as found by a research conducted by Morning Consult and Facebook, as reported by U.S. Chamber of Commerce in this article [5].

One more study by SARIWULAN, T. et al. (2020) [6] finds that digital literacy has a significant positive impact on the skills of entrepreneurs.

These data points clearly show that the SME around the world are a hugely important part of our economy and are in dire need of easy to use digital solutions for their daily workflow.

Understanding the problem

To understand the consumers and their particular needs at a basic stage, a survey was prepared which gives us some insight into the demographic and their behavioural data.

The survey consisted of both quantitative and qualitative questions, and was distributed among a target audience of small and medium business owners.

Survey: Demographic questions

The purpose of these questions were to find out from which social segment our prime users are coming from.

Survey: Behavioural questions

The following questions were asked so that we can find out the frustrations our users feel while using their preferred method of accounting, and also to find out why they keep using it.

We can analyse why the users keep using alternative accounting methods and take that reason away to put in our product with a much better experience. That will be a game changer for the first step of our product building. It is important to mention that the reason matters more here than the particular feature or the experience that it comes with.

Survey summary

The survey was answered by a total of 46 people, among which 25 people (54.34%) categorised themselves as small business owners with at least one shopfront, 16 people (34.78%) categorised themselves as freelancers with no shopfront, and 5 people (10.87%) categorised themselves as medium businesses with more than one shopfronts.

Furthermore, the survey found that Excel sheets (26.08%) and ledgers (36.9%) are some very popular methods of logging finances among the audience which makes sense as 47.82% of business owners were above the age of 46, to whom writing down expenses and dues, and using traditional methods are more common.

Young business owners (from 18 - 30 years old) ranked at ~17% and the rest (31 - 45 years old) at ~35%.

The data further reveals that 35 out of total 46 people, those who used spreadsheets and ledgers, often felt frustrated, confused, and helpless while logging expenses and incomes via their preferred method, where the bank app/site and other bookkeeping app users felt that it got the job done and was effective at informing spending categories and tax breakdowns, although at the expense of an unfriendly user experience.

User interviews

Through the survey, we figured the main preferences and frustrations of our users. However, to empathise with the users, and to truly understand how overwhelming their experience was, interview sessions were conducted with a handful of small and local freelance business owners.

The interviews were conducted with open-ended questions so that the users could voice their frustrations without being led. At the end, the users put forth some serious issues.

"I’m old and I’m not good with computers and modern phones. I usually write down my day’s income, dues and expenses in ledgers. I also need to maintain balance books for each customer and I don’t know how many of those I have at this point."

"I left my job, so that I could focus on my bakery business, to market it to more people. But I regret it every time I need to log my finances. I also wish I could get some financial advice such as best methods of money saving tactics."

"The app that I use to calculate my expenses is only available in a certain language and I don’t understand many things. I also can’t find many things on the screen often."

"I write down my incomes and expenses in Excel sheets. It’s tedious to fill it up and I’m not a spreadsheet pro and I find it very difficult to get summaries for each month. Half of the freelance business is only paperwork, nobody told me that before."

User archetypes

Based on the survey and user interviews we can segregate our user base into three user archetypes.

We will not be using user personas here since the fundamental flaw with user personas is that they are broad and abstract. They focus so much on their demographic details that they almost ignore the frustrations which most of the time have nothing to do with users’ demographic. For user personas to work, they have to reflect the data that was analysed and comply with the user goals that were found. Without granular focus on the improvement of the experience, and the users´ goals and scopes, the personas serve next to no purpose. A lot more on this topic can be learned below.

Following are the three prime user archetypes that were created.

👤 The grocery shopkeeper

User archetype 1 is a family business owner who runs a small grocery shop and lists all his finances in ledgers for years. Furthermore, for his age, gets easily frustrated with the different balance books for every customer.

Too aged to understand complicated software and can read only his mother tongue.

Goals:

🎯 Log his daily expenses/incomes and dues.

🎯 Maintain separate balance books for each customer.

🎯 Simplify few processes so that he can spend time with his family.

Frustrations:

💢 Too old to understand general accounting software.

💢 Too many customer-balance books to maintain.

💢 Understands one language only.

👤 The new entrepreneur

User archetype 2 is a new entrepreneur who just left his job as a front-end developer at a well-known company to follow his passion which is opening a bakery chain. Coming from an IT background, he is disappointed with the obsolete and difficult experience traditional accounting software provide. He wants to focus on his business and marketing but that requires his finances to be on autopilot.

Goals:

🎯 Log his daily incomes and schedule payments.

🎯 Have a great user experience with minimum effort to track his finances.

🎯 Automate logging payments from Point-of-sale machine.

Frustrations:

💢 Too busy to spend hours to understand complicated applications.

💢 Distracted from his main goal which is to expand his business and marketing.

💢 Feels traditional accounting software do not focus enough on new-gen entrepreneurs.

👤 The young freelancer

User type 3 is a single mother and young freelancer, runs a customised handicraft business online, based on orders. She does not have a need for daily income/expense logging. However, she lists all her expenses, dues, and incomes from clients in an Excel sheet at the end of every month.

Goals:

🎯 Log expenses from sells receipts.

🎯 Create customised invoices for her clients.

🎯 See simple monthly reports of her finances and categories she spent her money on.

Frustrations:

💢 Easily gets frustrated with Excel sheet formatting.

💢 Needs to create invoices for every payment with online tool.

💢 Can not generate reports of her finances from Excel sheets.

Defining the problem

The user archetypes help us to understand the problem with modern finance management software to the root! They are not user-friendly, offer little to no automation and are overly complicated. Users want ease, flexibility and total control over the data that is being presented to them. Our job is to create a product that is useful, usable and delightful, not a platform to show off maximum features. Otherwise, the irrelevant analysis of data is as good as no data!

A concise statement on the problems will help us explore and scope our path and eventually discover a solution.

Problem statement

Our users are mid-economic business owners without a budget to appoint accounting agencies and without the knowledge of digital accounting. They spend a lot of time trying to navigate, comprehend, and perform tasks to simply understand and manage their financial transactions. This is a problem because it eventually frustrates the users to the point where they abandon the digital product and start using traditional offline methods, as cumbersome as those may be, and it hinders the digital transformation of the economy. There is an opportunity to create a digital product that will help users manage their finances quickly and easily, and thus create a profitable customer focused app.

Based on the surveys and user interviews, a couple of user stories were established, which will help us with our ideation process!

As a family business owner, I want an easy to learn software that speaks my language and which I can operate with minimum hurdles, so that I can spend more time with my family.

As a former front-end developer turned entrepreneur, I want to have a solution that simplifies logging my sales and expenses, so that I can focus more on marketing my business.

As a freelance designer, I want a user-friendly app to manage my invoices, so that I can calculate my taxes and finances better.

What comes to light from these user stories are that our product should focus on:

• language localisation
• using nomenclatures that are understandable in layman’s language
• no-frills transaction details
• adding transactions easily
• ↳ or to automate them (based on the user’s hardware capacity)
• creating invoices and scheduling payments

On our quest to understand how the existing products are able to help (or not) users, I conducted an intensive market research based on the availability of the above features. I nominated six software that are widely used (at the time of doing this research) among freelancers and small business owners. My nomination for a competitive research consisted of Quickbook, Freshbook, Khatabook, Xero, WaveApp, and Monefy.

Except for Freshbook, all the rest fell behind at the overall user experience.

Oh yes, I named the app Outreg — the outraging new solution to put all the register books out of business. 🤔 Anyways...

Ideating the solutions

Before we jump into the solutions, let’s first understand the limitations and viability. Ideation is the only step in the product designing process which is focused on quantity rather than quality. There are a plethora of solutions and features that we can implement to solve the above problems, but mapping out the possibilities and scopes of the project will guide us towards the right direction of making a useful product rather than being lost in features.

Scopes

There are many different techniques that can be applied to prioritise the requirements in a project, but we will be using the MoSCoW method (Must have, Should have, Could have, Won’t have) as it is one of the simplest methods to quickly determine priorities.

Based on the interviews and by analysing the project’s limitations, the required features were prioritised. According to the outcome, we will focus on onboarding (which will address three out of four requirements in the must haves), manual transaction logging, and invoicing (which will cover contact management as well).

Wireframing

During the search for the ideal solutions, I started designing action flows in Figma for the must-have features and created low-fidelity prototypes to validate my design decisions.

I began with a couple of simple questions:

How might we make the onboarding easy for our target users?

I thought to minimise the options on the landing screen for the users and tell them more about the product until they are ready to explore. I designed a swipe through product information journey which also asks the user certain questions (such as selecting their profession and preferred language) to set up an appropriate profile for them in the background. This should reduce time taken to set up the app. I kept the sign up/log in screen as minimal as possible in order to reduce the cognitive load on the less tech-savvy users. I decided to make the addition of banking details appear only when requested by the user.

How might we make manual transaction logging easy for our target users?

Once the users land on the main home or dashboard, they should be presented with an overview of their account in case they have already used this app before, or else, the dashboard will prompt them to add their first transaction (income/expense), which can be achieved by either manually typing the transaction details or by simply taking a photo of the bill or invoice, where the app will detect the items and the prices. In future, with the help of an AI data-analysis in the backend, the app should be able to automatically detect the biller, billing details and reduce errors in detecting the items and their respective prices. In an advanced scenario, it may even add the biller in the contact as well automatically.

Outreg wireframes

Usability testing

Although, it is advisable to create medium fidelity prototypes for internal usability testing if a design system is in place, since this app is still in its pre-launch early stage, I used Material Design Kit 3 to quickly ideate the screens. The reason for this decision is that the design language is highly accessible, fluid and does not require a lot of cognitive load from the user, since it is familiar.

I created two low-fidelity prototypes to understand how effective it is for users to complete certain tasks which will, in turn, test my design decisions.

1. Onboarding Test:

• Task: To introduce participants to the wireframe prototype, explaining its purpose and core features.
• Test Focus: Assess the effectiveness of onboarding elements and participants' comprehension of the app's purpose and key features.
• Metrics to Measure: Participant feedback on onboarding clarity and usefulness, comprehension of the app's purpose and features.

2. Form Completion Test:

• Task: To instruct participants to add a new income or record an expense.
• Test Focus: Evaluate the clarity, ease of use, and efficiency of the form design and interaction.
• Metrics to Measure: Completion time, number of errors or hesitations, participant feedback on form intuitiveness and ease of completion, etc.

3. Navigation Test:

• Task: To ask participants to find and access a specific month’s transactions.
• Test Focus: Assess the ease of navigation and the clarity of the app's menu or navigation structure.
• Metrics to Measure: Time taken to locate the transactions, number of incorrect paths taken, participant satisfaction with the navigation experience.

4. Information tree test:

• Task: To ask participants to find the right path to create an invoice.
• Test Focus: Assess the the clarity of the probable options.
• Metrics to Measure: Time taken to locate the “create invoice” option, number of incorrect paths taken and successful returns to original start point.

I shared the prototypes with a hand-picked group of 20 users who not only fell in the target audience segment but were also briefed to understand that they are testing a early-stage prototype. Understanding what they are seeing on the screen was an important eligibility criteria for this test because this way the users would not be confused while testing a low-fidelity prototype and also the necessary amendments can be made before the app goes to production.

It is always important to test the design with actual users in high-fidelity mode, but it is quite impossible to do so before launching the product in the wild and before having a design system established.

Usability testing on Maze

Prototype 1: Onboarding Test

Out of 20 users, 7 (approximately 35%) took the intended or direct path and completed the task, while 11 participants (approximately 55%) completed the task by taking paths not intended in the prototype. 2 participants (approximately 10%) got lost and abandoned the task. The average misclick rate was 18% of total clicks and the average time to complete the task was 30.8s.

Onboarding test results

Judging by the heatmaps, about 45% of participants tried to go back on the onboarding screen and also skipped the prodouct features and wanted to arrive on the login/signup screen quicker.

Onboarding heatmaps on project feature journey

While 55% participants could still complete the task indirectly, the number is still huge and we do not want users to be distracted and go on unintended paths. On the sign up/log in screen, we notice 2 drop-offs, signifying that first time users were not much inclined to create an account before exploring.

Combining product walkthrough and profile setup did not bear fruit as envisioned.

Prototype 2: Form Completion Test

Out of 20 users, 4 (approximately 20%) had direct success logging their expenses, while 14 participants (approximately 70%) took an indirect path to complete the task. 2 participants got lost. The average misclick rate was 21.7% of total clicks and the average time to complete the task was 43.7s.

Transaction logging test results

The particpants who took indirect paths, spent quite some time (about 12s to 15s) on the start screen or homepage to locate the “Add Transaction” CTA, which was a Floating Action Button comprising of two sub-CTAs — “Add Expense” and “Add Income”. Perhaps two separate buttons with clear labels will help them complete the task faster. Since the targeted users are majorly an elder population, the FAB may not make much sense to them. I will run an A/B test to confirm this assumption.

65% of the total users opted to use the “Take a photo of your receipt” option to log their transaction. The whole process took about 20 to 25 seconds provided the backend server can analyse the snapshot fast enough in the real app. Rest of the participants went the extra mile and logged the transaction using the manual mode.

Prototype 3: Navigation Test

Out of 20 users, 4 (approximately 20%) took an intended path and 9 participants (approximately 45%) took the indirect paths to complete this task. 7 participants abandoned the task. The average misclick rate was high at 48.3% of total clicks and the average time to complete the task was 23.6s.

Navigation test results

35% of participants leaving this task and about 45% taking indirect paths suggests that it was indeed very hard for them to locate the calendar filter and navigate through it. Perhaps a simpler interface to navigate between previous and current months or weeks would be beneficial. Also, judging by the heatmap, a number of participants tried to see the text that was being obscured by the problematic floating action button. 2 out of 7 participants who left the task, also left feedback that they could not find the calendar filter to begin with.

Heatmap around the CTA position

Tree test

70% of the users took the intended path to locate the “Create invoice” option proving the information hierarchy to be accessible.

Tree test result

A/B testing

To confirm my assumptions about the FAB being problematic, I made two more prototypes to check click rates. The first prototype had the old FAB and the new one had two primary CTA buttons distinctively labeled to add expense and income. I also changed any button on the screen that resembled a primary CTA. The second prototype had an increased successful click rate of whopping ~85%. The participants did not need to think or look too hard for the CTA as they were easily scannable up front.

A/B test results for the problematic floating CTA

Designing the ideal solution

After conducting a thorough analysis of the identified pitfalls and user behaviours, I meticulously refined and enhanced the wireframes to holistically capture and incorporate the valuable insights gleaned from the findings. By iterating on the wireframes, I strived to ensure that they effectively align with the users' needs, expectations, and preferences, fostering an optimised and intuitive user experience that addresses the identified challenges.

A note about the branding...

With our primarily digitally inexperienced user base in mind, the app has been thoughtfully designed for maximum engagement. Larger typography ensures easy content discovery, whilst spacious button areas minimise misclicks. The app's vibrant mix of pastel colours and bold shapes that are both aesthetically pleasing and easily distinguishable, appeals to both younger and older generations, creating an inclusive and visually appealing experience that promotes accessibility for all users. The purple represents luxurious experience while the green represents finances (literally called the colour of the money). The logo is inspired by the percentage symbol which appears very often in the balancing and profiting calculations. The branding also incorporates a subtle square-grid pattern on pastel green that is usually seen in balance or register books, with a playful mix of the brand shapes.

Onboarding

I removed the product features from onboarding flow and let the user select options that were more important for them such as local language and the option to sync their contacts with the app. The flow has been made simpler to both new and returning users as new users will get to choose the walkthrough process and the returning users will be able to sign in without the walkthrough. The local languages can be fetched and personalised based on the IP address. Users were not forced to sign up for a new account as the option was tucked in the profile menu for later use and users were allowed to use the app right away locally, which increased conversion.

Final result for the onboarding flow

Transaction logging

For logging transactions, I placed two clearly labeled buttons on the home page as confirmed from my previous A/B test. I also removed the blank graph from the home page as it confused the users. I improved the expense logging flow to some extent by letting the user take a photo of their receipts by default. For income logging, the manual process had to be implemented as default as many of the users did not have a point-of-sale machine to connect or did not add their bank account to pull the incoming cash flow data.

Final result for the transaction logging flow

Navigation and Date Filter

I reimagined the entire filtering by showing all the transactions on one screen which the user could scroll through. I also implemented a dedicated filter button which provides user-friendly and yet granular filtering options.

Final result for the navigation and filter flow

Invoicing

I provided a separate page in the app where all the contacts can be segregated by either Vendor or by Customer category. From there the user can view details of the vendors and customers, view payment histories and send invoices (to customers) or payments (to vendors).

Final result for the invoicing flow

Conclusion

I ran the new prototypes again and observed a significant improvement in user performance. The latest results reveal an impressive increase in direct success rates across all tasks, with 85% for onboarding, 70% for transaction logging, and a remarkable 90% for locating a given month's transaction. Moreover, it is equally exciting to note that no participants abandoned the tasks, indicating a higher level of engagement and satisfaction. These positive outcomes affirm the effectiveness of the refined prototypes and validate my efforts in creating a user-friendly experience that successfully addresses user needs.

Results of the final prototype

Key Takeaways

• Usability testing, A/B testing, and tree testing are valuable tools for evaluating design decisions and enhancing the user experience.
• Onboarding should be quick and easy, providing clear guidance and minimal options.
• Simplifying manual transaction logging and exploring automation options can enhance user experience.
• Intuitive navigation with helpful filters and clear labels improves usability.

Future Implementations

• Automatic transaction logging from the point-of-sale machines to streamline the process can be explored once an integration with the POS software is in place.
• Adding bank accounts to fetch transaction details and send payments can be explored. This feature will be different for every region as most countries have certain ways and regulations for adding, fetching, and accessing bank details.
• Conducting research on language localisation and nomenclature preferences to cater to non-English speaking users.
• Show languages that are related and contextual to the physical location and geography of the user.
• Continuously test and refine the navigation and filtering systems to enhance the user experience.
• Consider incorporating advanced features like predictive analytics or machine learning to automate certain tasks like invoice creation, payment scheduling and such to provide additional value to the target audience.

Incorporating these valuable insights and lessons learned, we are poised to deliver a user-centered product that delights users, meets their needs, and provides a seamless and engaging experience. Together, let's create something truly exceptional!

References