员工发现会议室投影坏了，手机就在手边，但他不知道设备编号，会议又快开始。产品说“拍照报修”，能否帮助这件事继续，取决于照片之外还需要什么，以及提交之后谁接手。
故事板用连续画面表达人物、目标、环境、行动和结果，把概念放进可见的使用情境。早期团队可以据此讨论条件和转折；画面流畅不能说明现实一定流畅，它也不是用户行为的录像。
先画一个人要解决的事
以企业服务台的拍照报修概念为假设示例。核心可以写成：员工不必先知道维修部门，就能提交足够的报修信息并了解进展。
故事从投影异常开始，而非从打开应用开始。员工查看设备贴纸，编号不清楚；他拍下故障画面，输入房间位置；行政确认地点，维修人员需要进一步描述。他还要决定继续等待，还是先换会议室。
这些细节影响设计判断，但当前只是示例条件。真实项目要由访谈或观察支持，没有依据的地方注明假设，不能把它画成已经发生的真实旅程。
一个故事板最好聚焦一个概念。预约、支付、推荐和售后都塞在同一条故事里，反馈很难对应具体价值。要比较两个方向，分别画故事。
写关键事件，比先画漂亮界面更有效
在纸上先写触发、尝试、反馈、等待和结果，挑会改变行动的转折。再用方框、简笔画或照片拼贴表达，不需要固定格数，能看懂时间和因果即可。
只画首页、列表、详情、提交，会漏掉员工为什么急、手里有什么资料、身边谁在等。即使遮住界面，读者仍应知道故事为什么发生。
| 画面 | 本例要让读者看见的条件 |
|---|---|
| 发现故障 | 会议将开始，员工要作出临时安排 |
| 准备报修 | 有手机照片，却不知道完整设备编号 |
| 收到反馈 | 哪些信息已收到，谁继续确认 |
| 等待处理 | 能否查看进展，需不需要换会议室 |
| 结束 | 员工知道可采取什么行动，问题怎样被接手 |
结果不必是投影立刻恢复。若服务需要等待，让员工知道下一步同样值得设计。不要用一个成功图标或“非常满意”的表情替代实际结果。
系统响应和服务能力不确定，就在旁注中标出来。故事可以提出未来方案，但不能悄悄让无法实现的即时处理成为前提。
根据读者，补不同的细节
用于早期用户讨论，画面简洁更容易让人补充条件，过于精致的界面可能把反馈带向视觉评价。用于开发讨论，则可以补权限、数据和交接，但假设仍要清楚标记。
人物感受可以表现，最好接到行动。例如他反复查处理状态，或去寻找备用会议室。图能展示发生了什么，焦虑的原因还要听参与者解释。
如果必须由主持人长篇解释才能理解一格，先检查缺少人物、条件还是反馈。提高绘画精度，未必能填补信息空白。
让读者复述，也允许他否定故事
请用户代表、业务和开发先说自己看懂了什么，再解释设计意图。按画面问“此时你手边有什么？”“通常由谁接手？”“没收到反馈会怎样处理？”答案关联到格子，方便修改。
若参与者说平常从不使用手机报修，先核实渠道和角色。别继续逼他评价拍照按钮；这个反馈可能说明概念起点不适用。故事被否定，也能帮助团队及时发现错误假设。
成功标志是读者能用自己的话说明概念帮助谁、在哪一刻提供支持，并能指出一个需要核实的条件。团队据此修改画面或安排研究，而不只是觉得“故事完整、画得好”。
让重要转折走到原型里
成品保留核心概念、分镜、假设和验证问题。在本例中，可以先制作位置识别与提交反馈的关键界面，检查员工不知道编号时能否报修，也能用身体风暴演绎会议将开始的那一刻。
故事板帮助发现问题，不直接测量使用频率和任务成功。等待时间要由实际服务能力确认，接口和权限要由技术检查，用户理解则要在没有解释的任务里观察。
当团队能看见员工报修以后仍需安排会议，就更容易判断哪些反馈必不可少。概念因此有了具体的使用条件，界面也有了值得检验的起点。
把服务概念变成能讨论的页面
58UI提供UI/UX设计，可将故事中的关键转折整理成任务与原型；在企业官网设计开发和品牌视觉设计中，也可用清楚的情境表达服务作用，避免只堆功能名称。
相关范围见设计与开发服务，呈现方式可查看官网与界面案例。若团队对概念理解不同，通过沟通具体设计问题带来一条任务与粗略故事板，就能开始讨论需要补充的条件。
相关服务
