Drake Pay and Refund Pay, designed across three host products for tax professionals and their clients, under contract and consent constraints.
My roleSole designer across the full Drake Pay program, responsible for the payment product experience on Drake Tax desktop, TaxAct Pro, and the web and mobile taxpayer checkout, plus tax professional enrollment, regulated consent flows, and the Drake Pay Manager admin interface
Scope5 PMs across 3 product teams + engineering on 3 sides + QA + legal | 2 audiences (tax professionals, taxpayers) | 3 host products (Drake Tax desktop, TaxAct Pro, web / mobile) | ~114 designed surfaces spanning enrollment, payment requests, §7216 consent, checkout, receipts, admin, and notifications
ChallengesHolding five product managers across three product teams in alignment, designing for two audiences with different mental models, reconciling three host products of different maturities, and satisfying three overlapping regulatory and contractual frameworks (Pathward contract, §7216 consent to Use and Disclose, KYC and AML)
ImpactSole designer on the full program. The Drake-side launch produced a 16% increase in program enrollment by tax professionals, cited on my resume. TaxAct Pro integration, taxpayer checkout, and several edge-case flows were in active development at time of offboarding.
SkillsMulti-product integration design, regulated consent flow design, cross-team stakeholder facilitation across four PMs and three engineering teams, scope discipline for a multi-surface design, state handling for regulated enrollment, graceful edge-case and denial-path design
Drake Pay is a merchant payment product. Refund Pay is a bank product that lets tax professionals have their preparation fee taken out of the taxpayer's federal refund. Both are native to Drake's ecosystem. After the parent organization acquired both Drake and TaxAct, the mandate expanded: extend these products beyond Drake's own surfaces to TaxAct Pro, to the web and mobile taxpayer checkout, and, through the §7216 consent framework, to the moment a taxpayer actually encounters the offer at filing time. I led the design across the full program as the sole designer.
The design problem was not a single UI. It was holding a matrix together. Two audiences (tax professionals and taxpayers). Three host products of different maturities (Drake Tax desktop, TaxAct Pro, and the web and mobile taxpayer checkout). Three overlapping regulatory and contractual frameworks (the Pathward partner contract, the §7216 consent regime, and KYC and AML obligations inherited from the banking partner). Five product managers across three product teams. Every surface had to feel native to its host product, respect its audience's mental model, and satisfy whichever part of the regulatory stack applied.
My opening move was scope discipline. I walked through Drake Pay's existing Drake-native surfaces and marked explicitly which patterns transferred to each host and which did not. That prevented a failure mode I have seen derail other integration work, where acquired-product paradigms get imported wholesale and quietly destabilize the host experience. From there, the work broke into three design beats that I came back to repeatedly: the §7216 two-consent flow for taxpayers, the send-payment-request design as it had to live inside both Drake Tax desktop and TaxAct Pro, and the combined Drake Pay plus Refund Pay enrollment flow for tax professionals. The systems map below lays out the full surface area.
The full surface area of the Drake Pay program. Two audiences, three host products, and the handoff moment when a tax professional who has enrolled then exposes the product to their clients at filing time. All ~114 designed surfaces were sole-designer deliverables.
Treat §7216 consent as two legally distinct moments, not one form
DecisionDesigned the taxpayer consent flow as two separate acts. Consent to Use gates the eligibility check. Consent to Disclose gates the product offer. Added married-filing-jointly variants requiring two signatures. Surfaced the Pathward bank agreement as a distinct step. Designed a denied-consent fallback that returns the taxpayer to the payment page without penalty or friction.
TradeoffLonger taxpayer flow than a single combined consent would be. Three to five screens instead of one, at the point of greatest checkout friction.
Why§7216 carries criminal penalties for preparers who mishandle it, so combining consents would have been a compliance failure. Couples with Married Filing Jointly (MFJ) are a significant portion of the user base, so requiring only one signature would have been a compliance failure for them. Denied consent has to read as a legitimate taxpayer choice, not a broken state.
ResultLegal counsel approved the flow without structural changes. The denied-consent fallback was specifically called out in review for respecting taxpayer agency rather than pressuring them back into the funnel.
Design the same user intent twice, natively in each host product
DecisionDesigned the send-payment-request flow as two native experiences inside Drake Tax desktop and TaxAct Pro. Preserved the Drake Pay mark within dialogs as a cross-product identifier, but embedded everything else in each host's conventions. Marked Drake-native patterns that did not transfer (Portals, ePay) as out of scope explicitly.
TradeoffDesigned the same intent twice, with material differences, rather than a single shared dialog that would have rolled out faster and been cheaper to maintain.
WhyDrake Tax users are long-tenured and change-averse. TaxAct Pro users expect TAP's conventions. A shared dialog would have pleased neither.
ResultBoth flows progressed into engineering and QA. TaxAct Pro's QA lead, the most skeptical stakeholder on the project, signed off on the destructive-action flows after a series of walk-throughs.
Enroll two financial products in one flow rather than two
DecisionDesigned tax professional enrollment as a single entry point offering both Drake Pay (merchant payments) and Refund Pay (preparer-fee-from-refund), with a multi-tab application form handling both products' Pathward KYC and bank-agreement requirements. Designed an alternate layout for tax pros with preexisting bank-product relationships, where Refund Pay surfaced as ineligible with explanation rather than being hidden.
TradeoffLonger form covering two financial products in one sitting. Higher cognitive load than either product's form alone.
WhyTax pros sign up for payment products once per season. Two separate applications would have produced two separate drop-off curves. Explaining Refund Pay ineligibility rather than hiding it preserved trust and reduced downstream support load.
ResultThe Drake-side launch produced a 16% increase in program enrollment by tax professionals.
Regulated consent as design artifact: The §7216 two-consent flow, including MFJ variants, the Pathward bank agreement, and the denied-consent fallback, passed legal review without structural changes.
Cross-product integration: The send-payment-request flow was designed natively for both Drake Tax desktop and TaxAct Pro, preserving the Drake Pay identity without colonizing either host product.
Dual-product enrollment: Drake Pay and Refund Pay were brought into a single tax professional enrollment flow, with graceful handling of ineligibility cases.
Multi-PM facilitation: Held five product managers across three product teams in alignment over the life of the project, alongside engineering, QA, and legal counsel.
What changed in the product
Drake Pay and Refund Pay enrollment was unified into a single tax-pro-facing flow
The send-payment-request experience was natively integrated into both Drake Tax desktop and TaxAct Pro
§7216 consent was surfaced as two distinct moments with MFJ variants and a graceful denied-consent fallback
The Pathward bank agreement appeared as a distinct, visible step rather than being buried in fine print
The taxpayer payment page supported credit card, ACH, PayPal, Venmo, Affirm, and Refund Pay in a single responsive design across web and mobile
How we measured
A 16% increase in tax professional enrollment on the Drake side after the native product launch, cited on my resume, is the primary outcome measure of tax professional demand for the product. Legal counsel approval of the §7216 flow without structural changes served as a compliance check. TaxAct Pro QA signoff on destructive-action flows served as an informal robustness check on edge cases.
