Home

Drake: Web Pilot

Drake's first product pilot program, validated with 100+ professionals during live tax season.

My role Sole designer and researcher, responsible for defining the research plan, facilitating participant feedback sessions, and shaping early UX direction for Drake's first web pilot
Scope PM + engineering + pilot participants | Tax-season pilot | Web to desktop handoff states, return ownership, locking messaging, office-hours research loop
Challenges Highly change-averse user base, a new web product running alongside a mature desktop workflow, and the need to validate interoperability behaviors during an active tax season
Impact Established a structured research approach, gathered direct feedback through office hours, and informed early product decisions around interoperability and return-locking behavior to reduce confusion and prevent errors
Skills Research planning, moderated qualitative sessions, rapid synthesis, cross-platform workflow reasoning, error prevention UX, stakeholder alignment

I owned the research plan for Drake's first web pilot, using mixed methods across the season and lightweight touchpoints to stay close to users. We ran two drop-in office hours sessions to capture initial issues, insights, and questions in a group setting.

Our first feature was interoperability: starting a return on the web and continuing it in the legacy desktop product without losing momentum.

The next feature we were researching and ideating on was whether to "lock" a return when opened. This is what I'm able to show in the images below.

A scenario map for locking a return.

The diagram above maps the access challenges we identified in multi-preparer firms and the design directions it revealed. Rather than prescribe a single behavior, we designed an org-level control with administrative oversight.

Key decisions Summary: ownership visibility, proactive locking rules, office hours feedback loop
Make ownership and locking visible at the moment of action
DecisionSurfaced return ownership and lock state directly in the workflow so users could predict what would happen before switching platforms
TradeoffDid not redesign the underlying locking model during the pilot, focused on clarity and guardrails in the UI
WhyHigh consequence work and a live pilot required fast clarity without destabilizing behavior
ResultFewer "what happens if" questions and fewer lock conflict moments during the pilot
Communicate locking rules proactively, not only as errors
DecisionExplained handoff and lock rules before users committed instead of only showing messages after a conflict
TradeoffAdded copy and UI states that needed careful review instead of keeping screens minimal
WhyLost work is unacceptable in this domain, prevention mattered more than a perfectly clean UI
ResultImproved predictability in handoff scenarios and fewer lock related support moments in feedback
Build a repeatable feedback loop for the season
DecisionEstablished office hours as a repeatable research channel paired with lightweight instrumentation around lock states
TradeoffLess depth per participant than long 1:1 studies in exchange for faster signal and broader coverage
WhyA brand-new web product needed ongoing signal, not a single research event
Result100+ tax pros recruited, two office hours sessions run, synthesis delivered to product and engineering
Outcomes Summary: 100+ recruited, 2 office hours sessions, fewer lock conflict moments
100+
Tax pros recruited
2
Office hours sessions
Fewer
Lock conflicts
  • Interoperability confidence — Users hesitated to start in web because they did not trust the desktop handoff. Ownership states and locking behavior made explicit in the UI. Confirmed through office hours themes and fewer "what happens if" questions.
  • Error prevention — Return locking was unclear, leading to lost work. State indicators plus a clarified handoff model at the moment of decision. Fewer lock conflict moments observed in session data and office hours notes.
  • Research infrastructure — No structured feedback loop existed for a brand-new web user base. Repeatable office hours model plus a mixed-method research plan for the season. 100+ tax pros recruited, two sessions run, synthesis shared with PM and engineering.
What changed in the product
  • Interoperability behaviors were made explicit in the UI rather than assumed
  • Return ownership states were surfaced when users needed to decide on a handoff
  • Locking rules were communicated proactively, not only as error states
How we measured

Moderated office hours sessions, tagged qualitative themes, and event instrumentation around handoff and lock states during the pilot window

"I'd rather change religions than change my tax software."

— Drake Desktop Pro User