第3章 需求树节点设计规范

用户场景

产品经理小张与交互设计师小王共同维护一份需求树，但两人对“Epic”“Story”“Task”的节点样式理解不一致：小张用矩形表示所有需求，小王用圆角矩形区分层级。评审时经常需要口头解释“这个蓝色矩形是Epic还是Feature？”，沟通效率低下，需求树的可读性极差。

业务问题

• 节点形状、颜色、字号没有统一约定，不同成员绘制出的需求树如同“方言混杂”。
• 状态标记（如“进行中”“已关闭”）缺失或使用不规范的文字缩写，无法快速识别进度。
• 命名规则不统一（例如“登录功能-优化”“优化登录”混用），导致树图搜索、筛选困难。

用户访谈

对6位产品经理和4位设计师进行结构化访谈，归纳出3条核心诉求：

1. 一眼识别层级：节点形状应当直观区分 Epic / Feature / Story / Task。
2. 状态可视化：颜色应反映需求状态（待评审、开发中、已完成、已废弃），而非随意喜好色。
3. 命名可检索：所有节点名称必须遵循“动词 + 对象 + 约束”模板，例如“优化登录页面的加载速度”。

需求拆解

方案表达：Figma需求树节点规范绘制

在Figma中创建“节点样式库”组件，包含以下属性：

• 形状：使用矩形工具，Epic不加圆角，Feature圆角8px，Story旋转45°+裁剪为菱形，Task使用胶囊形状（圆角50%高度）。
• 颜色：填充色严格绑定至状态，文字为白色（#ffffff），描边使用同色系深色（如蓝色描边#2980b9）。
• 字号：标题（Epic/Feature）16px加粗，子节点14px，描述文字12px，颜色统一为#ffffff。
• 状态标记：在节点左上角绘制6px×6px圆点，填充与状态一致，右侧紧跟2～3字符大写缩写（例如“REV”）。
• 命名格式：节点内文本首行强制“动词+对象”，例如“添加搜索记录”、“修复登录白屏”。

节点规范示意图

下图展示了一个包含4种层级、3种状态的简化需求树原型：

指标验证

• 沟通效率：引入规范后，需求树评审会议平均时长从45分钟减少至22分钟（样本量=6次会议）。
• 误解率：随机抽取5个需求树截图，让新成员解读层级和状态，错误率从38%降至7%。
• 命名一致性：通过脚本统计节点名称中“动词+对象”结构的占比，从58%提升至94%。

验收标准

交付物模板

团队需要产出以下两个交付物：

1. 节点规范说明文档（PDF/Notion）：包含形状、颜色、字号、状态标记、命名规则的详细说明和示例截图。
2. Figma组件库：将上述规范制作为可复用组件，团队成员直接拖拽使用，并配置“图层属性”面板切换状态和层级。