Make a Fintech App Work for Blind and Low-Vision Customers

Quick Overview

A product design prompt asking a PM candidate to pick a fintech app and improve it for blind and low-vision users. It tests segment choice, understanding of sight-dependent money tasks such as sending funds and verifying identity, prioritization, and privacy-aware success metrics.

Make a Fintech App Work for Blind and Low-Vision Customers

Company: Coinbase

Role: Product Manager

Category: Product Design & Strategy

Difficulty: medium

Interview Round: Other

Pick a fintech app you know well and improve it for people with visual impairments. ```hint Follow the costly mistakes Visual impairment covers very different needs, and money tasks differ in how much a mistake costs. Look for the segment and the journey where the current design leans hardest on sight and where an error is most expensive or hardest to undo. ``` ### Clarifying Questions - May I choose Coinbase's own app, or would you prefer a mainstream payments or banking app? - Which users should the work target first: people who are blind and use a screen reader, people with low vision who enlarge or magnify the screen, or people with color-vision deficiency? - Is the goal to remove barriers in journeys the app already has, or to add new features built for these users? - Should I cover the mobile apps, the website, or both? ### What a Strong Answer Covers - A deliberate choice of app and of a segment within visually impaired users, with the reasoning behind both. - The journeys where sight-dependent design causes the costliest failures, such as moving money, verifying identity and reading prices or balances, and the pain points in each. - Prioritized solutions, including the choice between fixing the main app and building a separate accessible mode. - Success metrics centered on independent, error-free task completion, gathered in a way that respects privacy, with guardrails for errors and fraud. - Risks such as speaking financial details aloud, added friction in sensitive flows, and later features quietly breaking accessibility. ### Follow-up Questions - How would you measure results for these users without asking them to disclose a disability, and how would you evaluate a change when the segment is too small for a well-powered A/B test? - An extra spoken confirmation cuts mistaken transfers but slows every transfer down. How do you decide who gets it by default? - How would you keep features that other teams ship next year from undoing this work?

Overview: A product design prompt asking a PM candidate to pick a fintech app and improve it for blind and low-vision users. It tests segment choice, understanding of sight-dependent money tasks such as sending funds and verifying identity, prioritization, and privacy-aware success metrics.

Coinbase logo
Coinbase
Dec 23, 2025
mediumProduct ManagerOtherProduct Design & Strategy
0
0

Pick a fintech app you know well and improve it for people with visual impairments.

Clarifying Questions Guidance

  • May I choose Coinbase's own app, or would you prefer a mainstream payments or banking app?
  • Which users should the work target first: people who are blind and use a screen reader, people with low vision who enlarge or magnify the screen, or people with color-vision deficiency?
  • Is the goal to remove barriers in journeys the app already has, or to add new features built for these users?
  • Should I cover the mobile apps, the website, or both?

What a Strong Answer Covers Guidance

  • A deliberate choice of app and of a segment within visually impaired users, with the reasoning behind both.
  • The journeys where sight-dependent design causes the costliest failures, such as moving money, verifying identity and reading prices or balances, and the pain points in each.
  • Prioritized solutions, including the choice between fixing the main app and building a separate accessible mode.
  • Success metrics centered on independent, error-free task completion, gathered in a way that respects privacy, with guardrails for errors and fraud.
  • Risks such as speaking financial details aloud, added friction in sensitive flows, and later features quietly breaking accessibility.

Follow-up Questions Guidance

  • How would you measure results for these users without asking them to disclose a disability, and how would you evaluate a change when the segment is too small for a well-powered A/B test?
  • An extra spoken confirmation cuts mistaken transfers but slows every transfer down. How do you decide who gets it by default?
  • How would you keep features that other teams ship next year from undoing this work?