InvoX Dashboard

The Problem

Freelancers and small finance teams were tracking invoices across spreadsheets, email threads and legacy accounting tools. Nothing gave them a single answer to the only question that mattered day to day: who owes me money, and how late are they?

• Overdue invoices were discovered by accident, not by system
• Creating an invoice took 8+ clicks across three screens
• Revenue reporting required exporting to a spreadsheet

Goals & Success Metrics

We framed the redesign around measurable outcomes rather than a visual refresh, so every design decision could be argued for or against.

• Cut time-to-create an invoice by at least half
• Surface overdue balances on the first screen, without a click
• Give a non-financial user a readable revenue picture in under 10 seconds
• Ship a component library the two engineers could build from directly

Research

I ran six interviews with freelancers, agency owners and one in-house finance lead, then audited four competing tools to map where the friction actually lived.

The pattern was consistent: users did not want more features, they wanted fewer decisions. Every participant described chasing payments as emotional work they wanted the product to depersonalise.

User Personas

Two personas carried the project. Tolu, a freelance designer with 5–15 open invoices, who needs speed and gentle payment nudges. And Ada, a finance lead at a 30-person agency, who needs oversight, filters, and exportable reporting she can defend in a meeting.

Where the two conflicted, Tolu won on the create flow and Ada won on the reporting views.

Information Architecture

The old structure buried status inside each invoice record. The new IA flips it: status is the top-level organising principle, and invoices are the objects inside it.

• Dashboard — balances, overdue, cashflow trend
• Invoices — list, filters, bulk actions
• Clients — profile, history, payment behaviour
• Payments — timeline of money actually received
• Reports — exportable revenue and tax views

Wireframes & Early Concepts

Low-fidelity first, in greyscale, for three days. Three dashboard layouts were tested on paper: a card grid, a split list-and-detail, and a timeline-led view.

The split layout won because it let a user scan the queue and act on one record without ever losing their place — the single biggest complaint about the previous tool.

Visual Design & Design System

A dark, low-glare interface built for long working sessions, with a restrained accent palette so status colour actually means something.

• 8pt spacing scale and a 4-step type ramp
• Semantic status tokens: paid, pending, overdue, draft
• Tabular numerals across every money value
• 36 components documented with states and handoff notes

Key Screens

The dashboard leads with outstanding balance and overdue count. The invoice builder is one screen with inline line items and a live preview. The payment timeline replaces the old status column with a readable history of every touchpoint.

• Dashboard with revenue trend and overdue alerts
• Single-screen invoice builder with live preview
• Client profile with payment-behaviour summary
• Payment timeline and reminder scheduling
• Report builder with CSV and PDF export

Prototyping & Usability Testing

A clickable Figma prototype was tested with five users on two tasks: create and send an invoice, and find every overdue client.

Task one dropped from an average of 2m 40s to 1m 15s. Task two went from a 60% success rate to 100%. Two rounds of fixes came out of it — clearer draft-versus-sent labelling, and a bigger tap target on the reminder action.

Outcome & Impact

The redesign shipped as the product's 2.0 release and became the reference for every screen added since.

• 50% faster invoice creation in moderated testing
• Overdue balances visible on load, with zero clicks
• A component library the engineering team builds from directly
• Reported satisfaction of 98% in the post-launch survey

Key Learnings

Designing for money is designing for anxiety. The most valuable changes were not the charts — they were the small reassurances: clear states, undo, and a preview before anything irreversible.

I would also involve engineering in the IA stage next time. Two late constraints around invoice versioning forced rework that a 30-minute conversation in week one would have prevented.