Drake — Web Pilot

Drake's first-ever Pilot Program.

Roles

  • UX Design
  • Researcher
  • Page Copy
  • Information Architecture

Visit Drake Website

Drake Web Pilot Program

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 and constraints 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 demonstrated Research planning, moderated qualitative sessions, rapid synthesis, cross-platform workflow reasoning, error prevention UX, stakeholder alignment

Working with a large cohort of Drake users to craft the next generation of tax prep software.

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.

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
    Baseline: Users hesitated to start in web because they did not trust the desktop handoff
    Change: Ownership states and locking behavior made explicit in the UI
    Evidence: Office hours themes and fewer "what happens if" questions
  • Error prevention
    Baseline: Return locking was unclear, leading to lost work and frustrated support contacts
    Change: State indicators plus a clarified handoff model at the moment of decision
    Evidence: Fewer lock conflict moments observed in session data and office hours notes
  • Research infrastructure
    Baseline: No structured feedback loop for a brand-new web user base
    Change: Repeatable office hours model plus a mixed-method research plan for the season
    Evidence: 100+ tax pros recruited, two office hours 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

Home
Next

Get in touch

I'd love the opportunity to discuss how my skills and experience can align with and support your organization's goals.

Contact me