Tax software is a user-experience problem wearing a maths costume
The arithmetic in a tax return was a solved problem decades ago. Everything that still makes filing miserable is a design choice, made by someone, on purpose.
Every filing season, somewhere in the middle, there is a screen that asks a question you cannot answer. Not because the answer is unknowable — because the question uses a phrase that appears nowhere outside this context, offers no example, and has a help link that opens a page repeating the phrase in a slightly longer sentence.
You sit there. You open a second tab. Twenty minutes later you've read three forum threads and a government page, and you now know the answer is "no."
The maths, once the inputs are finally supplied, takes a computer approximately no time at all. The maths was never the problem. The problem was the twenty minutes, and the twenty minutes was a design decision.
The costume
Tax software presents itself as a computational product. The marketing is about accuracy, about calculations, about getting the number right. Guarantees are framed around correctness of arithmetic.
This is a strange thing to compete on, because arithmetic is the easy part. Any of these products can compute a return correctly given correct inputs. That capability has been commoditised for decades. What differs — enormously, product to product — is how hard it is to supply the inputs.
The hard problem was never "what is the number." It's "what is this question asking me, and does it apply to my life."
That's a translation problem. It's about turning statutory language into questions a person can answer about their own year. And translation is design work, not computation.
Four patterns that turn up everywhere
1. The vocabulary of the form leaks into the interface
The single most common failure. The underlying legal document has precise terms of art. Those terms get lifted into the interface unchanged, on the reasonable-sounding grounds that changing them risks inaccuracy.
But the user isn't a form. They have a life, described in ordinary words. A well-designed question asks about the life — did you pay someone to look after your child while you worked? — and does the mapping to terminology invisibly. A badly designed one asks about the form and makes the user do the mapping, which is the hardest part of the entire task and the part they're least equipped for.
2. Progress is shown, but not scope
Almost every product has a progress indicator. Very few tell you, at the start, how long this will be for someone like you.
These are different. A progress bar tells you where you are inside an unknown quantity. Scope tells you what you're committing to. The absence of scope is why filing feels open-ended and slightly dreadful — you never know if you're twenty minutes from done or two hours.
I don't think this omission is accidental. Telling someone at the start that their situation involves ninety screens is honest and would reduce the number of people who begin.
3. The refund counter
The running total that ticks up as you enter information. It's the most emotionally effective element in the entire product and I find it genuinely troubling.
It turns a compliance task into a slot machine. Each entry produces immediate feedback in the form of a number going up or down, which is engaging, which keeps people moving through screens. As a mechanism for completion it works brilliantly.
But it also attaches emotional weight to intermediate states that are meaningless. The number halfway through your return isn't a fact about anything; it's an artefact of the order the questions happen to come in. Watching it drop when you enter a second income makes that income feel like a punishment, which is not a helpful frame for accurate reporting.
4. Price at the end
There is a separate essay on this site about it, so I'll be brief. The pricing decision arrives after the work is done, when the cost of leaving is highest. Every product does it. It converts better. It is, straightforwardly, a design choice optimised against the user's interest, and describing it as anything else is generous.
What good looks like
This shouldn't be entirely negative, because there is real craft in these products too.
Importing data directly from an employer or a broker, when it works, eliminates an entire category of transcription error and takes a twenty-minute task to thirty seconds. That's substantial engineering effort spent purely on removing work from the user, and it is arguably the single best thing to happen to consumer filing.
Plain-language summaries at the end — here is what we concluded and why — are also genuinely good when done well. They turn an opaque output into something you can check.
And a small thing worth appreciating: products that let you skip a section and come back. The ability to say "I don't have that document yet" without losing your place respects that filing happens in an actual life with interruptions.
Why it stays bad
The uncomfortable part is that the incentives don't reliably point at clarity.
A product that made filing feel trivially easy for simple situations would have a harder time upselling. A product that told you your scope at the start would lose people at the start. A product without a live refund counter would have lower completion. Each individual decision has a defensible business case, and the accumulation is the experience we all have every spring.
I'm not accusing anyone of villainy. It is easy to see how this happens without anyone intending it — nobody proposes making a product worse, they propose a series of individually reasonable improvements to a metric, and the sum is the thing.
What I'd ask for
One thing, if I could only have one: scope up front. Three or four questions at the very beginning, then a plain statement — this will take about this long, cover about this much, and cost about this amount.
Every one of those numbers is already known to the product. Withholding them isn't a technical limitation. It's a decision about what the user is allowed to know before they're committed.
Fix that and I'd forgive most of the rest.
What this isn't
Not a product review and not a recommendation. This is about interface patterns that recur across tax filing products generally.
Bias, declared
I am predisposed to read these products as design decisions rather than as legal requirements. Treat that as a bias in what follows.
Found an error?
Corrections get made in the text with a dated note. Tell me what's wrong.