Building the Content Architecture for an AI Tax Platform
SmartRequestAI automated one of the most complex workflows in tax preparation. With no dedicated UX team and engineering already underway, I defined the content architecture that let accountants trust AI-generated workpapers — turning an unstructured, undocumented process into a scalable content system used by hundreds of firms.
No content model, no UX team, engineering already underway
SmartRequestAI uses AI to scan a client's prior-year tax return, generate a personalized document request list, and auto-organize uploaded files into SmartVault — delivering prep-ready workpapers before tax preparation begins. It was one of the most conditional-logic-heavy workflows in the product: hundreds of possible document types, each with its own eligibility rules, phrasing, and edge cases, all of which had to resolve into plain-English requests an accountant's client could actually understand.
Engineering had already begun development when I joined. There was no established content model, no dedicated UX designer, and no existing pattern for how AI-generated output should read or be trusted by the accountants using it. I had to define the content architecture while the feature itself was still evolving — reverse-engineering structure from a build already in motion rather than designing ahead of it.
With no dedicated design function on the team, I identified the gap, recruited an external UX designer, and established the working model between us — setting direction on structure and content while partnering on interaction design. I owned every word a user would see, from the client-facing questionnaire to the accountant's output document.
An Excel file as the content model — content systems design, not content design
The entire feature was built from a shared Excel blueprint — a structured file every developer, designer, and stakeholder worked from simultaneously. Engineering used it to build the data model and apply conditional logic. I used the same file to define every piece of content users would see: page titles, page descriptions, group labels, question text, field labels, and answer options across every tab of the feature.
That distinction matters. I wasn't writing isolated strings — I was defining the structure that content lived in: how fields related to each other, how conditional logic mapped to plain-language output, and how a single source of truth stayed synchronized between what engineering built and what users read. It's closer to information architecture than traditional UX writing.
Key decisions:
Why I used the engineering blueprint instead of a separate content doc: A parallel content spec would have drifted from the data model within weeks, given how often the conditional logic changed mid-build. Working inside the same file engineering used meant content and logic couldn't fall out of sync — the trade-off was writing content in a format built for structured data, not prose.
Why one field per row for the workpaper (over a denser layout): A denser layout would have fit more on a page, but accountants scan under time pressure during tax season. I chose scannability over compactness after hearing directly from the Customer Advisory Council that speed mattered more than length.
Why green-bar styling over SmartVault's corporate blue: Corporate branding would have been the safer, more consistent choice. I chose familiarity to the task over brand consistency, because the workpaper's job was to feel instantly usable to accountants trained on decades of green-bar paper — not to reinforce the SmartVault brand.
This file was, functionally, a content model — structured fields with defined types, relationships, and conditional logic. Every label I wrote here rendered directly in the live product. Getting it right meant the product shipped right.
Writing for accountants and their clients simultaneously
The questionnaire served two audiences: accounting professionals who needed clean, structured data, and their clients — everyday taxpayers who needed reassurance and clarity. Every label had to work for both.
One deliberate decision: income source checkboxes include the IRS form numbers in parentheses — "Brokerage accounts (1099-B, Consolidated-1099, Brokerage statement)" — because clients receive physical documents with those form numbers. Matching the label to what they hold in their hands reduces confusion and increases upload accuracy.
Designing the output — a 38-page document built for how accountants work
The most visible deliverable wasn't a screen — it was a PDF workpaper used during tax preparation. I was shown a competitor's template as a starting point. It was functional but dense: multiple fields per row, difficult to scan under time pressure.
I asked a Customer Advisory Council member one question that changed everything:
"We don't care how long it is. We just want each field on one row so we can move faster."
One field per row. I also researched how accountants interact with paper — green bar paper has been the standard for financial record-keeping for decades, designed to reduce eye strain across long data columns. I chose green tones over SmartVault's corporate blue palette to signal familiarity to the people using it.
After iterating on several directions, the design was approved by my manager, the company president, and all Customer Advisory Council stakeholders. Product used my 38-page PDF as the definitive template for field mapping throughout development.
A scalable content system, not just a shipped feature
Beyond the blueprint and workpaper, I wrote all onboarding flows, release notes, and knowledge base articles, and coordinated with Engineering to ensure copy rendered correctly in production on launch day. I also unified two separate features (Request Docs and SmartRequestAI) into a single Doc Requests landing page with tabbed navigation — reducing the number of places a user had to look to complete one task.
SmartRequestAI launched in November 2025, reclaiming 60–90 minutes per return for accounting firms processing hundreds of returns per season. More than the launch itself, the shared blueprint model — content and logic living in one source of truth — became the pattern the team reused for future builds, reducing the risk of content and functionality drifting apart as the product continues to evolve.