Product Sense: Designing a Trustworthy Voting App, From Choosing the Use Case to Metrics

Design a voting app. Decide what kind of voting it is for and who will use it, then take the interviewer through the problems it solves, what you would build first, and how you would judge whether it is working. ```hint Pick the vote before the app A quick poll among friends and a binding election need very different things. Decide which kind of vote you are serving, and let that choice set how much identity checking, privacy and auditability the product needs. ``` ### Clarifying Questions - Which kind of voting should I target: casual polls among friends or in group chats, decisions inside an organization such as a student union, club or homeowners' association, or binding public elections? - Is this a standalone app, or a voting feature inside an existing social or messaging product? - Must results be binding and auditable, with exactly one verified vote per eligible person, or is a lightweight signal enough? - Is there a target platform or region I should design for? ### What a Strong Answer Covers - A deliberate choice of voting context and primary users, with the reasons the other contexts were set aside - Pain points for both the people running a vote and the people casting one, across setup, eligibility, voting and results - Integrity features matched to the stakes: eligibility checks, one vote per person, ballot secrecy, verifiable results and accessibility - A prioritized first version, with what was deferred and why - Success metrics with guardrails, and the main risks such as fraud, coercion and disputed results ### Follow-up Questions - How would you stop someone from voting twice without making voting harder for everyone else? - Would you show live results while the vote is still open? Why or why not? - What would have to be true before you let the product run binding public elections?