01. Overview
I led the 0-1 design of a modern, cloud-based tax preparation software for professionals and their clients. I'm going to focus on one feature from the experience: the taxpayer review, done after the tax pro has completed the taxes for their client
Lead Designer
My Role
6 months
Timeline
Me + PM + Eng
Team
02. The Customer Problem
We wanted to better understand practitioners—especially their attitude and workflow relating to their interactions with clients. So we visited a dozen firms to ask questions and observe. Here’s a few insights:
“My clients only care about two things: How much they’re getting, and when they’re getting it.”
"It would be huge if I could electronically request banking information."
"Clients expect to be able to do everything on their phones. We’re falling behind the times”
Key Finding
During the short ‘tax season’ window, tax pros are overworked and stressed out. They enjoy the work of preparing returns, but would gladly delegate the rest
There was a lot of directions we could go with this finding, and we brainstormed and evaluated several. We knew what the customers pain points were, and we knew the business needed a relatively quick win, while we continued work on the core product of Tax Prep. Ultimately, we agreed to focus on automating the taxpayer review workflow, where clients reviewed the work the tax pro had done and made their payment. I led the team in crafting this hypothesis statement to keep us grounded moving forward:
Automating the tax return finalization process will save practitioners time and increase their clients’ satisfaction
We referred to this time and time again. It simplified decision-making and kept us focused on our goal. Now it was time for me to take what we’d learned and put a prototype together that we could react to and get feedback on.
03. Prototype + Test + Tweak
I spent a few days putting together a few low-fidelity screens, getting feedback from the team along the way. Once I had something that conveyed the idea we wanted, we walked through it with some internal folks, made some tweaks with the findings, showed it to some more teams, made tweaks, and after a few rounds we were ready to do some testing with customers. But, we hit a snag...
04. The snag
The prototype didn’t feel real enough. We had to use words or hand gestures to explain how it was going to work, introducing bias and limiting our confidence in the usability of the final product.
After some research, I found an advanced prototyping tool (Framer) that allowed me to create robust interactions. I could make it feel real, allowing participants to type, scroll, and navigate with their keyboard, just like the real product would do. This would allow us to test our hypothesis more fully and give us the confidence we needed to build out the real thing.
05. Success!
The prototype tested well, and any concerns from the team were alleviated. There were still a few minor tweaks we made during the build phase, but we kept true to the prototype because we knew how users and their clients felt about it. The clients who use it give it high marks, practitioners love the time savings (~20mins per return) and clients think more highly of their practitioners because of how painless and fast it is.
