面试聊“产品做不到”，先讲用户卡在哪

有用户评价某产品：遇到做不了的事情时会弹出一个迷你浏览器，把控制权交还给用户，而不是卡住；这位用户还称它是深思熟虑、以人为本的设计。消息提到的是个别用户感受，不代表广泛反馈，也不等于该功能已稳定可用。但如果你准备面试，并想讲清自己处理“产品做不到”场景的思路，这个评价可以当作一个讨论起点。

回答时别一上来就讲兜底文案。先讲用户卡在哪一步：是意图没被理解，还是能力边界之外。再讲你怎么交还控制权：让用户自己继续、换一种方式完成，还是明确告知并退出。最后讲你如何验证这个选择。比如同一个模拟任务：用户让AI整理表格，模型识别不了某个字段。做法A只弹一句“抱歉，我做不到”；做法B标出问题字段，让用户手动补上再继续。两者差别不在文案，而在用户是否还有路可走。面试里讲清你选B的理由和代价，比堆概念更有说服力。 延伸阅读：产品面试通关指南：从需求分析到方案设计

怎么判断“交还控制权”是真设计还是话术

“把控制权交还用户”听起来都对，但面试里要经得起追问。素材里的用户把弹迷你浏览器评价为以人为本，这毕竟是一种观点，不是效果证明。你可以用三个可核查的问题自查：用户能否自己继续下一步？退出成本有多高？失败后是否留下可恢复的路径？

如果答不上来，说明你讲的可能还是话术。真设计会交代取舍：交还控制权可能让流程变长，也可能需要用户多操作一步。你要能说出为什么这个代价值得，以及在什么条件下你会改回更自动的方案。不要断言“这样一定更好”，而是说明你当时依据什么判断、后来用什么信号验证。

作品集里没有失败路径案例，怎么补

不必硬造一个项目。从已有经历里挑一个“当时卡住”的环节，按用户卡点、你的取舍、验证方式三步重写。例如：用户在哪一步失败，你选择让用户手填还是退回上一步，当时观察到什么行为。成果只写实际完成的，比如[实际记录]中的完成率变化；没有数据就写你当时如何判断、后来发现哪里判断错了。

面试前可以做一件小事：拿目标岗位的职位描述，圈出和异常流程、用户控制相关的词，再对照自己的案例，看能不能用三句话说清“用户卡在哪、我交还了什么、我怎么知道这有用”。然后找朋友做一次模拟追问：如果用户不按你预设的方式操作，你怎么办？这比背通用答案更接近真实的设计讨论。