mcpField
C
concept-selection

concept-selection

github.com/owl-listener设计与 UI3.1k693 次安装8 周前更新
代码仓库

关于 concept-selection

用于设计团队收敛设计方向的决策技能:先设定可检验标准,再比较概念、记录选择及落选原因。强调证据、取舍与复议条件,而非偏好投票。

主要功能

  1. 01比较前定义门槛与权衡标准
  2. 02将标准应用于所有候选方案
  3. 03记录胜出方案的代价与复议条件
  4. 04说明落选方案及其重启条件
  5. 05区分优先级冲突与设计问题

适用场景

  1. 01评审多种设计概念并确定方向
  2. 02记录设计取舍,避免团队反复争论
  3. 03发现标准冲突并升级决策
  4. 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