01 — 描述一个人和一项任务
假设您帮助社区团体组织志愿者轮班。一个有用的第一个问题可能是志愿者是否能够找到合适的转变并了解如何表达兴趣。与具有提醒、权限和工资单的完整调度系统相比，它更小且更容易审查。
- 描述这个人今天做了什么以及有什么困难。
- 选择您想要使其更清晰或更容易的操作。
- 写下如果第一个版本有效你会观察到什么。
02 — 在纸上走一遍旅程
对于志愿者示例，绘制轮班列表、轮班详细信息和兴趣表。为每个屏幕分配一项工作。使用一些实际的班次样本，包括完整的班次或空列表，因此审查涵盖的不仅仅是一条完美的快乐路径。
- 命名起始屏幕和下一个操作。
- 列出此测试所需的字段。
- 包括空状态和失败操作状态。
- 在探索性提示和示例中保留真实的个人信息。
03 — 将演示与运营服务分开
决定此版本是仅演示旅程还是必须保存实际请求。演示可以显示清晰标记的示例确认。操作服务需要目的地、适当的访问以及检索请求的方法。在邀请真正的参与者之前确认这些要求。
- 标记摘要中的每个仅示例操作。
- 分别列出连接、权限和发布需求。
- 将帐户、付款和提醒留到以后使用，除非第一个测试依赖于它们。
- 当任务涉及敏感信息或复杂访问时，请寻求合格的帮助。
04 — 根据简报查看结果
使用下面的工作表，然后按照产品提示指南将其转换为构建请求。一代又一代地走过同样的旅程并记下发生了什么。对于志愿者的例子，成功的演示可能意味着新访问者可以找到正确的转变并理解下一步，而无需您的解释。
- 请不熟悉这个想法的人尝试这个任务。
- 在请求更多功能之前记录令人困惑的步骤。
- 进行一项重点更改并重复相同的检查。
- 仅当第一次旅程回答了您原来的问题时才扩大范围。
一个起点
让简介具体化。
将此示例应用于您的业务。将样本数据与真实客户信息分开。
第一版本范围工作表 使用人员： ___ 他们今天面临的问题： ___ 他们应该完成的一项任务： ___ 该任务所需的页面： ___ 显示或输入的信息： ___ 主要操作后会发生什么： ___ 保留为示例的内容： ___ 留待以后使用的功能： ___ 当我可以观察到时，第一个版本通过了： ___
当您需要下一步时
请遵循产品文档。
在开始之前。
我需要先选择编程语言吗？
从用户、任务、信息和可观察结果开始。如果现有系统或技术限制决定了语言或平台，请将其包含在简报中并与负责该系统的人员确认。
第一个版本应包含多少功能？
使用最小的一套，让您检查一个完整的旅程。没有通用的功能计数。当没有某个功能就无法对任务进行有意义的测试时，该功能就属于第一个版本。
找到你的下一步。
从一项有用的任务开始