演示画面可以点击、切换和出现结果，客户容易认为这些能力已经能正式提供。实际可能一部分属于当前产品，一部分是样例流程，还有一部分仅用于讨论未来方向。若开场只说一句“这是演示”，具体到某个功能时仍然难以辨认它处于什么状态。
演示功能状态说明，需要把功能是否可提供、演示怎样实现、结果依据是什么分开表达。界面上的标注不是为了降低展示吸引力，而是让客户按正确范围判断。状态规则应贯穿进入、关键画面和结束材料，不能依赖主持人始终在旁解释。
先做能力清单，再决定状态名称
请产品负责人逐项确认本次会展示的能力：现行产品在相应条件下已提供，当前仅作演示，还是仍需评估是否提供。名称可以按团队实际语境调整，但三种含义应能区别。不能因为画面制作完成，就把对应能力自动归入已提供。
“已提供”也需要范围，例如对应哪一产品版本、哪些条件或什么服务安排。若仅有局部现行能力，应将它与未确认的其他部分拆开。一个模块中可以出现不同状态，不能让模块标题覆盖所有子功能。
以下是假设示例：一款软件的资料查阅已可提供，某项联动结果用预置样例展示，另一项定制分析仅有概念画面。三者都可以用于交流，但客户必须知道哪项可查看现行资料、哪项只是理解路径、哪项需要进一步讨论。这里不是任何真实软件的发布状态。
能力清单还要记录依据和负责角色。当前产品说明、演示准备记录和待问事项分别保留，方便状态变化时核对。官网设计人员可以安排位置和表现，不能替产品团队决定能否正式供给，也不能依据销售愿望修改成熟度。
资料不完整的功能先保留待确认。空白不是未提供的证明，更不是可以默认为已提供。状态清单的价值，是让演示团队知道哪些判断已有依据、哪些还欠确认，而不是将所有项目填成最有利的名称。
进入时说明版本，不要求客户记住一次提醒
演示入口应简要交代产品身份、版本与本次用途。客户从链接直接进入时，也能看到这些信息，不需要先参加一场开场介绍。若同一链接可能被转交给其他部门，入口说明尤其重要。
开场可以提示状态含义，但不能只靠一页说明承担所有边界。参与者稍后可能只看某个局部画面，或在提问中切到其他功能。关键画面仍应保留当前状态，让读者不用回忆几分钟前的定义。
进入后若有一项能力受特定提供条件约束，应在相关处说明。不能用“正式版”统称整个演示环境，又在少数功能里混入概念。环境身份和单项能力状态分别组织，避免一个名称让全部内容显得同样确定。
截图或录制材料也应能辨认版本与状态。主持人口头说明在转交中可能丢失，可使用与画面关联的准确说明，而不是把所有限制放在单独附件。转交资料的结构由实际任务决定，但关键事实需跟着相关内容。
发布前检查入口文案是否暗示了正式使用。按钮写“立即体验全部能力”，落点却多数为样例，会形成预期冲突。可以写出进入后能做什么和本次展示范围，避免靠泛化动词扩大供给承诺。
状态标注放在形成判断的位置
标注可以靠近功能标题、操作入口或结果区域，具体位置依据用户在哪一步作判断。若用户点击后才知道只是样例，可能已经把前一页的承诺当真。影响采购判断的状态应在进入相关操作前容易发现。
文字是主要解释，颜色、图标或边框可辅助，但不要让用户只凭颜色猜状态。状态名称与一句用途说明组合，往往比三个抽象图标更清楚。这里不规定技术实现或数值，实际可读性仍需在代表性设备和使用条件下检查。
混合状态的流程需要说明切换点。前半段是现行能力，后半段是预置结果，可以在进入后半段时清楚提示，不能让连续动效暗示前后全部实际运行。主持人同样使用一致说法，避免口头承诺超过界面说明。
对待评估能力，不宜使用像正式可执行操作一样的确定结果。可以展示讨论方向或说明需确认条件，帮助客户提出问题。若现有原型只能沿固定路径运行，应说清本次演示支持什么，不伪装为完整自由操作系统。相关操作可参阅《低保真、高保真、可交互原型有什么区别？按验证问题来选》。
状态变化应由同一份已确认清单驱动。设计稿、演示环境和发送截图可能不同步，更新时都要核对相关位置。不能只改一个状态标签，却保留旁边的旧结果描述与新功能承诺。
样例结果和真实运行证据分别表达
演示数据帮助理解内容关系，实际运行记录帮助核对特定条件下发生过什么，两者不能混用。样例结果可以明确为构造内容，不加真实客户名称或看似来源明确的成绩。真实材料则按已确认公开范围使用。
某次演示按钮能够触发画面变化，只证明该演示支持这一变化。它不证明后端处理已经完成、真实数据规模已覆盖，也不证明目标用户能独立完成任务。结果说明要准确写本次实际展示，不从画面顺畅推导运行能力。
如果现场确实展示现行功能，也需要保留条件。演示环境的角色、预先准备和使用对象可能与客户情况不同，适用性仍待核对。不要因来源真实就将演示升级为全部场景的保证。
展示等待、失败或异常时，同样分清是否预置。构造异常可以解释设计方向，却不能证明实际系统已经按该方式恢复。未现场验证的部分可以提供现有资料或登记待问项，不临时把模拟结果说成真实测试。
结果区域最好回答“这是什么结果，来自哪种展示，下一步可据此判断什么”。不必公开技术细节，但应让参与者知道它的证据边界。客户可以据此继续了解，不会把一张漂亮结果图当成已经完成的交付。
结束时把可提供与待评估分别带走
会后材料应列出本次已经展示且当前可提供的内容、仅用于说明的样例，以及仍需评估的方向。与产品或服务确认文件的关系应清楚，不把会议纪要自动作为供给承诺，也不把所有演示项合并成采购清单。
请客户用自己的话复述一项混合状态流程：哪些可以查看现行资料，哪些还未确认。若回答仍是“看到的都能买”，需要调整状态位置与解释。这个检查关注理解，不需要虚构客户评价或满意数据。
负责人再核对发送版本，确认标题、摘要、图注和功能状态一致。未来正式提供某项能力时，更新依据后再调整状态，不单纯把“演示中”删掉。当前不再展示的功能也应从常用资料中处理，避免旧截图继续流转。
交接给维护者时，记录谁确认状态、哪份材料需要同步、哪些事件触发复核。这样后续发布变化能够追到实际对象，而不是靠设计者记忆。状态清单可以很简短，只要支持准确更新。相关操作可参阅《组件状态为什么总在开发阶段补？按钮、输入框和卡片至少要把这些状态设计完整》。
完成标志是客户能辨认当前供给、样例展示和未知方向，内部人员使用同一范围，结果说明有对应依据。成熟度展示可以很直观，但必须让可见画面与实际承诺一致。
常见问题
整个链接叫Demo，还需要每项标注吗？
需要检查客户是否能辨认混合状态。环境名称不能回答单个功能能否提供，关键功能和切换点仍需准确说明，尤其在截图可能被独立阅读时。
已开发但尚未正式提供属于哪一类？
按实际可提供条件确认，不能只看开发是否完成。可以说明现阶段用途与尚待完成的事项，由产品负责人决定对外状态，避免提前形成采购承诺。
未上线功能能用正式产品视觉吗？
可以用于展示，但成熟度必须容易辨认。视觉完成度不是供给证据，不能因为看起来一致就省略功能状态与样例范围。
状态文字会影响客户观看兴趣吗？
清楚说明有助于客户按正确范围提问。可采用简短、贴近功能的表达，避免大段重复提醒，但不能为了展示顺畅隐藏影响采购判断的事实。
会后客户要求某项演示能力，怎样记录？
先核对它的当前状态及要求条件。已提供内容进入对应范围讨论，待评估内容登记问题与负责人，不将客户表达兴趣写成企业已承诺交付。
链接复制成功
