Tax teams had run audits in Excel for years and had no reason to stop. The platform had to feel familiar on day one — and take over the checking they were doing in their heads.
Every audit lived in one Excel file. Colour codes held the rules, and one person held the file.
Kept the table people already knew, and moved the checking into the product — flags, reasons and a work queue.
In testing, people finished the core flows without training, and the strongest Excel users started asking for it.
↔ Scroll the screen sideways
Every audit ran inside one Excel file — many tabs, hand-built formulas, and checks done from memory. The team knew that file well, which is why earlier tools had failed to replace it.
So we stopped trying to replace it. We looked at what made Excel easy for them, and built those parts into the product.
Reviewers held last year’s numbers, this year’s numbers, the difference and their own notes in their head while working down the sheet.
| A | B | C | D | E | F | |
|---|---|---|---|---|---|---|
| 7 | Cl 9(b) — members / ratio change | |||||
| 8 | Name | PAN | Date | Old | New | Diff |
| 9 | Rajesh K Menon | AABPM4471K | 12-06-23 | 22.00 | 18.00 | -4.00 |
| 10 | Sunita Deshpande | AFTPD9012Q | 01-08-23 | 15.00 | 21.00 | 6.00 |
| 11 | Imran Qureshi | BKLPQ2238M | 18.00 | 18.00 | 0.00 | |
| 12 | Meera Iyer | CDXPI7754R | 01-08-23 | 20.00 | 20.00 | 0.00 |
| 13 | Vikram Shetty | AMNPS3390B | 28-02-24 | 10.00 | 12.40 | 2.40 |
| 14 | 85.00 | 98.40 | #REF! | |||
| 15 | yellow = ask partner · green = ok last yr · red = PAN pending. ratio short 1.6 — Vikram deed? | |||||
Colour carried the meaning, and the only key to it sat in row 15 of one tab, in one file.
Same table, but the things people were tracking by hand are now on the screen: last year’s value, the difference, the status, and the reason behind each flag.
The aim was to feel familiar without behaving like a spreadsheet.
| Member | Last yr | This yr | Δ | Status |
|---|---|---|---|---|
| Rajesh Kumar Menon | 22.00 | 18.00 | −4.00 | PAN not verified |
| Sunita Deshpande | 15.00 | 21.00 | +6.00 | No deed on record |
| Imran Qureshi | 18.00 | 18.00 | 0.00 | Matches last year |
| Meera Iyer | 20.00 | 20.00 | 0.00 | Matches last year |
| Vikram Shetty | 10.00 | 12.40 | +2.40 | Dated after year end |
Same columns, same reading order, same habits. The one change is that every flag now says why it is flagged.
Clause screens, dashboards and the main flows. I took the clause screens from wireframes to final UI, along with the analyst dashboard, the My Work queue and entity setup.
I defined the shared table, status and empty-state patterns, and worked with engineers to keep every design practical to build.
Time with real users and real files. I sat with reviewers working in their own Excel files, built clickable HTML prototypes to test with, and wrote the screen notes engineering built from.
We were asked to make data entry faster. After watching six reviewers work through real audits, it was clear that data entry was not the problem.
Most of their time went into finding the right file, checking numbers again, and working out what had changed since last year.
Six sessions, grouped on the wall. Four problems came back in every single one.
Nobody asked for a new system. They wanted something that felt like Excel but did the remembering for them, so the rules were not sitting in their head all day.
Five things came up again and again across the six sessions. Every big decision after this had to answer to one of them.
People trust Excel because they built it themselves. Asking them to give that up on day one was never going to work.
Tax season is stressful enough. Nobody wants to learn a brand new tool with a deadline running.
Fewer clicks, and far less time spent hunting for the right file or the right number.
A small slip can turn into a real problem later, so people check everything twice. The tool should carry some of that load.
They had built their own formulas over years, and did not want to learn a new syntax to keep using them.
A clause can hold five rows or five hundred. Reviewers open the same clause many times in one audit, so what shows up first matters more than it looks.
I built three versions and tested all of them on the same Clause 9(b) data.
One member at a time, with guided fields. Safe and easy to follow, but people kept asking to see the other members.
The whole clause as one editable table, close to Excel.
Rows with problems come first. The rest of the clause stays one click away.
Each one failed for a reason worth keeping.
The first version let people type anything into any cell and sort it out later. That broke the audit trail. If a number can be changed quietly, there is no record of who changed it.
Every clause in one long scroll. In testing, people lost their place within minutes and could not tell what they had already checked.
The system was confident about 40% of rows, so the plan was to clear those and show the reviewer the rest. But partners sign the return personally, and they will not sign for a row nobody opened.
A firm rarely quits a tool in week six. They quit in the first ten minutes, when one import does not match their records and reopening the old workbook feels safer.
So setup is four short steps, and nothing is allowed to fail quietly.
The financial year is the only real decision here.
The assessment year, due date and form fill in automatically.
The assessment year stays locked, so the three can never fall out of step.
The file is checked before anything is imported.
28 rows came through clean. 3 are flagged, and the problem is named on the row itself.
A flagged row never blocks the import. Fix it now, or fix it later.
Analysts prepare and submit.
Admins review, approve and file.
Roles are named after what a person does, not after permission levels.
A plain summary of what is about to be created.
156 clauses across 28 entities — named before they appear.
Every card can still be edited. Nothing is locked until you finish.
First, how a return moves: set up the workspace, bring in the entities, work through the clauses, send for review, file.
Then the clause screen itself. The eight decisions below are the ones I would defend in a design review, and each one comes from something we watched people do.
The full path from setup to filing, including what happens when a reviewer sends work back.
Everything a reviewer needs to sign off one clause, on one screen. The notes below explain the eight choices behind it.
Print, Edit, Cancel and Save are outlined. Only Send for review is filled, because it's the only action that hands the work to somebody else.
Each sub-clause carries its record count, and a tick once it's done. You can see what's left across 9(a) to 9(e) without opening any of them.
Whether member shares are indeterminate changes how every ratio underneath is read, so it's answered above the table rather than buried as a field inside it.
Completion, verification counts and the document checklist live in a rail, not a separate dashboard. The reviewer's real question — is this ready to sign? — is answered without leaving the clause.
Verified, Review suggested, Action required, Pending — each spelled out and each paired with a reason in Remarks. The dot reinforces the word; it never carries the meaning alone.
Profit sharing has to total exactly 100.00%. The total is calculated, sits at the foot of the rows it sums, and is the fastest place to catch a bad entry.
Selecting a member opens the detail below the table instead of in a modal or on a new page. The list, the running total and the record stay in view together — and identifiers stay masked until someone needs them.
“Low ratio” appears beside the number it's about, not in a summary at the bottom of the page. Whoever fixes it doesn't have to go looking for what was wrong.
An analyst opens the product asking “what do I do next?” An admin opens it asking “what is going to be late, and who is stuck?”
The plan was one dashboard with a role switch. I pushed back. One screen answering both questions would have answered neither.
↔ Scroll the screen sideways
Analyst — My Work. The first screen after sign-in. It answers one question, and does not try to answer the other.
Five due today. Two sent back by the reviewer. Said in one sentence, before any chart.
Six tiles across the top. Each one opens the queue already filtered, so a number is never just a number.
The queue sorts by due date and returned work, not by name and not by entity.
Due dates sit in a fixed rail on the right, so nothing depends on remembering to look.
The admin view is a separate screen. Same data underneath, but built around approvals, entity progress and what is slipping, rather than a personal task list.
This was a new product, so there is no “before” to compare against. Everything below came out of testing sessions and design reviews, not launch metrics I cannot stand behind.
People got through setup and a full clause review with no walkthrough first.
Problems showed up in the cell, so people fixed their own work before sending it on.
Shared components meant two squads never built the same pattern twice.
Finance and compliance signed off without asking for a redesign.
Time saved per return. Error rates in live filings. How long a firm takes to move over. All of it needs data from after launch, which I did not have. Putting numbers on it would be guessing.
I came in wanting to modernise everything. I left protecting the way people already work, and putting the new power underneath it.
The auto-clear idea cost most of a sprint. Two conversations would have ended it in an afternoon. Now I put rough work in front of two people before anyone builds it properly.
Our sample data was too tidy. Duplicate rows, broken references and odd date formats only turned up once real filings hit the screens.
Bulk fixes for errors that repeat. A reviewer view for team workload. And a way to measure the work, because with no baseline the first job is finding where people actually slow down.