Receipt management

The problem

Replacing a standalone tool with an integrated feature

The company's separate receipt application was being retired. It hadn't been updated frequently and no longer met client needs. The product team was asked to build receipt management into the existing mobile application and accounting software — replacing a standalone tool with an integrated feature across two surfaces.

This wasn't a small addition. The feature needed to cover the full lifecycle of a receipt: capture on mobile, transfer to the accounting software, processing by accountants. Two distinct user types — entrepreneurs sending receipts and accountants processing them — with different devices, different workflows, and different definitions of what done looked like.

My role & constraints

Sole designer and Product Owner across a broad scope

I was the sole designer on the development team and also held Product Owner responsibilities. The scope was large enough that I requested a UX Designer colleague to assist with the research phase — that help was essential given the dual role and the breadth of the project.

Everything from the first user survey to the final UI was my work. The colleague's contribution was in the research phase specifically. Tools: Adobe XD, Miro.

Discovery

Research built in layers, each step informing the next

The starting point was existing user feedback. Customer service had accumulated complaints and requests about the current receipt application. Rather than starting from scratch, we used that material to shape a questionnaire for entrepreneur users — targeting how they currently processed receipts and where they experienced friction.

I also arranged a workshop with accountants to get the processing side of the picture. The customer service conversations had surfaced what was broken at a general level; the accountant workshop grounded those ideas in how professional processors actually worked. The two groups had different pain points. Entrepreneurs found capture and submission cumbersome. Accountants needed better visibility into receipt status, clarity on who had processed what, and the ability to handle missing or incomplete receipts.

With no time available for direct observation or structured interviews with entrepreneur users, I planned and facilitated a proto-persona workshop with the development team. Seven proto-personas were produced — each with background, pain points, needs, and behavioural characteristics.

Bringing developers through the workshop was a deliberate choice: it gave them direct exposure to user needs before a single line of code was written, which changed how development decisions were framed throughout the project.

The design challenge

A coherent feature across two very different surfaces

The core challenge was a two-sided workflow problem. The mobile side needed to be simple enough for an entrepreneur to use quickly — take a photo, add information, send. The accounting software side needed to give accountants enough control and visibility to process receipts reliably: edit information, track status, identify who had handled what, and manage exceptions like missing receipts or PDF files.

Both surfaces were part of the same feature. A decision made for the mobile flow had implications for what arrived in the accounting software, and vice versa. The design had to be coherent across both without flattening the different needs of each user group. The framing question I used to anchor the work: how might we create a simple workflow to ease receipt processing for both accountants and entrepreneur users?

Process

From layered research to alpha and beta testing

Phase 1: User research

Customer service feedback analysis, an entrepreneur user questionnaire, and an accountant workshop — run in sequence, each building on the previous. The questionnaire went to entrepreneur users, the mobile senders. The accountant workshop used the questionnaire findings as a basis for deeper discussion about the processing side, so it wasn't starting cold; it was stress-testing and extending what the questionnaire had already surfaced.

Phase 2: Proto-persona workshop and problem framing

A proto-persona workshop facilitated with the development team produced seven personas covering the main user types on both sides of the workflow. I created a receipt lifecycle chart mapping the full flow from capture through to accounting software processing. This gave the team a shared picture of the problem before any interface design started, and produced the HMW framing that guided what followed.

Phase 3: Wireframing and prototyping

Initial wireframes for both surfaces: the mobile application covering capture, information entry, and submission; and the accounting software covering the receipt management view, information editing, and status visibility. Research had surfaced two additions beyond the initial brief — the ability to add supplementary information to a receipt before sending, and support for PDF receipts, not just photos. Both were incorporated, and both had implications for the accounting software side that needed to be designed for at the same time.

Phase 4: Prototype testing

I contacted accountant users directly — via email and phone — to test the initial prototypes. Developers from the team participated in the sessions as observers, continuing the empathy-building started in the persona workshop. Hearing users describe confusion in real time is different from reading a findings summary; it changed the quality of development conversations after testing. Feedback was incorporated into prototype revisions before development began.

Phase 5: Alpha and beta testing

Questionnaires were sent at the beginning and end of alpha and beta testing phases, and feedback from those rounds informed continued iteration alongside development. The team iterated until the project deadline. Participation in the testing groups proved difficult to maintain — response volume was lower than needed, which meant some later-stage decisions were made on assumptions rather than validated user input. That limitation was managed as transparently as possible, but it was real, and it affected the confidence level of some design decisions in the final stretch.

Key design decisions

The decisions that shaped the feature

Two-surface coherence without forcing identical interaction models

The mobile capture flow and the accounting software processing view needed to work together without pretending they were the same thing. Entrepreneurs needed speed — minimal steps between taking a photo and submitting. Accountants needed control — status visibility, editing capability, exception handling. The design held both by keeping the mobile flow focused and giving the accounting software the complexity it actually needed, rather than simplifying both to a common denominator.

Proto-persona workshop as a developer tool, not just a design output

Running the persona workshop with the development team rather than presenting them a completed set of personas was a deliberate choice. Developers who had built up the same picture of user needs that informed design decisions understood why those decisions were made. That shared understanding reduced friction when design and development tradeoffs came up later, and it changed how the team talked about the product during prototype testing.

PDF support and supplementary information as research-driven scope additions

Both came from research rather than the original brief. Users needed to attach PDFs — not just photos — and needed to add context to receipts before sending. Including both in scope was a product call as much as a design one. Each had downstream implications for the accounting software side that had to be resolved in the same design pass.

Developers as prototype testing observers

Inviting developers to observe testing sessions extended the empathy-building from the persona workshop into direct user contact. A developer who has watched a user struggle with a flow in real time carries that differently than one who has read a research summary. It was worth the time cost.

Artifacts produced

What was delivered

• Customer service feedback analysis.
• Entrepreneur user questionnaire and results.
• Accountant workshop output.
• Seven proto-personas (Miro).
• Receipt lifecycle chart (Miro).
• Mobile application wireframes and prototype: capture, information entry, submission (Adobe XD).
• Accounting software wireframes and prototype: receipt management view, information editing, status tracking (Adobe XD).
• Alpha and beta testing questionnaires.
• Final UI: mobile receipt capture and accounting software receipt management.

Outcomes

Shipped, and new users brought to the application

The feature shipped and brought new users to the application. Receipt management is still supported with ongoing development. The two-surface scope was delivered within the project timeline, and the proto-persona and prototype testing approach gave the development team more direct contact with user needs than was typical for this team, which changed how development decisions were discussed throughout the project.

The limitation was alpha and beta testing participation. Engagement was harder to sustain than anticipated, and response volume from those phases was lower than needed. Some later design decisions were made on assumptions rather than validated input. That was the honest tradeoff of the timeline and testing format.

What I would do differently

Where I would push harder next time

More research with entrepreneur users. The research was stronger on the accountant side. The accountant workshop produced specific, actionable findings. The entrepreneur side was covered by questionnaire only — no direct observation, no interviews, no testing with actual entrepreneurs submitting receipts. Given that the mobile capture flow was half the product, that imbalance matters. With more time I would have pushed for direct sessions with entrepreneur users before wireframing started.

Better alpha and beta testing engagement design. The participation problem wasn't just a recruitment issue — it was also a design of the testing process itself. Questionnaires at the beginning and end of a testing period are a low-commitment format, but they are also easy to deprioritise. Shorter, more frequent touchpoints — or more directly facilitated sessions — would likely have maintained engagement better and produced more usable feedback volume.

Earlier scope definition on the accounting software side. The mobile flow had clearer requirements from the start. The accounting software requirements — editing, status visibility, exception handling — emerged more gradually through research and iteration. More explicit scoping of what the accounting software needed to handle before wireframing started would have made the design process more efficient on that side.

Reflection

The most research-intensive project in my Accountor portfolio

Running surveys, an accountant workshop, a proto-persona session, prototype testing, and alpha and beta feedback rounds — while holding Product Owner responsibilities — was a significant operational challenge alongside the design work. It required constant prioritisation of where time went and what could be done rigorously versus approximately.

The decision that had the most lasting impact beyond the immediate project was bringing developers into the research and testing process directly. The proto-persona workshop and the prototype testing observations gave the development team a user-grounded understanding of what they were building. That changed the quality of conversations throughout — not just during design reviews, but during technical decisions where user needs were otherwise easy to lose sight of.

The honest gap is the entrepreneur side. The accountant persona is richer and better validated. The entrepreneur experience on mobile was designed from a weaker evidence base. For a feature where half the value depends on how easy it is to capture and submit a receipt, that asymmetry is worth acknowledging.