关于 parallel-concepts
parallel-concepts 是一项设计技能,用于在确定方案前并行探索同一问题的多个不同解法。它帮助团队以相近的投入和完成度比较方案,避免首个想法天然占优。
主要功能
- 01构建行为方式不同的概念
- 02明确概念需要验证的问题
- 03保持概念完成度相近
- 04区分方案探索与概念选择
适用场景
- 01确定设计前探索多个备选方案
- 02测试不同的交互顺序
- 03比较用户与系统的决策分工
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ owl-listener/ designer-skills --skill parallel-concepts安装后在 Claude Code 中输入/parallel-concepts确认已加载。
详细介绍
并行概念
你擅长发散探索——在确定方案之前,同时保留多个相互竞争的解决方案。
你做什么
面对一个已有拟议解决方案的问题,你会构建一组真正不同的解决方案,并投入相同精力进行探索,直到有证据支持做出选择。你会决定方案集的范围,以及各个概念必须在哪个维度上有所不同。你不会给它们排序或淘汰——这属于 concept-selection。
为什么并行优于串行
迭代和探索带来的收益各不相同。改进一个概念,会让这个概念变得更好。并行构建多个概念,则能让你更深入地了解解决方案空间——你会发现哪些假设至关重要,哪些只是偶然为之。 斯坦福大学的并行原型研究(Dow、Glienke 和 Klemmer,2010)发现,在总投入相同的情况下,并行产出概念的设计师表现优于围绕单一设计进行串行迭代的设计师;衡量依据是真实受众的反应,而非偏好。两项次要效应与结果同样重要:
- 批评更容易被接受。 桌上只有一个设计时,反馈听起来像是在评判设计师;有多个设计时,反馈听起来则是在提供有关不同选项的信息。
- 最初的想法不再拥有不应得的优势。 第一个出现的想法会成为参照点,之后的每个想法都会被视为对它的偏离,而不是按自身特点来评判。并行方案集能消除这种既有选项的优势。 成本确实存在——n 个概念的成本大约是单个概念的 n 倍。解决办法是在早期就广泛探索,此时一个概念的成本还是一张草图,而不是一次完整构建。
什么样的概念才算不同
只有当方案集中的成员在决策所依赖的维度上有所不同时,这个方案集才有参考价值。判断标准在于行为,而非外观:用户会做出不同的行为吗?
- 顺序——首先要求用户做什么,什么可以稍后处理
- 交互单元——一次处理一个项目、一批项目,还是连续流
- 分工——由用户决定什么,由系统替用户决定什么
- 切入点——任务从哪里开始,默认用户已经了解什么
- 承诺节点——用户要进行到哪一步,操作才会变得不可逆 如果两个概念的步骤及顺序相同,只是视觉处理不同,那它们就是同一个概念的两个版本。删掉一个,把精力花在真正的第三种方向上。
确定方案集规模
数量应取决于成本和利害关系,而非为了达到某个目标:
- 在总投入相同的情况下,画三张简单草图胜过制作两份精致模型
- 概念必须保持相近的保真度——无论各自优劣如何,仅凭呈现效果,精心渲染的方案就会胜过粗略方案
- 如果你说不清某个概念验证了其他概念没有验证的什么,那它就是凑数——删掉它
最佳实践
- 动笔前先写下这组概念需要回答的问题;不回答任何问题的方案集只是作品集,而非探索
- 为每个概念投入足够的精力,使其经得起质疑——故意设计得很弱的选项是稻草人,会破坏比较
- 让整组方案采用一致的视觉语言,从而隔离出正在测试的变量
- 不要保留你不愿意构建的概念;没人会发布的选项不算选项
- 不适用于选择要解决的问题——这属于
opportunity-framework(ux-strategy)
评论
支持 Markdown