· personal  · 3 min read

Building Tools for a Law Firm Taught Me More About UX Than Any Tech Job

DRAFT

Outline

Hook: Lawyers don’t care about your tech stack. They care about winning cases. Building tools for a law firm taught me: The best UX is invisible, users want results not features, and “intuitive” means “works like what they already know.”

Core Argument: Non-technical professionals are the ultimate UX teachers because they won’t tolerate complexity, they’ll tell you exactly what’s broken, and they measure value in outcomes not features. If you can design for lawyers who bill $500/hour, you can design for anyone.

Key Sections:

  1. The Context: Why Law Firms Are Design Hard Mode

    • Billable hours: Every minute matters
    • High stakes: Mistakes cost clients money or cases
    • Low tech tolerance: They’re experts in law, not software
    • Workflow inertia: “We’ve always done it this way”
    • The challenge: Make new tool faster than old process

  2. Lesson #1: Features Are Liabilities, Not Assets

    • Lawyers wanted: Search cases, generate summaries, find precedents
    • I built: 15 features, complex dashboard, tons of options
    • Reality: They used 3 features, ignored the rest
    • The problem: Every feature is a decision point, click, training burden
    • The fix: Cut to 5 core features, hide advanced options
    • Takeaway: Subtract until it hurts, then subtract more

  3. Lesson #2: “Intuitive” Means “Like What I Already Know”

    • My idea: New AI-powered interface paradigm
    • Their reaction: “Where’s the search box? This is confusing.”
    • The reality: Innovation in UX = friction
    • The fix: Make it look like tools they use (Word, Google)
    • Takeaway: Don’t reinvent UX unless the old way is genuinely broken

  4. Lesson #3: Users Don’t Want AI, They Want Better Outcomes

    • Me: “This uses GPT-4 and vector embeddings!”
    • Them: “Okay… does it find relevant cases faster?”
    • The lesson: Nobody cares about the how, only the what
    • Examples: Don’t say “AI-powered,” say “Finds answers in seconds”
    • Takeaway: Sell outcomes, not technology

  5. Lesson #4: Error Messages Are UX Design

    • Bad: “Error 500: Null reference exception”
    • Better: “Something went wrong. Try again.”
    • Best: “Couldn’t find cases matching ‘X’. Try different keywords.”
    • Why it matters: Errors break flow, good errors guide users back
    • Plus: Actionable error messages reduce support tickets

  6. Lesson #5: Fast > Pretty > Clever

    • Lawyers will tolerate ugly if it’s fast
    • They won’t tolerate slow, even if it’s beautiful
    • Speed hierarchy: Instant > 1 second > 3 seconds > Death
    • What we optimized: Search speed, page load, document processing
    • Result: “It’s fast” became their favorite compliment

  7. Lesson #6: Support Requests Are Feature Requests in Disguise

    • “How do I…?” → Missing feature or bad UX
    • “It doesn’t…” → Broken expectation or edge case
    • “Can you make it…?” → Real feature request
    • Tracking: Spreadsheet of every support question
    • Result: Top 10 questions → Top 10 UX improvements

  8. Lesson #7: Users Will Break Things You Thought Were Impossible

    • Lawyers found edge cases I never imagined
    • Uploaded 500MB files (I expected 10MB)
    • Searched for symbols that broke parsing
    • Wanted to export 10,000 results (I built for 100)
    • Takeaway: Your assumptions about usage are wrong

  9. What I’d Do Differently

    • Start with just 3 features, ship in 2 weeks
    • Shadow users for a day before designing anything
    • Build error handling first, features second
    • Optimize for speed from day one, not “later”
    • Weekly user feedback sessions, not quarterly

Examples/Stories:

  • Success: Reducing 30-minute research task to 2 minutes
  • Failure: Fancy AI feature nobody used because too complex
  • Support story: Most common question → became default behavior
  • Edge case: Lawyer broke system in way that made no sense
  • Win: Partner said “I can’t work without this now”

Takeaways:

  • Non-tech users are your best UX teachers
  • Features subtract value unless they’re essential
  • Fast beats pretty, outcomes beat features
  • “Intuitive” = familiar, not innovative
  • Track support requests → they tell you what to fix
  • Build for real usage patterns, not imagined ones

Cross-Links:

  • ← “Reverse Real Estate Matchmaking” (Series 2-14)
  • → “Why I Don’t Trust Vibes-Only Startups” (Series 2-16)
  • → “How to Design Products for Non-Tech People” (Series 2-19)
  • ← “From Legal Memos to Dream Circuits” (Series 1-9)
Share:
Back to Blog