Case Study · B2B SaaS · FinTech
Redesigning an accounting app so business owners can do their own bookkeeping, without an accountant
Ongoing · about 50% redesigned and implemented
The problem: A big accounting app, built by developers without a designer and never tested with users. Its core workflows were confusing, cluttered and sometimes unfinished.
What I did: Reviewed the whole app, built a roadmap with the PM, and ran workshops on each core area with all three real users. Then I redesigned those areas, proposed and designed Adviser, an AI assistant, and built the new UI myself with Claude Code.
Key decisions: An Overview sorted by urgency, clear statuses everywhere, search and filters for long lists, payroll in small steps, and Adviser, an AI assistant inside the app.
Status: About 50% redesigned and built. Formal testing of V2 is next.
Simple Booking wants business owners to do their own accounting, taxes and month-end included, for a low monthly price, instead of hiring an accountant. Along the way, Adviser, an AI assistant, helps them understand their numbers.
When I joined, the product was already big: invoices, quotes, receipts, journal, payroll and more. But it was built around the database, not around people. There was no clear hierarchy, statuses were missing, some parts were unfinished, and the app expected users to know accounting, which is exactly what they don't know.
A bit like a cookbook that assumes you're already a chef.
If an owner can't see whether an invoice is paid, they'll hire an accountant instead, and the whole idea fails. So every decision had to answer one question: can someone without accounting knowledge do this alone?
The app was too big to fix at once, so I started by reviewing everything myself. Together with the PM, I ranked each part by business importance and how badly it was broken. Six areas came first: Overview, Invoices, Quotes, Receipts, Journal entries and Payroll.
The startup had three real users, all running small companies in Stockholm. That's a small group, but it meant I could work with every one of them. They did real tasks in their own work environment and told me how it felt, and in one session I sat beside a user and watched him think out loud. Then I turned the patterns into design decisions.
I lead the UX work end to end, side by side with the PM, and with the back-end team, who connect the front-end I build to the rest of the product.
I went through the whole app and listed problems, gaps and bugs.
We ranked each part by business importance and how serious the problems were.
All three users did real tasks in their own environment, and I watched one of them in person.
I compared what the three users said and did, and turned it into design decisions.
Here's what we found in each area, in the order people use the app. V1 is the original, V2 is my redesign.
Users couldn't see which invoices were paid, or find a specific one.
The setup form came first, so users couldn't see what would be sent next.
Every button looked equally important and some statuses were missing, so users couldn't tell where a quote stood.
The upload area was so big that users had to scroll to find their receipts, and every status was the same grey.
The longest list in the app, with no search, filters or sorting. Finding one transaction meant scrolling through everything.
One big block of repeated information, and nothing told users what to do first. So I organised the page by time.
Registering an employee meant filling in two long forms. During the workshop, one user stopped and asked:
"I filled in this option above. Why is the system asking me to fill it in again?"
— Workshop participant, Payroll sessionNo field was actually repeated.
The form was just long enough to give everyone déjà vu.
So the fix wasn't the data, it was how much we showed at once.
AI assistant · My idea, my design, my front-end
Even with clearer screens, accounting raises questions. So the redesign includes Adviser, an AI assistant that opens in a side panel next to the user's work. Nobody has to leave the page, search a help centre or call an accountant.
Adviser started as an idea the team wasn't sure about. I designed it to show what it could be, and the team decided to build it. Because so much of it depended on the back end, I worked closely with the back-end team through many sessions to shape how it should work, then finalised the design and built the front-end myself.
Users type a question the way they'd ask a person, like whether two of their companies affect each other's revenue, and get a clear answer without accounting terms.
Adviser explains revenue and reports in everyday language, so owners know where they stand.
In conversation mode, users just talk. They pause, the question is sent, and the answer is read aloud. Useful when typing is hard or the keyboard gets in the way.
When Adviser can't solve a problem, it creates a support ticket and confirms it right in the chat, so a real person follows up.
An accountant that's available at 11 pm on a Sunday.
It closes the loop on the question behind the whole redesign: owners can do their accounting alone, but they're never stuck alone.
From the workshops, I wrote five principles. I check every new screen against them.
Start with what needs attention.From the Overview
Users should never have to guess if something is sent, paid or overdue.From Invoices, Quotes and Receipts
Long lists always get search, filters and sorting.From Journal entries and Invoices
Each screen has one obvious main action.From Quotes
Split long tasks into short steps.From Payroll
Before redesigning screen by screen, I built a design system, keeping what worked in the old design and improving the rest. It's also what makes building with AI reliable: Claude Code uses the same colours, type and components as my Figma file, so every screen looks and behaves the same.
I build the front-end myself, directly in the product: design in Figma → build with Claude Code, one component at a time → check it in dark and light mode → hand it to the back-end team → improve it with user feedback.
Sheet 01 · Foundations
Sheet 02 · Components
About half of the app is redesigned and built. Next comes formal usability testing of V2 with the same three users and the same tasks, comparing V1 and V2 on task completion and errors. Until then, this page shows my decisions and why I made them, not results. I'll add the numbers after testing.
Working with every real user on every core area went deeper than a bigger, quicker study would have.
If something feels complicated, it needs fixing, even when the data is correct.
My decisions make it all the way into the product.
Looking back
I'd add short sessions with a few new users, beyond the three existing ones, to check that the patterns hold as the product grows.