产品迭代案例：记账 App 的5步迭代过程

更新时间：2026年10月22日

一次产品迭代，需要把用户问题、解决方案、原型、反馈和下一轮决定连起来。功能做得更多、界面变得更漂亮，都不能单独说明问题已经解决。关键是先明确这次想改善哪项任务，再用相应证据判断是否继续。

下面沿着一款记账 App 的五步迭代过程，讨论“记录一笔日常支出”这个任务。团队可以在 Boardmix 博思白板中组织问题、方案草图和反馈记录，让设计、开发与业务成员看到同一条判断过程。案例用于说明如何作取舍，具体需求仍需用实际研究确认。

1. 了解用户需求：把业务愿望还原成具体任务

可以通过用户访谈、问卷和使用观察了解现有做法。对记账 App，先问用户在什么场景记账、需要保留哪些信息、哪里容易中断；不要一上来就问“你想要语音记账吗”，把解决方式提前塞进问题。

“日活较低”“变现方式单一”是业务关注点；“买完午餐后，想记下支出，却不清楚从哪里开始”才是可以观察的使用任务。两者可能有关，但需要研究建立联系，不能直接把业务指标当作用户需求。

待核问题	怎样获取线索	暂不能直接得出的结论
入口是否难找	请用户从首页开始记录一笔支出，观察首先寻找和点击哪里。	没有立即点击，不一定说明需要更大或更亮的按钮。
填写是否费力	观察金额、类别、日期等字段的理解与修改过程。	步骤多不一定都多余，需区分必要确认与重复输入。
是否担心数据使用	询问用户对权限、数据保存和分享范围的具体疑问。	增加品牌标识或安全感文案不能替代实际数据规则。

这一轮可先聚焦“完成一笔普通支出记录，并能确认记录正确”。自动读取账单、理财服务和会员经营属于其他问题，需要独立判断，不与本轮录入流程一起无限扩张。

问题明确后，用头脑风暴收集候选方案，再按任务收益、实现条件和风险进行取舍。便签可以分别写“想解决什么”“准备怎么做”“还不确定什么”，避免只留下功能名称。

针对记录支出，可以考虑三个方向：

假设团队本轮先做前两项，就应同时写明暂不做的内容及理由：先看手动录入的入口与字段是否清楚，再决定是否需要新增输入方式。这样一次原型测试能回答具体问题，结果也较容易解释。

早期原型可以是纸面草图或低保真线框。Boardmix 的图形、文本和连接线适合把页面草图与流程放在一起讨论；需要更细的交互验证时，再选择适合的原型形式。不要为了测试一个入口，先制作全部业务页面。

记账任务可以先串联四个画面：首页找到入口、输入支出、确认保存结果、查看并修改记录。至少包含金额为空、类别选错或用户中途退出等与本轮问题直接相关的情况。未实现的分支提前标记，组织测试时避免把原型限制误判成产品问题。

原型细节可以沿着四个方向检查：记账入口是否容易定位，金额与类别是否便于读取，填写后是否清楚已保存，发现错误后是否知道如何修改。卡片布局、文字大小和底部导航都是可选设计手段，不是天然有效的结论。

如果同时改变入口、配色、字段顺序和提示方式，测试发现变化后就难以判断主要原因。可先保持其它条件相近，聚焦入口与字段理解；等关键路径可用后再处理视觉完善。不同阶段的原型精度应服务当前问题。

邀请实际或可能使用此类产品的人完成任务，并准备清楚、不中途提示答案的说明。例如：“你刚花了 28 元买午餐，请把这笔支出记下来，之后检查金额与类别是否正确。”如果直接说“点击底部的加号”，就无法判断用户能否自己找到入口。

GOV.UK 的主持式可用性测试指南建议围绕具体任务观察使用过程，并采用清楚、中性的任务指令。记录既要包含完成情况，也要包含误操作、停顿、求助和用户的解释；一句“挺好用”不足以决定改版。

可以比较两种方案的完成情况与用时，但要保持任务、资料和说明方式相近。让同一个人先做一次再做另一次，还可能产生熟悉任务的影响。样本和条件不足时，先把观察作为定位问题的线索，不把一次更快的操作写成“效率显著提升”或“证明方向正确”。

整理反馈时可分三层：观察到什么、团队怎样解释、准备验证或修改什么。例如，“用户保存后又点一次提交”是行为；“没有看见保存反馈”是待确认解释；“调整反馈位置再观察是否重复提交”才是下一动作。

迭代次数没有一个保证有效的固定下限。每轮结束后，应按原问题决定下一步：关键路径已经足够清楚，可以进入后续实现与验证；仍有明确障碍，继续改相应环节；证据与假设不符，则重新理解问题或暂缓方案。

如果入口已能找到，但保存后反复提交，就先处理状态反馈，不急着增加语音记账；如果填写无明显障碍，用户却说自己习惯月底一次整理，就应进一步了解真实使用频率，不能简单用更多提醒解决。业务留存、付费等结果需要在上线后的实际使用中观察，原型任务表现不能代替这些结果。

将每轮的目标、方案版本、观察记录、决定和未解决问题放在同一画布，方便团队回看为什么调整。进入开发时，再把已确认范围、规则和验收条件交给执行团队；开发完成后继续核对实际使用，而不是把原型通过当作整个产品成功。

本例的重点是沿一项记账任务完成问题确认、方案取舍和反馈判断。要把这些决定放入更长周期的资源与路线图安排，可继续阅读产品规划流程。每次迭代都知道自己在验证什么，才能积累有用的产品经验。