数据原型边界概念：定义、重要性与 KANO 决策框架
数据原型是产品团队在早期构建的、具备核心数据结构和交互逻辑的轻量级可执行模型。它不同于高保真视觉稿，重点在于数据流转、字段关系、状态变化与边界条件。数据原型的边界指该模型所覆盖的功能范围、数据粒度、异常处理以及外部依赖的切分点。
讲师提示：数据原型是“可工作的最小数据骨架”，边界划得越清晰，后续需求拆解和迭代的风险就越低。
为什么边界如此重要？
模糊的边界会导致三大类业务问题：
- 需求蔓延：原型边界未明确定义，开发过程中不断追加字段或功能，排期失控。
- 数据冲突：不同团队对同一数据字段的理解偏差，造成集成时数据不一致。
- 验收扯皮：原型边界与正式产品边界不一致，测试和验收时反复返工。
| 边界类型 | 典型问题 | 影响程度 |
|---|---|---|
| 功能范围边界 | 哪些操作属于原型，哪些属于未来版本 | 高 |
| 数据字段边界 | 每个字段的必填、可选、默认值、数据来源 | 高 |
| 异常场景边界 | 空值、网络超时、并发冲突的处理方式 | 中 |
| 外部依赖边界 | 依赖的第三方服务数据格式、响应时间、容错策略 | 高 |
KANO 如何辅助确定功能去留
KANO 模型将用户需求分为三类：基本型（Must-be）、期望型（One-dimensional）、兴奋型（Attractive）。在数据原型边界设计中，我们通过用户访谈和问卷为每个候选功能分类，从而决定边界内的去留：
- 基本型：必须纳入原型边界，缺失会导致用户直接弃用。
- 期望型：按优先级评估，若边界容量允许则纳入，否则推迟。
- 兴奋型：一般情况下不纳入原型边界，可作为后续迭代的惊喜点。
业务场景示例：某电商后台“订单列表”数据原型，用户访谈发现“按支付状态筛选”是基本型（必须做），“多条件组合搜索”是期望型，“导出为 PDF 报表”是兴奋型。边界内优先实现基本型和前两个期望型字段。
用户访谈与需求拆解
通过结构化的用户访谈收集对每个数据功能的评价（正面/反面问题），再利用 KANO 二维分类矩阵做归属判断。以下是常见访谈问题模板：
问：如果“订单列表”支持按支付状态筛选，您感觉如何？
A. 我喜欢 B. 我期望 C. 无所谓 D. 我能忍受 E. 我不喜欢
问：如果“订单列表”不支持按支付状态筛选，您感觉如何？
A. 我喜欢 B. 我期望 C. 无所谓 D. 我能忍受 E. 我不喜欢根据两组答案对照 KANO 分类表，得到该功能所属类别。再对同类别的功能排优先级，并写入边界文档。
方案表达：边界决策流程图
下图清晰展示了从用户需求到边界确定的决策链路：
指标验证与验收标准
边界确定后，需定义可量化的验证指标：
- 边界覆盖率：原型中已实现功能数 / 边界文档中承诺的功能数 ≥ 95%。
- 边界偏差率：原型交付后发现的需求遗漏 / 总功能数 ≤ 5%。
- 用户满意度评分：对边界内功能进行可用性测试，平均评分 ≥ 4.0/5.0。
避坑提醒：KANO 分类结果不是一成不变的。每次用户访谈后应更新分类表，避免凭一次调研就冻结边界。
交付物模板：数据原型边界文档
下表为推荐边界文档的主要字段，可直接作为团队协作模板：
| 功能名称 | 字段/交互描述 | KANO 类型 | 是否纳入边界 | 备注 |
|---|---|---|---|---|
| 按支付状态筛选 | 下拉选择：未支付/已支付/退款中 | 基本型 | 是 | 接口已有数据 |
| 多条件组合搜索 | 输入框 + 日期范围 + 状态复选 | 期望型 | 是（高优先级） | 需后端支持复合查询 |
| 导出 PDF 报表 | 点击按钮导出当前筛选结果 | 兴奋型 | 否 | 暂不开发，放入 backlog |
基于此文档，团队可快速对齐数据原型的开发范围，并在评审会上逐项确认，大幅降低返工风险。