故事卡应尽量简练,而非事无巨细应写都写;同时,应尽量完整、准确,而非缺少细节、模棱两可
这是我的基础观点,我的考虑如下:
- 简练意味着读者获取的信息是经过提炼的,读者阅读起来是更高效的。
- 简练意味着BA 写卡可以更高效,可以投入更多精力在其他更具挑战的工作内容上。
- 完整、准确意味着故事卡是经过讨论并达成一致的。
- 完整、准确意味着故事卡是有着清晰验收标准的。
- 完整、准确意味着故事卡是便于追溯、便于传递的。
- ……
基于以上观点再分类别展开聊下。
关于对页面交互的描述
上图展示了一个添加新账号功能的 UI 设计。一种对该功能需求的描述可能是:
- 用户通过主菜单进入“权限管理”模块,选择“账号管理”Tab页,可以看到“新增账号”按钮。
- 点击“新增账号”按钮,系统弹出新增账号窗口(可能还会写一句“背景置灰”)。
- 用户可在窗口中填写姓名、登录邮箱……
- 若用户未填写必填字段,则点击“确认”时给出错误提醒“请完成所有必填字段的填写!”
- 点击“确认”按钮后弹出二次确认窗口,二次确认信息为“确认创建该账号?账号一旦创建成功即会邮件通知对应用户”。用户再次选择“确认”则系统创建账号,若用户选择“取消”则返回填写账号窗口。
这些文字描述没有任何错误,应该还符合不少Dev同学 或QA 同学的胃口,但在我看来过于臃肿。尝试思考简化哪些信息不会影响Dev 编码和各角色理解业务:
详细的操作步骤描述是否必要?
通常是不必要的。一般情况下设计图或简单的沟通是很容易表达这些内容的,故事卡中简单地表述主要路径即可,详细的描述反而约束了设计和实现,并且让故事卡变得臃肿。
描述所有字段是否有必要?
通常是需要的,但应该是从业务角度描述,后文有详细聊到。
详细地描述用户操作后的系统反馈是否有必要?
通常不是必要的,因为绝大多数的系统反馈是约定俗称或显而易见的。比如popup 窗口下方的页面是被置灰的,popup 窗口上的“取消”按钮点了后会关闭窗口,等等。那什么是“不通常”的情况呢?常见的是期望系统根据业务目标给出的反馈,比如我会注明“创建用户成功后页面应跳转回列表页”,因为我知道管理员通常会批量创建多个用户,这样效率更高。
二次确认功能中的文案是否有必要详细描述呢?
很多时候是需要的,因为这些文案通常是想表达特定的业务含义的,用完美的文案将这层业务含义表达出来是BA 的职责。那反过来的情况呢?比如一些常规的删除操作的确认文案就不需要一一描述,可以与团队约定好所有的删除操作都需要二次确认,所有的二次确认文案都是“确认删除该xx?删除后不可恢复”,如有特殊情况再单独表述。
那么对于上面的需求,我的描述会是这样的:
「
权限管理员可创建新的用户
- 路径:后台管理端 - 权限管理 - 账号管理 - “新增账号”button
- 新增账号所需字段</