· technical  · 3 min read

How to Design Products for People Who Don't Care About Tech (But Need It)

DRAFT

Outline

Hook: Your users don’t care that you used the latest framework or that your AI is “state of the art.” They care that clicking one button saved them 3 hours. Design for outcomes, not technology. Design for humans, not hackers.

Core Argument: Most developers design for themselves—tech-savvy early adopters who tolerate complexity. But the biggest markets are non-technical professionals who just want their job done faster. Design for them by hiding complexity, speaking their language, and obsessing over the outcome, not the implementation.

Key Sections:

  1. The User You’re NOT Designing For

    • You: Comfortable with terminals, loves keyboard shortcuts, reads docs
    • Them: Uses mouse for everything, never reads docs, hates “learning curves”
    • You: Thinks features are benefits
    • Them: Thinks outcomes are benefits
    • The trap: Designing for yourself by accident

  2. Principle #1: Speak Their Language, Not Yours

    • Bad: “Configure API endpoints”
    • Good: “Connect your accounts”
    • Bad: “Initialize database schema”
    • Good: “Set up your workspace”
    • Bad: “AI-powered semantic search”
    • Good: “Find anything instantly”
    • Rule: If you need to explain what a button does, rename it

  3. Principle #2: Eliminate Decisions (Provide Smart Defaults)

    • Every choice = cognitive load = friction
    • Example: Don’t ask “What port?” → Use 3000, let power users change
    • Example: Don’t ask “Which algorithm?” → Pick best one, hide option
    • When to provide options: When it materially affects outcome
    • When to hide options: Always, until proven necessary

  4. Principle #3: Make the Happy Path Impossible to Miss

    • Primary action: Big, obvious, one click
    • Secondary actions: Smaller, less prominent
    • Rare actions: Hidden in menus
    • Visual hierarchy: Size, color, position guide attention
    • Example: Email app → “Send” is huge, “Save draft” is small

  5. Principle #4: Errors Should Feel Like Help, Not Punishment

    • Bad: “Error 422: Validation failed”
    • Good: “Email address looks wrong. Try again?”
    • Bad: “Null pointer exception”
    • Good: “Something went wrong. We’re fixing it.”
    • Include: What happened, why, what to do next
    • Tone: Helpful, not condescending or robotic

  6. Principle #5: Progressive Disclosure (Show Complexity Later)

    • V1: Simple interface, covers 80% of use cases
    • V2: “Advanced” mode for power users
    • Don’t: Show all 50 options on first screen
    • Do: Show 3 options, “More options” link
    • Example: iPhone camera vs. pro camera apps

  7. Principle #6: Speed Matters More Than You Think

    • Non-tech users notice lag more than tech users
    • Why: They assume technology is fast (blame themselves if slow)
    • Loading states: Always show progress
    • Perceived speed: Optimistic UI, skeleton screens
    • Actual speed: Optimize ruthlessly (see: Building Tools for Law Firm)

  8. Principle #7: Onboarding is the Product

    • First 5 minutes: Make or break
    • Goal: One quick win before anything else
    • Don’t: Video tutorial, long form, feature tour
    • Do: Interactive walkthrough, one step at a time
    • Example: Slack → Send one message immediately

  9. Principle #8: Make “Undo” Trivial (Build Confidence)

    • Users fear breaking things
    • Solution: Make everything undoable
    • Delete? → “Restore from trash”
    • Change setting? → “Revert to previous”
    • Psychological impact: More exploration, less fear

  10. Testing with Non-Tech Users

    • Watch them use it (don’t explain)
    • Where do they get stuck? → Fix that
    • What do they click expecting to happen? → Make it happen
    • What do they skip? → Remove it or make it clearer
    • What do they say? → Tells you their mental model

Examples/Stories:

  • Law firm tool: Changed “Run query” to “Search” → usage doubled
  • Personal: Mom couldn’t use early version, made me redesign everything
  • Client: Removed 10 settings, complaints went down (not up)
  • Success: Lawyer said “I didn’t have to learn anything, it just worked”
  • Failure: Built beautiful UI that confused everyone

Takeaways:

  • Design for outcomes, not features
  • Speak their language (outcomes), not yours (tech)
  • Reduce decisions with smart defaults
  • Make happy path obvious, errors helpful
  • Progressive disclosure: Simple first, complex later
  • Speed and “undo” build confidence
  • Test with real non-tech users, fix what confuses them

Cross-Links:

  • ← “From One-Off Project to Sellable SaaS” (Series 2-18)
  • → “Build Once, Leverage Forever” (Series 2-20)
  • ← “Building Tools for a Law Firm” (Series 2-15)
  • ← “Why ‘AI-First’ Doesn’t Mean ‘No Soul’” (Series 1-2)
  • ← “Reverse Real Estate Matchmaking” (Series 2-14)
Share:
Back to Blog