用户需要与user story怎样相连，为什么功能清单不能独自回答需求

一份功能清单列得很长，是否就表示团队已经清楚用户需要什么？GOV.UK的《Learning about users and their needs》把user needs与user stories放在相连却不同的层次：needs通常较高层、范围较宽，随时间相对稳定；stories描述为满足这些需要而创建的具体功能与内容。[1]

先看需要的对象。该页说，user needs是用户对服务的需要，服务须满足它们，用户才能得到相应结果。它不是把一个按钮、一个页面或一种渠道换成“需求”这个名称。文档在验证需要时特别提醒，应聚焦用户的问题，而非预先选定的解决方式；它用“需要提醒”与“需要邮件或信件”作区别。

这个例子使层次容易理解。提醒描述用户想解决的问题，邮件或信件已经指定了表达手段。作者对资料的分析是，如果一份说明一开始就只留下某个手段，后来读者可能难以知道它原本回应什么问题。本文没有调查真实用户，也不据此宣布哪种提醒方式最合适。

user story则承担更具体的工作表达。指南说，它通常比need采用更受限的格式，并包含验收准则、复杂度与依赖等附加信息。团队用它把工作组织成可以管理的部分。因此，story里出现具体实现内容并不奇怪；关键在于，这些内容与哪项用户需要相联系，而不是要求两个层次必须写成相同句子。

文档据此要求，编写user story时持续记录它所关联的user needs。这样的可追溯关系，可以帮助追踪相关活动，并判断某项需要被满足到什么程度。它没有说，只要每个story都填写完整，用户需要就已在现实中获得满足。文档之间建立联系，与服务结果已有证据，仍是两种进度。

可以设想一份不对应真实项目的交接：上层说明用户需要及时获得提醒，下层列某项具体提醒内容，并记录它关联这项需要。后来具体表达发生变化，上层的问题仍可以保持可见。反过来，若只剩一串内容任务，就难以从任务名称知道哪些属于同一需要。这个情形仅解释文档组织，不是服务配置或研究方案。

指南还说，好的需要应来自用户研究证据，而非假设，并随着后续所学继续验证与完善。因此，“较稳定”不应被读成永远不再核对；它描述与具体stories相比的层次和范围，不能替来源证据免检。本篇未招募参与者、访问用户或测试任何功能，也不承诺这种文档表达必然改善体验。

页面首次发布于2016年4月4日，最后更新于2017年3月23日。本文采用其中验证与关联段落，作为历史服务设计资料解释。对用户体验团队，其用途是让需要、具体工作与证据各有位置：功能清单可以承载要做的内容，但不能独自代替用户问题及其研究依据。