Qwix: Small Business Accounting Tool

How might we make accounting tasks easier, faster and less intimidating for small business owners?

How We Got Here

I started working as a Product Designer at Qwix in October 2022, as the company’s first hire.

Qwix is an early-stage startup working on an a SaaS product for Israeli accounting firms that specialize in small business accounting. The vision: a tool that could be used by both the accounting firm and the small business owner to streamline and improve processes.

When I joined the company there were still a lot of unknowns about what our users needed and therefor what the product should look like. This case study follows my design process when designing the first feature for the MVP: the expenses feature on the business owner side of the app. However, that process was intertwined with activities that were part of more foundational discovery research and that contributed to the company’s overall product strategy.

My Role

I was the sole product designer at the company, and my role in this project included:

Performing discovery research including user interviews, contextual inquiry, SME interviews and secondary research, in addition to synthesizing and analyzing the resulting data.
Constructing information architecture and user flows based on user research and business goals.
End to end visual design including sketching out multiple concepts, and designing high fidelity wireframes using a design system
Creating prototypes and performing user testing to test out design concepts and iterate based on feedback.
Designing detailed mockups for the engineering team.
Shaping product strategy together with the company founders.

The Problem

The first thing I did when joining the company was get acquainted with the subject matter- Israeli taxes and bookkeeping standards as they apply to small businesses. I wrote more about this experience here.

For the purposes of understanding this feature, here are two things to keep in mind:

The business owner is responsible for making sure they generate and receive the proper receipts, but most business owners turn their receipts over to accounting firms so that they can handle all of the reports and payments to the government on the business’s behalf.

The Opportunity

Our overall product vision included improving this experience for business owners, and the expenses feature was a big part of that vision.

In order to understand where this feature fits in, here’s a quick look at the journey that expense receipts typically take from the time of purchase until they are reported to the government:

Each leg of this journey requires it’s own treatment, but this feature focuses on step 3- getting the receipts from the business owner to the accounting office.

From handing over physical folders to digital uploading

Traditionally, business owners have collected all of their receipts throughout the month and then physically brought them in to their accountant at the end of the reporting period (every 1-2 months). Bookkeepers then review the receipts manually and use that data to generate the appropriate reports and calculate how much business owners owe the government.

As technology has advanced, more and more accountants are asking their clients to use digital software to upload their receipts, since the firm can then use OCR (optical character recognition) software to automatically extract data from the receipts.

We knew that having clients upload receipts and using OCR to parse them had the potential to improve things for both accounting firms and business owners, and there were a couple of competitors in the market already providing this in some form. However, we needed to dive deeper to understand our users and their needs- and what needs weren’t being met by existing solutions- in order to optimize the feature that would allow business owners to upload their receipts to the system.

Uncovering User Needs

The research for this feature was wrapped up in a larger discovery research project that I led when I first joined the company. In this first round of research I tackled some really basic questions we had about user needs, behaviors and workflows. If you want to learn more about the research in its entirety, shoot me a message- I’m a research nerd! I’ll share the information relevant to the Expenses feature in particular here.

The research consisted of the following, split up by user type:

🧠

Notable Challenge: We didn’t manage to recruit enough participants on the accountant/bookkeeper side. We remedied this later on by doing a discovery research project focusing solely on accountants and bookkeepers, but for the sake of the client-facing expenses feature this was alright - we needed more detailed information on the business owner side for this feature, plus the relevant information on the bookkeeping side was fairly consistent across all of the participants I spoke to and observed.

After gathering all of my notes I got to work synthesizing the data. I used topical grouping and affinity mapping to find themes in the data. Here are some examples from research on the small business owner side:

Grouping data by topic.

Grouping data by theme/sentiment.

I distilled the research into core insights, presented them to my team and facilitated a collaborative brainstorming session to generate ideas for solutions. After the session, I categorized the ideas, ironed out some of the details and took a closer look at some design-specific considerations. Here’s a summary of the research insights pertaining to the expenses feature, and the resulting design solutions or guiding principles:

🧠

Notable Challenge: The business model of the company pointed to the bookkeeper/accountant being the user we needed to solve for the most, but it was still very important to us to ensure that the business owner’s needs were being met. Designing the business owner side of this feature while keeping in mind (and sometimes prioritizing) the needs of the other user(s) was challenging!

User Flows, Design Patterns and More

In order to get a better understanding of how the user should move through the tasks involved in the uploading, managing and viewing a given receipt, I took a closer look at other products in the market to see how they do this.

I looked at Green Invoice and iCount which are bookkeeping platforms whose primary users are small business owners, Paperless which is an accountant-facing bookkeeping tool that also provides business owners with a way to upload receipts directly to their accountant, and Sumit which is a little bit of both.

I analyzed the flows and design patterns in these products to gain inspiration, and then circled back to the user needs we uncovered, our unique product vision and the technical constraints we were working with in order to decide on the appropriate flow and patterns.

Here’s an example of how I compared design patterns and flows used in other software. I took notes on interesting UX decisions I noticed, what I liked and didn’t like, and how they handled certain use cases:

How Green Invoice (left) and iCount (right) let you add a new expense.

Here’s a snippet of the final user flow for uploading a new receipt:

A small section of a user flow.

Sketching

I sketched out multiple ideas for each flow and then multiple solutions for each screen. I then decided which designs would be most impactful yet feasible.

Four possible layouts for the uploads page. The final layout is combination of the top right and bottom left sketches.

Before moving on the high-fi wireframes, I consulted our design system.

Collaborating on the Design System

The company decided early on that we would purchase a “ready-made” design system with a Figma library and corresponding React library to speed up the design and development process. However, I soon discovered that though our MVP would be in Hebrew, the design system (Minimal UI) was in English and there was no easy way to swap everything to right-to-left for design purposes. Additionally, while the design system was built for a dashboard-style product, it needed to be tailored better to our exact needs- I needed to modify some components and add new ones. Lastly, while pre-made UI elements were really helpful, there was no documentation to go along with them, so I needed to create standards for when and how components were to be used.

🧠

Notable Challenges: Deciding when it was worthwhile to make changes to the design system, and figuring out the best way to track those changes. In order to maximize my time, I collaborated with the engineering team to examine the impact that potential changes would have on the user experience and the development process, against the effort it would take to redesign those components and update the code accordingly. For tracking changes made to the Figma file of the design system so that they could be modified on the dev end, I consulted with the front-end engineer and we came up with a figma comments system that worked for us.

Some comments about modifications that I left next to the text field components in the design system - for the front-end developer and for my future self.

High-Fi Wireframes

Since I had a design system to work with, I went straight from sketching to high-fi designs. During and after the first draft of high-fis, I shared the designs with the engineering team to get their feedback on feasibility and edge cases. Since this was the first feature being designed and built out in its entirety, this was a great to have early and preemptive discussions about things like micro-interactions, annotation preferences and what the developers did and didn’t need in a prototype.

Here’s a peek at how the research and resulting design principles translated into the high-fi mocks:

Iterations, User Testing, More Iterations and… Implementation!

After a few rounds of getting feedback on the designs (from dev and a more experienced designer), doing moderated usability testing and iterating, it was time for the engineering team to start implementing the designs.

Here’s how I organized data from a round of usability testing:

Grouping usability testing results in an affinity map- by theme and sentiment.

And here’s a peek at how I annotated my designs for the developer:

Annotations on a dialog that allows the user to zoom in on and rotate the receipt, as well as add a relevant note or question for the bookkeeper. A lot of my annotations are about changes I had made to the original design system library.

Annotations on the expenses table, which is where business owners can find information about receipts that have been reviewed by the bookkeeper.

As the engineering team worked on the designs, I communicated with them daily to get updated on their progress, review elements to ensure alignment with the original designs and collaborate on solutions as various edge cases and technical considerations came up. I was lucky to work with phenomenal engineers who care a lot about UX, so many of the modifications were a product of fruitful collaboration.

See It In Action

This is a demo of the completed feature:

Looking Back & Ahead

The product has not yet been released, but it’ll be exciting to see how this feature fairs in the hands of real users. Whenever the product is released, we’ll measure user behavior and satisfaction carefully to ensure that we are solving the right problems with the right solutions.

I learned an immense amount working on this project- and at Qwix in general.

To name a few:

✔️ Balancing the needs of multiple user types within a complex system is challenging, but it’s the kind of challenge I thrive on.

✔️ Pre-seed startups are constantly refining their vision and roadmap, so flexibility is important.

✔️ Leaning on user research and usability testing results is a great way to prioritize design decisions and defend them to others.

✔️ Collaborating with engineering early and often is key.

✔️ Putting in effort to understand the industry your designing for pays major dividends (fintech joke intended 😉).

If you’d like to hear more about this project and my additional work, be in touch!