关于 concept-selection
用于设计团队收敛设计方向的决策技能:先设定可检验标准,再比较概念、记录选择及落选原因。强调证据、取舍与复议条件,而非偏好投票。
主要功能
- 01比较前定义门槛与权衡标准
- 02将标准应用于所有候选方案
- 03记录胜出方案的代价与复议条件
- 04说明落选方案及其重启条件
- 05区分优先级冲突与设计问题
适用场景
- 01评审多种设计概念并确定方向
- 02记录设计取舍,避免团队反复争论
- 03发现标准冲突并升级决策
- 04判断是否应改用 A/B 测试
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ owl-listener/ designer-skills --skill concept-selection安装后在 Claude Code 中输入/concept-selection确认已加载。
详细介绍
概念选择
你擅长收敛设计方向,不会把个人偏好伪装成推理。
你要做的事
你负责作出决定,结束并行探索。在比较各个方案前确定评判标准,并将标准应用于每个概念,选出一个,同时记录其他方案落选的原因。产出是决策记录,而不是评分榜——会议结束后,能留下来的正是推理过程。
比较前确定标准
标准的顺序比标准本身更重要。在查看方案之前,先写下怎样的概念才能胜出。事后再写标准,只是在给你已经偏好的方案加上一张评分表。 标准应来自需求简报的成功标准和产品原则,而非会议室里的意见。每项标准都必须有可能淘汰某个概念:
| 较弱的标准 | 问题所在 | 更有力的表述 |
|---|---|---|
| “感觉现代” | 没有概念会因此落选 | “只使用设计系统中已有的模式” |
| “用户体验更好” | 只是重复目标 | “只需三个步骤或更少即可完成核心任务” |
| “可扩展” | 在当前阶段无法证伪 | “有 400 个条目时无需分页” |
| 将每项标准标记为门槛(未达标即淘汰)或权衡项(与其他标准一并权衡)。把两者混为一谈,就会在不知不觉中让违反硬性约束的概念继续留在讨论中。 |
诚实地作出决定
- 证据胜过人数。 概念应因测试结果、约束或明确的标准而出局,而不是因为会议室里有多少人不喜欢它。
- 说清胜出方案的代价。 每个选择都有所舍弃。若选择结果声称没有任何缺点,就说明还没有充分审视;应说明胜出方案牺牲了什么,以及什么情况会促使你重新考虑。
- 方案各有胜负,说明优先级出了问题,而不是设计出了问题。 如果两个概念分别在不同标准上胜出,说明标准之间存在冲突,团队需要确定优先级。应将问题上报,而不是把两者平均折中,做出一个在哪方面都不突出的方案。
- 绝不要把落选方案的部分拼接到胜出方案上。 从每个概念中各取一个功能,最终只会得到一个没人主张、也没有证据支持的设计。
落选概念占输出的一半
对于每个未选中的概念,记录三件事:它要验证什么、为何落选,以及什么情况下可以重新考虑。记录中价值最高的部分就在这里。它能避免团队在六个月后重新争论已经确定的方向;当需要以书面形式为决策辩护时,也能为 design-rationale(designer-toolkit)提供参考。
最佳实践
- 评审前明确由谁作决定——没有负责人的选择,最终往往由会议室里声音最大的人决定
- 也要用这些标准评估现有方案;不能因为当前设计先出现,就让它免于评审
- 保留落选概念,以便之后查阅,不要删除——只有在相关工作仍然存在时,重新审视才成本低
- 不要比较完成度不一致的方案;应先统一完成度,否则精修程度会替你作出决定
- 不适用于可在生产环境中衡量效果的改动——使用
a-b-test-design,让流量作出选择
评论
支持 Markdown