没有完整需求文档，怎样用一次业务演示让UI团队理解工作？

项目准备启动，甲方知道每天怎样工作，却还没有完整需求文档。此时只发几张页面截图，UI团队能够看到界面，仍看不出资料从哪里来、为什么这样处理，以及下一位人员怎样接手。一次业务演示可以帮助双方建立共同理解，但前提是演示工作，而非仅展示页面。

UI需求业务演示的成果不是当场确认全部设计范围，而是得到一条可追溯的任务、相关资料与待问事项。使用者展示实际做法，设计方记录事实，业务负责人核对规则。三类角色各有作用，不能让某一个人的熟练操作代表所有工作条件。

选择有起点、交接和结果的日常任务

选择一条足以解释当前工作关系的任务，不从系统首页依次翻菜单。任务应能说出谁开始、收到什么、需要做什么、怎样判断完成。若只有“我们经常处理客户资料”，仍需选定一次具体处理类型，避免演示中不断换对象。

下面采用假设场景：业务人员收到一份客户信息，整理后交给另一位同事核对，最终得到可继续处理的资料。它只是说明演示方法，不对应真实客户或内部项目。任务不必复杂，但应看得出输入与结果的关系。

会前让操作人说明自己在这条任务中的身份和职责。部门名称不一定等同于产品角色，同一个人可能兼做录入、核对和交接。演示团队需要知道何时发生身份切换，不能据一人操作所有步骤就判断未来界面都属于一个角色。

任务过长时，选一个连续部分，并说明前后的衔接，不将其当成整个业务。任务太短只有单次点击，则补足输入和完成判断。适当范围能够让设计方深入提问，而不是仅看到一次高速展示。

再约定本次要看懂什么。例如找出资料来源、重复录入和交接依据，而不是现场选颜色或讨论页面数量。目的具体，参与者才知道哪些细节值得停下来说明，也避免演示被临时变成报价或最终方案评审。

资料要像真实工作，身份要可公开

演示资料应保留影响工作判断的结构，同时去除不适合共享的信息。可以构造接近实际长度与关系的内容，说明哪些是样例、哪些来自已确认流程。不要用真实客户名称增加“真实性”，也不要让脱敏后所有字段都变得一样而失去工作意义。

操作者应使用经过安排的环境或材料，不把真实线上任务当作随意演练。是否允许操作、哪些内容可以查看，由甲方实际负责人确认。设计团队需要理解的是规则与行为，不必获得全部系统权限或客户原始数据。

资料结构本身也要解释。一个字段从文件里复制，另一个由操作人判断后填写，二者对设计有不同含义。仅看到相同输入框，无法知道是否可自动带入、是否需要业务审核。这些实现判断留待后续评估，演示先记录来源。

不要要求操作人背诵完整制度。他可以解释最近一次怎样做，业务负责人再核对这是否属于允许的做法或临时绕行。实际行为与正式规则不一致时，保留两项记录，不把其中一项悄悄替换成更整齐的流程。

会前准备资料所在位置和相关参与角色。资料尚未取得，就在演示中明确这一缺口，而不是临时虚构一份看似正式的文件。遗漏的来源会影响后续设计，需要知道由谁补，而不是让UI团队自行补想象。

让操作人做一次，再解释为什么

请操作人按平时顺序处理一项任务，并说出正在找什么、如何判断下一步。设计方先看行为，再问具体原因。不要让负责人从头代操作，否则容易只看到管理者理解的理想路径，而看不到日常工作方式。

关键节点可以停下来核对：这份信息来自哪里？为什么复制到另一位置？谁会使用处理结果？这些问题帮助UI团队理解约束，不预先指定“应增加一个按钮”之类解决方案。方案讨论太早，会让后续观察围绕既定答案展开。相关操作可参阅《UI设计Brief怎么写？一份让设计团队快速理解项目的需求模板》。

涉及交接时，让接收者说明怎样知道已经轮到自己，以及怎样判断资料足够。只展示发起者点击提交，不能解释接续工作。若另一角色未到场，可以保留待核对事项，不能由发起者代替其确认全部需要。

屏幕外的动作同样重要。操作人打开文件、给同事发消息、手写记录或询问负责人，可能承担界面未覆盖的工作。记录这些动作与目的，而非立即认定都应搬进软件。是否需要产品化，取决于实际问题和后续范围判断。

设计方不要为了让演示顺利，替操作者找到按钮或改资料。可以记录其停顿，再询问当时在寻找什么。此次演示旨在理解现状，与正式可用性测试不同，但仍需避免提示过多而抹去真实工作线索。

专门补演经常被略过的部分

日常演示容易沿正常路径结束，例外却往往决定界面需要哪些状态。可以请操作人选择与本任务相关的常见差异，说明资料不全、需要退回或暂时无法继续时怎样处理。不要求一次覆盖所有罕见情况。

不能现场演示的例外，可以用已确认材料解释，并登记没有直接观察的范围。不要为了证明流程完整，现场构造一个未发生过的“客户问题”。构造样例可以帮助讨论，但记录中需要保留假设身份。

问清线下步骤发生在前面还是后面。比如任务结束后仍需人工检查，界面上的“完成”可能只表示提交。UI团队据此需要进一步了解状态含义，不能把一个词直接当成业务已经结束的证明。

同一任务不同人员做法不一致时，先查差异来自权限、资料条件、个人习惯还是制度要求。不急着投票选一个最顺的流程。差异可能指向不同使用场景，强行统一会失去实际条件。

对未确认的规则，指定能够回答的角色和所需材料。不能把“设计团队后续考虑”作为业务未知项的接收方式。设计方可以提出问题与方案，业务规则仍需要甲方相应负责人确定，技术实现再由实施方评估。

演示记录分成事实、待问与设计想法

记录事实时，写清哪个角色在何种条件下做了什么，附适合的材料位置。待问项说明缺少什么与谁来核对。设计想法则单独保留，它是候选方向，不能被混写成用户已经提出或业务已经确认的要求。

演示后请操作人核对任务描述，业务负责人核对规则含义。若两者存在差异，在同一记录中保留，不用一份漂亮流程图消除矛盾。设计团队应知道哪些输入可靠，哪些必须等新依据才能推进。相关操作可参阅《复杂业务流程怎么转成可用的B端产品？从流程图到界面》。

下一步可以整理需要补充的资料或安排另一角色演示，按实际项目决定。没有确认的后续工作不要写成必然包含，页面数量和交付范围也不能从一次操作自动推算。演示是理解材料，不是所有范围的确认文件。

保存记录时保留日期、任务范围和材料版本，后续规则变化能找到受影响的设计输入。简短清晰的记录即可，不必逐字转录所有聊天，也不把大量无关截图当作完整理解的证明。

完成标志是UI团队能够复述输入、动作、交接、结果与主要例外，双方知道还有哪些规则未确认。没有完整需求文档仍可开展有依据的沟通，但不应以一次演示结束为由停止补充后续需要的事实。

常见问题

操作人很熟练，演示会不会看不出问题？

可以请他说明依据和被省略的动作，再核对其他角色的条件。熟练操作有助于理解工作，但不能代表所有人都能独立完成，也不能替代后续目标用户验证。

只能提供截图，怎样补足工作关系？

按一条任务排列截图，逐步解释输入来源、动作原因、交接和结果。明确哪些没有直接展示，再安排对应人员或资料补充，不用截图数量代替任务完整性。

业务负责人必须全程参加吗？

按实际任务安排。至少需要有人确认规则和待问项的负责人；无法到场可以后续核对记录，但操作人的个人做法不应被直接当成已批准规则。

一次演示能直接估算全部UI工作量吗？

不能。它帮助识别任务和缺口，完整范围还要核对角色、状态、平台与交付内容。设计方可据此提出进一步评估，而非把演示路径当成全部系统。

演示中发现明显界面问题，可以马上修改吗？

可先记录问题与条件。低影响调整也需要确认范围和依据，涉及业务规则的改变应由相关负责人判断。不要因现场想到方案就把观察过程改成实施会议。