mcpField
L
layers-orient

layers-orient

github.com/jamiemill设计与 UI3132.0k 次安装22 周前更新
代码仓库

关于 layers-orient

面向设计师的快速诊断技能,用于判断设计工作下一步应聚焦何处。它审查七个层面的决策,找出基础瓶颈,并推荐相关技能。

主要功能

  1. 01审查七个层面的决策
  2. 02评估决策稳固度与假设
  3. 03识别基础瓶颈
  4. 04推荐后续技能

适用场景

  1. 01及早发现产品设计中的缺口
  2. 02区分已验证决策与假设
  3. 03选择下一步处理的设计层面

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/jamiemill/layers-skills --skill layers-orient

安装后在 Claude Code 中输入/layers-orient确认已加载。

详细介绍

/layers-orient

假设已加载 /layers-intro,以了解框架背景。

Orient 是一种快速诊断方式,是寻找其他技能要处理的当前决策的入口。它会梳理七个层面的当前决策状态,找出瓶颈——存在未解决或有风险决策的最低层——并建议下一步应聚焦的方向。

它不会深入探讨任何层面,那是各个层面技能的职责。Orient 回答的是更优先的问题:哪个层面最亟需关注? 保持快速、轻量——输出应是一份简短审查和一条建议,而不是报告。

评估内容:

  • 每个层面的关键决策是否已做出,以及决策有多稳固
  • 被视为稳固的决策是否其实只是一些假设
  • 哪个层面最具基础性,且仍有未完成的工作,从而给其上方的所有层面带来风险

质量信号——Orient 做得好的标志:

  • 明确指出瓶颈层面,而不是含糊其辞
  • 区分假设层面和 Strong 层面——它们需要不同的应对方式
  • 建议明确关联到具体技能,并说明理由

引导式会话

描述你的设计情况,以及是什么促使你着手处理它;或者说“开始梳理”来启动。

(记录信息为可选且轻量——参见 /layers-intro。对于 Orient,通常只需保留审查表。)

然后询问:

  1. 你正在做什么产品或功能?
  2. 你目前面临什么设计挑战?
  3. 这项工作进展到什么阶段——早期探索、积极设计,还是修复现有产品中的问题?

留意哪些层面已经梳理过,哪些层面还不完善或缺失。


层面审查

通过一两个有针对性的问题逐一检查每个层面。评级为: Strong / Partial / Assumed / Weak / Not started / N/A

观察到的行为 “你有哪些用户研究资料?你是否与用户交谈过、观察过他们,或有分析数据?还是说,这主要基于团队对用户行为的判断?”

领域 “你对该产品所处的领域了解多少——包括现实世界中的概念、术语,以及产品出现之前用户的思维方式?”

用户需求 “你能否说明用户试图实现什么目标——不是功能,而是其根本任务以及为何重要?你是否有任务故事或类似资料?”

产品与服务策略 “你是否清楚这项工作针对哪项具体用户需求,以及它旨在推动什么业务成果?机会与业务目标之间的联系是明确的,还是非正式的?”

概念模型 “产品是否对其处理的对象有清晰的模型——包括存在的事物、它们之间的联系,以及所使用的词汇?团队成员是否对此有共识,还是每个人都有自己的版本?”

交互结构与流程 “你是否清楚关键用户旅程——涉及哪些位置、步骤和决策点?是否有面包板、粗略流程、可运行代码,或可供你讲述的说明?”

界面 “是否已有需要与之匹配的设计系统、视觉语言或组件库?”


决策全景

将审查结果整理成表格:

Layer                      | State       | Notes
---------------------------|-------------|----------------------------------------
Observed behaviour         |             |
The domain                 |             |
User needs                 |             |
Product & service strategy |             |
Conceptual model           |             |
Interaction structure      |             |
Surface                    |             |

瓶颈分析

找出瓶颈层面:状态为 Weak、Assumed 或 Not started 的最低层。明确说明缺少哪些决策,以及这会给其上方的层面带来什么风险。

同时指出假设层面——那些被视为已做出决策、但尚未验证的层面。看似稳固的假设往往隐藏着最危险的决策。

如果设计师有会影响判断的截止日期或限制,请予以说明。有时正确的做法并非选择最具基础性的方向——应明确指出这种权衡,而不是置之不理。


推荐

推荐接下来运行某个特定技能,并说明原因:

  • 概念模型 → /layers-conceptual-model
  • 产品策略 → /layers-product-strategy
  • 用户需求 → /layers-user-needs
  • 领域 → /layers-domain
  • 交互结构 → /layers-interaction-flow
  • 观察到的行为 → /layers-observed-behaviour

结尾写上:"Want to run [skill] now, or is there something in this picture to push back on first?"

评论

支持 Markdown