产品经理写需求文档，写了一句“页面要用户友好”。开发看完问：友好到什么程度？测试问：怎么算通过？一句话三个字，返工两星期。需求文档最常见的毛病，是形容词太多、数字太少。
把“用户友好”拆成6条可验收标准。1）首屏加载时间不超过2秒，在4G网络下实测3次取平均值。2）主要操作路径不超过3步，从进入页面到完成下单，点击次数≤3。3）错误提示写清楚原因和解决办法，比如“手机号格式不对，请检查是否11位”，而不是“输入有误”。4）关键按钮点击区域不小于44×44像素。5）表单必填项不超过5个，超过就分步。6）页面在1366×768分辨率下不出现横向滚动条。每条都能测，测不过就是没达标。
对比两种写法。写法A：“搜索结果要准确。”写法B：“搜索关键词命中标题的排前3位，命中正文的排4到10位，无命中的不展示；测试用20个关键词，前3位命中率≥80%。”B写了3行，开发和测试都能照着做，省掉至少2轮口头确认。
一个真实返工案例：某团队做筛选功能，文档写“支持多条件筛选”。开发做了3个下拉框，产品想要的是标签多选加价格区间滑块。返工花了5天，涉及前端2人、后端1人。后来补了一句话：“筛选条件为标签多选（最多选5个）+价格区间双滑块（步长10元）”，再没出过类似问题。
写需求文档有3个常见错误。第一，只写正常流程，不写异常流程，比如断网、重复提交、超时。第二，用“等等”“类似”收尾，开发和产品理解不一致。第三，改需求不留版本记录，第3版覆盖第2版，出问题找不到是谁改的。
操作上，每个功能点后面加一行“验收方式”，写清楚谁在什么环境用什么数据测。20个字就够，比如“测试环境，用50条 mock 数据，验证分页每页20条”。需求文档不是作文，是给开发和测试看的说明书，每个形容词后面都得跟一个数字。
