askTax - Designing an AI tax assistant people can actually act on

Thesis: For an AI tax assistant, the product isn't the answer. It's the evidence. The chat UI was the easy part. The hard part was making every response auditable enough that a specialist would stake a client filing on it, and still readable enough for a salesperson.

For the reader: If you're hiring a product designer who treats trust, accessibility, and design-to-build fidelity as design problems from day one, this one's for you.

---

01Project Overview & Context

The hook

Most AI chatbot designs optimize for the answer. In corporate tax, that's backwards. A confident answer you can't trace to a primary source is worse than no answer. It creates false confidence in a domain where being wrong is expensive and slow to discover.

askTax is a design concept for an internal AI tax assistant built on the opposite premise. The answer is the cheap part. My job was to surround it with enough evidence, freshness, and verification that a professional would act on it.

It's one product for two very different people. The corporate tax specialist wants depth, citations, and jurisdiction control. Everyone else in the company (PMs, sales, support, engineers) needs plain-language answers and help using the company's own apps.

My role

Solo Product Designer, end to end. I owned:

• Problem framing and the dual-persona definition
• Information architecture across ~10 screens (employee app + back-office "Studio")
• Interaction and visual design, including the trust/citation system
• The design system: tokens, type scale, spacing, color, component library
• Accessibility (WCAG AA contrast, focus, touch targets)
• A build-ready spec in shadcn/Tailwind token vocabulary
• Running a structured, multi-model design critique loop and acting on what it found

Timeline & tools

• Timeframe: A focused design sprint in May 2026. Two structured review rounds on the core flow, plus a first round on the extended/back-office screens.
• Tools: A multi-model design-review orchestrator (Claude, Gemini, and Codex each scoring the comps against a 10-dimension rubric), HTML/CSS comps as the working medium, Inter, an 8px spacing system, and shadcn/ui + Tailwind HSL design tokens as the build target.
• Surfaces designed: Desktop (1440×900) and mobile (390×844), responsive.

---

02The Problem Statement

The challenge

The company wanted every employee to understand what the company does. At the same time, it needed its tax specialists to work faster and more defensibly. So one brief, with a contradiction built in:

• Specialists need depth: real citations (IRC sections, internal memos, state guidance), jurisdiction awareness (Federal + state), freshness ("is this still current law?"), and a way to escalate edge cases.
• Everyone else needs the opposite: plain-language answers and step-by-step help with the company's 12 internal apps, without the tax jargon.

A generic LLM chat window fails both groups. Specialists get answers they can't trust or trace. Non-specialists get a blank box and no idea what to ask.

So the question was: how do you build one surface that stretches from "auditable enough to file against" to "simple enough for a new hire," without splitting into two products and two knowledge bases?

Objectives

1. Make answers trustworthy and auditable. Every claim traces to a primary source, with visible freshness, jurisdiction, and human verification.
2. Serve both audiences from one surface. Adjustable depth and role instead of a separate "lite" app.
3. Turn "how do I use our apps" into doing, not reading. Guided, in-context walkthroughs for the 12 internal apps.
4. Be accessible for real. Clear WCAG AA, working focus states, mobile-safe touch targets.
5. Ship a build spec, not a picture. Design in the same token system engineers would implement (Next.js + shadcn/ui + Tailwind).

---

03Process & Methodology

Research & insights (framing and validation)

I started by splitting the audience in two: a primary power user (the tax specialist) and a secondary literacy user (developer, PM, sales, support). Almost every decision after that depended on which one a screen was serving. And I kept finding that the same screen usually had to serve both.

The competitive frame was the generic AI chatbot. In this domain, it fails in predictable ways. A "Sources" list dumped at the bottom, or none at all. No idea of jurisdiction or effective date. No sign a human checked anything. And a blank input that gives non-experts nothing to start with. I turned each of those failures into a design requirement.

For validation, I used a structured multi-model expert review instead of one opinion. Three models (Claude, Gemini, Codex) scored each round of comps independently against a 10-criterion rubric: Visual, Typography, Color, Accessibility, Usability, Information density, Consistency, Responsiveness, Interaction, and Emotional tone. That gave me a repeatable score and a ranked punch list for every iteration. Expert review is an early-stage method, and I chose it on purpose. Testing with real specialists and non-specialists is the next step (see What I'd do differently).

Iteration: review rounds, not guesses

I treated each round like a test with a score to beat. The rubric told me what to fix next.

Core workspace (Ask / Guides / Saved):

Round	Score (avg / 100)	Weakest dimensions going in
1	81.7	Color contrast, Accessibility
2	80.7	Interaction, Accessibility (next layer)

What I changed between Round 1 and Round 2:

• Contrast: Muted metadata text was #838c9b (~3.5:1 on white), under the 4.5:1 AA floor. I darkened it to #5b6472 (~6:1), so the 11-13px labels every reviewer flagged now pass AA.
• Focus: Added a visible focus ring and caret on the composer that doesn't rely on color, for keyboard users.
• Touch targets: Mobile action buttons, send, and filter chips were ~38px. I bumped them to the 44px minimum.
• Concreteness: Swapped a placeholder guide thumbnail for a faux FilingHub mini-UI (a verified CA row, an active NY row, an "add state" row). Now the "do it with me" step shows something real instead of an icon.
• Guardrail copy: Added an inline disclaimer ("confirm against primary sources before filing") without breaking the layout.

The overall score went down a little (81.7 → 80.7), even though accessibility got better. Fixing the obvious problems let the rubric find the next layer: answer lines running ~80 characters (the measure should tighten to ~680px), no breadcrumb or location cues on Guides and Saved, loose whitespace in the Saved grid on wide screens, and no empty, loading, or streaming states. I'll take that. The point of the rubric is to keep finding the next most important thing.

Extended / back-office ("askTax Studio"): The first review round scored 70.7. The source/citation viewer and the in-app companion scored well. The gaps to fix next: mobile coverage for Knowledge browse and History, denser back-office tables that need zebra rows and sticky headers, and more consistent focus states across tables and toggles.

Design decisions (the why)

Five decisions mattered most.

1. Citations sit inline with each claim, not in a footnote. Each claim carries numbered chips: [1] IRC §41, [2] Internal Memo TM-204, [3] CA FTB Pub 1001. A dedicated source viewer puts the answer next to the actual statute text, with the operative passage highlighted and an effective date. Considered instead: The LLM default, a generic "Sources" list at the bottom. Why: In tax, being able to trace each claim is the product. The AI stops being an oracle and becomes a research assistant you can audit. A specialist can check the source right there instead of trusting blindly.

2. Verification and escalation live inside the answer. Every answer shows an "As of Apr 2026" date, a jurisdiction tag (Federal + CA), a green "✓ Verified by Tax Team" badge, and a "Flag for SME review" (subject-matter expert) action. Considered instead: Handling verification as a separate QA process outside the chat. Why: Tax answers go stale when the law changes, and they vary by jurisdiction. Freshness and scope are part of what the answer means. Putting them inline tells people how much to trust this answer. And the flag makes every user a sensor that feeds the content team's gap list.

3. One surface for two audiences, using role and depth controls. A role selector (Specialist) and a jurisdiction pill sit in the composer and left rail. Suggestion chips ("For your role," "People also ask") change based on who's asking. Considered instead: A separate "lite" experience for non-specialists. Why: Two products means double the maintenance and a split knowledge base. Treating role and jurisdiction as lenses on one answer engine keeps a single source of truth. It still flexes from specialist depth to plain language. And the suggestion chips fix the blank-box problem for non-experts.

4. "How do I use our apps" becomes a guided walkthrough, not a doc site. The Guides surface has a 12-app picker, step-by-step checklists with progress ("Step 2 of 5"), and a "Show me" vs "Do it with me" toggle. An in-app companion docks askTax beside the live app and ties the current step to what's highlighted ("click New York"). Considered instead: Linking out to static help docs or a wiki. Why: People learn procedures by doing them. Guidance that points at the real UI is what sets this apart from both a generic chatbot and a knowledge base.

5. Design in shadcn/Tailwind tokens from day one, so the comp is the build spec. HSL tokens (--background, --foreground, --muted, --primary, --border, --radius), Inter, an 8px spacing system, and one indigo accent (#4F46E5), with green for verified and amber for flagged. Considered instead: Designing freely and handing off for interpretation. Why: The build target was Next.js + shadcn/ui. Designing in the same token vocabulary closes most of the design-to-dev gap. Accessibility decisions (contrast, focus, target size) get made in the same units engineers ship.

---

04The Final Solution

A responsive, tokenized system covering the employee app and a back-office Studio. The visual language is modern fintech: crisp neutrals, one indigo accent, strong type hierarchy, subtle borders instead of heavy shadows, and a focus on clear data.

The employee app

• Ask: A focused conversation thread. Each answer is structured (headline, short paragraphs, bullets) and carries inline citation chips, an "As of / jurisdiction / ✓ Verified" metadata row, and an action bar (Bookmark · Copy · 👍 · 👎 · Flag for SME review · Draft client explanation). Suggested-question chips handle the cold start. The composer exposes jurisdiction and role/depth controls.
• Guides: A 12-app picker plus a step panel with a numbered checklist (done / current / upcoming), an instruction for each step, a mini-UI thumbnail of the real app, an "Open in [app]" button, the Show me / Do it with me toggle, and a "Stuck? Contact support" escalation.
• Saved: A searchable, filterable library. A collections sidebar (All, R&D Credits, State Nexus, Client FAQs, Shared with me) and a card grid. Each card shows the question, a snippet, source count, jurisdiction tag, verified badge, date, and tags.

The back-office ("askTax Studio")

A dark-rail surface that looks different but reuses the same component system. It holds the source/citation viewer (answer beside the real statute text, operative passage highlighted, effective date), the in-app companion docked beside the live app, and an admin gaps dashboard. The dashboard surfaces low-confidence and no-source questions with ask volume and coverage bars. That's signal the content team can act on, not vanity metrics.

Implementation reality

Designed for desktop (1440×900) and mobile (390×844). On phones it drops to a bottom tab bar, a full-width composer, and stacked cards. Everything is expressed in shadcn-ready HSL tokens, Inter, 8px spacing, and shadcn default radii, so the comps double as the implementation spec for a Next.js + shadcn/ui + Tailwind build.

---

05Outcome & Impact

What changed

The result is a complete, build-ready design language for an AI tax assistant. The trust model (inline citations, source viewer, freshness, jurisdiction, human verification, escalation) is the backbone, not something added at the end. The review loop turned "looks good to me" debates into a scored, ranked punch list. Accessibility became something I measured instead of something I assumed.

Honest metrics

This is a design concept validated by structured expert review. So these numbers measure design quality and accessibility, not production business KPIs:

• Design-review quality: The core workspace held at ~81/100 on a 10-dimension multi-model rubric (81.7 → 80.7 as deeper issues surfaced). The back-office baseline was 70.7, with a clear path to improve.
• Accessibility: Muted-text contrast went from 3.5:1 → ~6:1 (passes WCAG AA). Mobile touch targets went from ~38px → 44px. Added visible focus indicators that don't depend on color.
• Concreteness: Replaced placeholder guidance with a realistic app mini-UI, so the "do it with me" model is something you can see instead of something you have to imagine.

Learnings - what I'd do differently

• Design the in-between states first. An AI product lives in its empty, loading, and streaming states, and by Round 2 those were the most-cited gap. Next time I'd storyboard "blank → thinking → streaming → answer → error" before polishing the answer card.
• Test the two-audience bet with real people. Multi-model review is a fast, repeatable early signal. It doesn't replace watching a real specialist and a real salesperson use the same screen. That's the next validation step, and it will either confirm the "one surface, two lenses" decision or kill it.
• Define the verification ops model earlier. Verified badges, Flag for SME, and the gaps dashboard only work if there's a real human-in-the-loop content pipeline behind them. I'd spec that loop alongside the UI, not after.
• Watch out for the average score. A flat or falling composite can hide real progress. Accessibility improved while the average dropped. I'd report per-dimension changes, not just the headline number, so it's clear what actually got better.