EstiMate: Designing trust into an AI co-pilot for an industry that runs on paperwork, not APIs

Go to EstiMate website

Industry

Automotive / InsurTech

Project Duration

2 weeks, 0 → MVP

Role

Product Designer (AI/Conversational UX)

The Problems

Collision repair shops sit on a mountain of financial data — insurance estimates, supplements, deductibles, payments — trapped inside legacy platforms never built to talk to modern software, let alone an AI. Shop owners were manually piecing together whether they’d actually been paid for a job.

The founder’s bet was an AI co-pilot: ask it a question in plain language, get a straight answer, pulled from data that used to take a human twenty minutes to reconstruct. My job was to design the layer where a language model meets a person who has never used one — and make that meeting feel obviously useful on the first try.

Why this was an AI design problem, not just a UI problem

Most of the hard design decisions weren’t about layout — they were about how an AI system should behave when it’s dealing with real money and imperfect data:

  • Grounding, not hallucination. The AI had to answer in the language of the industry (“AWF files,” “supplements,” “deductibles”) using data extracted from dense XML/BMS payloads — never generic or approximate. I worked closely with engineering on what the model needed as context versus what belonged in structured UI, so the chat interface wasn’t asked to do more than it reliably could.
  • Calibrating trust. A shop manager needs to know the difference between “the AI is telling you this” and “this is a confirmed, reconciled payment.” I designed explicit visual states for confidence and confirmation, so the product never let a conversational answer masquerade as verified fact.
  • Designing for a first-time AI user. The audience wasn’t early adopters — it was shop managers who’d never used a conversational tool for anything beyond texting. The chat UX had to be familiar enough (deliberately “ChatGPT-style”) to require zero onboarding, while still guiding people toward the questions the AI could actually answer well.

Process

1. Modeling the domain before modeling the conversation

Before designing a single chat bubble, I mapped what shop owners actually needed to know — what counts as “paid,” what a supplement changes, when a claim is actually resolved — so the AI’s answers could be scoped to real decisions, not just data retrieval. This became the backbone of both the prompt design and the UI’s information hierarchy.

2. Prototyping the AI experience before the AI existed

The model integration wasn’t production-ready yet, so I built high-fidelity Figma prototypes that simulated full conversational exchanges — realistic queries, realistic AI responses, real industry terminology. This let us pressure-test the interaction design of the AI — tone, response length, what it should proactively surface — independent of the engineering timeline, and let the founder demo a believable AI product to investors and pilot shops months early.

3. Designing the “single source of truth” surface: PaymentTrack

Conversational AI is powerful but non-visual by nature — people still need a place to see the full picture at a glance. PaymentTrack was designed as the structured counterpart to the chat: a dashboard that made “are we getting paid” scannable in seconds, and gave the AI a visual home base to reference back to (“as shown in your PaymentTrack summary…”).

4. Designing the failure and confidence states

AI products live or die on how they handle uncertainty. I designed explicit states for: data still syncing, data extracted but unconfirmed, and fully reconciled — so the AI was never in a position to imply certainty it didn’t have. This mattered even more given the domain: this product was gated by security and compliance requirements (SOC 2 Type II, CCC Secure Share), and the interface needed to visually earn that same rigor.

5. Restraint as a design principle

The temptation with AI products is to make the interface feel “smart” everywhere. I pushed the opposite direction — a familiar, minimal chat surface, AI used only where it beat a form or a table, and structured UI everywhere else. The AI was a tool inside the product, not the whole personality of it.

Outcome

In three months, the founder went from an idea and a domain insight to a live, demoable AI product in beta:

  • Moved from pitching a concept to demoing a working AI co-pilot in front of investors and pilot shops — before the full backend was even finished.
  • The prototype-first approach validated the conversational experience early, catching tone and scope issues before they were baked into a trained model.
  • Shipped a product where AI-generated answers and verified financial data were visually distinct by design — a trust decision, not just a styling one.

What this taught me about designing AI products

The hardest part of this project was never making the AI feel impressive — it was making sure it never felt more confident than it should. In domains where AI touches money, health, or legal outcomes, the design job shifts: less about showcasing intelligence, more about drawing honest boundaries around it, and building the UI that makes those boundaries legible to someone who has every reason not to trust a chatbot with their paycheck.