gitGood.dev
← Product cases
Product DesignFoundationalFree

Design a Product for Visually Impaired Users

The classic product-design prompt. Interviewers screen for user empathy and a structured, needs-first approach - not feature brainstorming.

Interview prompt

Design a product for people who are visually impaired.

What interviewers evaluate

  • Do you clarify scope before designing (which impairment, what severity, what context)?
  • Do you start from user needs and pain points, or jump to features?
  • Do you segment users and pick a target rather than designing for everyone?
  • Do you prioritize among ideas with explicit criteria, not list everything?
  • Do you define how you'd measure success?

A framework to structure your answer

  1. Clarify - scope the problem: which users (fully blind vs low vision), what context (mobile, home, navigation), any platform/business constraints. Restate the goal.
  2. Users & segments - list candidate user segments and pick one to design for, with a reason (size, underserved, strategic).
  3. Pain points - enumerate the target segment's key pain points/jobs-to-be-done. Prioritize the most acute.
  4. Solutions - brainstorm 2-3 solutions per top pain point; think breadth before depth.
  5. Prioritize - score solutions on impact vs effort (and reach); pick one to detail.
  6. Define success - name the primary metric and a guardrail, and how you'd validate with users.

Strong sample answer

Try structuring your own answer first, then reveal a strong worked example.

Common variants

  • Design a product for elderly users.
  • Design a product for people who are deaf.
  • Design a kitchen for someone who is blind.
  • Improve accessibility of an existing product you know.

Pitfalls to avoid

  • Jumping straight to features ('add voice control!') without scoping the user or the job.
  • Designing for 'all disabled people' instead of picking a target segment.
  • Listing 10 ideas without prioritizing or detailing one.
  • Forgetting to define how you'd measure success.
  • Designing from assumptions instead of acknowledging you'd validate with real users.

Likely follow-ups

  • How would you prioritize if engineering could only build one feature this quarter?
  • What's your riskiest assumption, and how would you test it cheaply?
  • How would you measure success in the first 90 days?