关于编写故事卡的一些经验

故事卡应尽量简练，而非事无巨细应写都写；同时，应尽量完整、准确，而非缺少细节、模棱两可

这是我的基础观点，我的考虑如下：

• 简练意味着读者获取的信息是经过提炼的，读者阅读起来是更高效的。
• 简练意味着BA 写卡可以更高效，可以投入更多精力在其他更具挑战的工作内容上。
• 完整、准确意味着故事卡是经过讨论并达成一致的。
• 完整、准确意味着故事卡是有着清晰验收标准的。
• 完整、准确意味着故事卡是便于追溯、便于传递的。
• ……

基于以上观点再分类别展开聊下。

关于对页面交互的描述

上图展示了一个添加新账号功能的 UI 设计。一种对该功能需求的描述可能是：

1. 用户通过主菜单进入“权限管理”模块，选择“账号管理”Tab页，可以看到“新增账号”按钮。
2. 点击“新增账号”按钮，系统弹出新增账号窗口（可能还会写一句“背景置灰”）。
3. 用户可在窗口中填写姓名、登录邮箱……
4. 若用户未填写必填字段，则点击“确认”时给出错误提醒“请完成所有必填字段的填写！”
5. 点击“确认”按钮后弹出二次确认窗口，二次确认信息为“确认创建该账号？账号一旦创建成功即会邮件通知对应用户”。用户再次选择“确认”则系统创建账号，若用户选择“取消”则返回填写账号窗口。

这些文字描述没有任何错误，应该还符合不少Dev同学 或QA 同学的胃口，但在我看来过于臃肿。尝试思考简化哪些信息不会影响Dev 编码和各角色理解业务：

详细的操作步骤描述是否必要？

通常是不必要的。一般情况下设计图或简单的沟通是很容易表达这些内容的，故事卡中简单地表述主要路径即可，详细的描述反而约束了设计和实现，并且让故事卡变得臃肿。

描述所有字段是否有必要？

通常是需要的，但应该是从业务角度描述，后文有详细聊到。

详细地描述用户操作后的系统反馈是否有必要？

通常不是必要的，因为绝大多数的系统反馈是约定俗称或显而易见的。比如popup 窗口下方的页面是被置灰的，popup 窗口上的“取消”按钮点了后会关闭窗口，等等。那什么是“不通常”的情况呢？常见的是期望系统根据业务目标给出的反馈，比如我会注明“创建用户成功后页面应跳转回列表页”，因为我知道管理员通常会批量创建多个用户，这样效率更高。

二次确认功能中的文案是否有必要详细描述呢？

很多时候是需要的，因为这些文案通常是想表达特定的业务含义的，用完美的文案将这层业务含义表达出来是BA 的职责。那反过来的情况呢？比如一些常规的删除操作的确认文案就不需要一一描述，可以与团队约定好所有的删除操作都需要二次确认，所有的二次确认文案都是“确认删除该xx？删除后不可恢复”，如有特殊情况再单独表述。

那么对于上面的需求，我的描述会是这样的：

「

权限管理员可创建新的用户

• 路径：后台管理端 - 权限管理 - 账号管理 - “新增账号”button
• 新增账号所需字段</