Reimagining invoice workflow for 30,000 users
Background
Yuki is a B2B Accounting software and this project is specifically Yuki's document workflow page—used daily by every accountant to book client invoices—had accumulated years of feature bloat and confusing status indicators. Users were accidentally interrupting automation, missing critical actions, and struggling to understand what required their attention. A technical migration provided the opportunity to fundamentally rethink this core experience.
Challenge
I worked as the UX Designer and was tasked with the re-design. I took this opportunity to understand the depth of the feature and tried to re-look it. Despite being mission-critical, the page had become cluttered and confusing over years of incremental additions. Users were working around the system rather than with it.
Context & Business Impact
Why This Matters
The document workflow page is the heart of Yuki's platform—the single most-used feature where accountants:
Review incoming invoices from entrepreneur clients
Book documents to appropriate accounts
Ask clarifying questions when needed
Process documents to prevent end-of-quarter backlogs
Understanding the problem
Feature Audit: What are the current features and functions of the feature.
Catalogued every existing feature and function:
30+ document status indicators
Action buttons scattered across the interface
Inconsistent visual hierarchy
Internal research: What have been current problems with the feature, support tickets, existing bugs, issues.
Analysed support tickets and bug reports
Conducted internal interviews
Data analysis : Worked along the team to dive into the usage through Mixpanel and Power BI.
Key findings:
60% of features were used by <5% of users
Many status indicators provided no actionable information
Users frequently opened documents during OCR processing, accidentally stopping automation.
User Story Mapping Workshop: Facilitated sessions with the team to map out the user flows, steps and iterations.
We divided the view into two different flows - to increase automation and have a clear distinction between
View 1: "Let the system work" - Check if automation handled everything
View 2: "I need to intervene" - Fix issues, add missing info, ask questions
User testing : Presented the design to users and asked them to use the prototype and share their feedback.
The semantic differences in color for recognition status was appreciated.
The didn’t need the three different views that we assumed and designed and for the next iteration we reduced it to two views.
Solution
Tried to take the picture apart and relook at how the document gets processed. At what point does the user needs to take action - what kind of action is required. There core things we focused on:
1. Feature Bloat
Unused features cluttered the interface, making core actions harder to find.
2. Status Overload
30+ statuses created cognitive burden without adding value. Users couldn't distinguish between "system processing" vs. "waiting for user action."
3. Automation Interruption
Users unknowingly disrupted automation by opening documents still in OCR processing, resetting the workflow and requiring manual entry.
1. Simplifying features
The Decision Process:
Cross-referenced usage data with user interviews
Identified features used by <5% of users in past 6 months
What We Removed:
40% of action buttons (consolidated or deprecated)
Redundant buttons and views
Status indicators that provided no actionable insight
2. Re-imagining statuses
Users didn't need granular system statuses like "Submitted for processing" vs. "Awaiting recognition"—they needed to know one thing: "Can I act on this, or should I wait?"
We started by mapping the entire document recognition workflow, then audited the codebase to identify unused statuses. We consolidated 30+ statuses into two categories: "Action Required" vs. "System Processing," and added color coding to indicate urgency and next steps.
3.Focusing Attention: Actionable vs. Automated
Users were opening documents to check status while OCR was still running—interrupting automation and forcing manual entry.
Created two distinct views:
View 1: "In Recognition" (System Processing)
Shows documents actively being processed
Read-only preview available
Clear indicator: "Automation in progress—will move to 'To Be Booked' when ready"
Estimated time remaining (when available)
View 2: "To Be Booked" (Action Required)
Only shows documents requiring user input
Opens directly to editable state
Prioritized by urgency/date
