“增加共享、提醒、日历同步”，很像一份完整的产品计划。但行政人员临时要安排一场跨地点会议时，最着急的可能是两位同事还没回复，她无法确定可以向其他人发出什么通知。
情景法把功能放回这样的使用时刻。它从用户视角讲述未来产品或服务如何参与任务，写出目标、触发、行动和结果。团队可以据此比较设计方向，形成共同愿景；故事中的未来仍然是设想，需要继续验证。
故事先回答她要办成什么
以一个面向中小企业的会议安排产品为假设示例。行政人员收到临时会议要求，需要确认人员、地点、设备，并告诉外地同事是否可以远程参加。她的目标是一份可执行的安排，而非在系统里创建一条记录。
如果故事写成“打开产品，点击创建，发送通知”，读者只能知道按钮顺序。补上“两人尚未确认，她需要在下班前通知其他同事”，才能讨论产品应怎样处理不确定的状态。
角色和条件应来自研究资料。时间压力、已有工具、谁有决定权，只写会影响任务的细节。资料没能确认的条件，注明假设；给角色写完整生平，对判断是否需要提醒功能帮助不大。
本篇只跟着行政人员。参会者确认出席、管理员维护会议室可以各写一篇情景，别让同一个人突然承担所有职责。多角色的目标有冲突时，也应保留，例如行政想尽快确定，参会者想先看议程。
把这段故事写到能够作出设计选择
从临时要求开始，让人物按自己的目标行动。她查询可用会议室，向同事确认时段，看到两人的回复仍为空，决定先保留一个候选时间。产品这时可以区分“拟定”“待确认”“已确定”，让她知道什么信息已经能发出去。
技术介入写到读者能理解就够了。“算法自动解决安排”省掉了设计难题。更可讨论的写法是：系统显示时间冲突和几个替代时段，行政能查看理由，再决定是否调整。
把每项候选功能放回故事，看看它解决哪一个困难。提醒是否发给未回复的人？共享是否让同事无需安装新应用就能确认？同步到日历是否会把尚未确定的安排当作正式会议？这些问题比功能名称更接近实现所需的条件。
故事结束时，应说明相关人员如何知道地点和参加方式。创建成功只是中途反馈；如果仍有人不知道从哪里加入，行政的任务还没完成。
写完可以请一位没参加规划的同事复述。成功标志是他不用记住按钮，就能说清谁为什么行动、方案在哪一刻提供帮助，以及结果为什么够用。这项检查确认故事可理解，还不代表目标用户确实需要该方案。
让不顺利的条件留在故事里
复制主故事，只改变一个重要条件。比如会议室临时不可用，行政在路上用手机处理，或一位关键同事一直未回复。再看之前设想的产品怎样回应。
手机情景可能暴露信息过密：她需要快速找到尚未确定的部分，而不是重看完整会议设置。未回复情景则可能要求保留草稿、解释状态、允许换时段。任务暂时办不完，也应该有可理解的结束位置。
同一情境也可以比较两种方案。一种要求所有人注册，另一种通过已有渠道确认。讨论注册成本、回复信息是否完整、企业是否允许使用渠道，别把选择变成“哪个故事写得更动人”。
早期想法很多时，头脑风暴图像组织法能帮团队整理人物、任务与支持方式。关系画清之后，仍要放回会议故事检查，才知道某个功能为什么值得做。
原型要保留故事中最难的那一刻
把情景转成测试任务时，可以说“请安排一场跨地点会议，让相关人员知道参加方式”，不要说“请使用待确认功能”。后者已经告诉参与者解决路径，只能检查他是否按指令操作。
原型也应保留未确认人员、移动端处理等关键条件。删掉这些困难，就无法检验故事为什么需要新设计。记录哪些条件有研究依据、哪些还在假设，新反馈出现后可以修改情景。
交付时保留主故事、必要的异常版本及验证问题即可。例如检查用户能否区分候选与正式时间、是否知道怎样邀请未注册同事、调整时间后通知是否一致。每个问题都对应故事中的一次动作或取舍。
阅读者说“喜欢这个场景”，不能说明他会采用产品。使用频率、替代方式、成本和企业规则还要另行研究；系统性能、权限是否正确也要专门检查。情景法帮助团队把愿景讲清楚，效果要在真实任务里看。
让功能说明回到人的任务
当功能越来越多，58UI可通过UI/UX设计整理关键任务、状态与页面关系，再用原型讨论取舍。官网设计开发与品牌视觉设计也可以围绕使用情景组织内容，让访客看懂产品在什么时候派得上用场。
你可以查看设计与开发服务和官网与界面案例。若已有功能清单，带上一位目标用户最想完成的任务，通过沟通具体设计问题一起确定需要先讲清、再验证的使用过程。
相关服务
