Back to Details

customer-centric-design

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Customer-Centric Design

以客户为中心的设计

This skill guides engineers and designers toward the right methodology for understanding users and validating solutions. It emphasizes solving real problems for real people.
这项技能指导工程师和设计师采用正确的方法论去理解用户、验证解决方案，核心是为真实用户解决真实问题。

Use-When

适用场景

This skill activates when:
  • Agent designs a new feature or product
  • Agent asks "how do I know this is a real problem?"
  • Agent needs to choose between qualitative vs quantitative research
  • Agent wants to validate a design before building
  • Agent asks "what metrics should I track?"
  • Agent receives user feedback requesting a feature
  • Agent needs to measure design impact
当出现以下情况时可启用这项技能：
  • Agent设计新功能或产品
  • Agent提出“我如何确定这是真实存在的问题？”
  • Agent需要在定性研究与定量研究之间做选择
  • Agent希望在开发前验证设计方案
  • Agent提出“我应该跟踪哪些指标？”
  • Agent收到用户要求新增功能的反馈
  • Agent需要衡量设计的影响

Core Rules

核心原则

  • ALWAYS validate the problem exists before designing a solution
  • ALWAYS define success metrics before building
  • ALWAYS choose methodology based on knowledge gap, not preference
  • NEVER assume you know what users need without evidence
  • ALWAYS validate design with actual users before shipping
  • 始终在设计解决方案前验证问题是否真实存在
  • 始终在开发前定义成功指标
  • 始终基于认知缺口而非个人偏好选择方法论
  • 绝不要在没有证据的情况下假设自己了解用户需求
  • 始终在产品上线前与真实用户一起验证设计方案

Common Agent Mistakes

Agent常见错误

  • Building features based on assumptions without problem validation
  • Choosing research methods randomly instead of matching to situation
  • Tracking vanity metrics that don't correlate with user success
  • Skipping user validation because "it's obvious"
  • Measuring activity instead of outcomes
  • 未验证问题就基于假设开发功能
  • 随机选择研究方法而非结合实际场景匹配
  • 跟踪与用户成功无关的虚荣指标
  • 以“这很明显”为由跳过用户验证环节
  • 只衡量用户活跃度而非实际成果

Methodology Decision Tree

方法论决策树

Use this decision framework to choose your approach:
Is the problem well-understood?
├── YES: Do users already complain about it?
│   ├── YES → Validate with analytics + quick usability test
│   └── NO → Optimize existing flow, measure impact
└── NO: Is this a new problem space?
    ├── YES → Qualitative research (interviews, observations)
    └── UNCERTAIN → Hybrid: qualitative discovery + quantitative validation
使用以下决策框架选择合适的方法：
问题是否已充分理解？
├── 是：用户是否已经对此抱怨？
│   ├── 是 → 通过数据分析+快速可用性测试进行验证
│   └── 否 → 优化现有流程，衡量影响
└── 否：是否属于全新问题领域？
    ├── 是 → 采用定性研究（访谈、观察）
    └── 不确定 → 混合模式：定性探索+定量验证

Examples

示例

✅ Correct

✅ 正确做法

tsx
// Before: Validating the problem exists
// Step 1: Talk to 5 customers about the pain point
// Step 2: Check support tickets for related issues
// Step 3: Analyze product analytics for drop-off points

// Step 4: Define success metrics BEFORE building
const successMetrics = {
  leading: "time-to-complete",    // What we can move
  lagging: "completion-rate",     // The outcome
  guardrail: "error-rate",        // What we must not hurt
}

// Step 5: Validate with prototype before full build
// Run usability test with 5 users on Figma prototype
tsx
// 前置步骤：验证问题是否存在
// 步骤1：与5位客户沟通痛点
// 步骤2：查看支持工单中的相关问题
// 步骤3：分析产品数据中的流失节点

// 步骤4：在开发前定义成功指标
const successMetrics = {
  leading: "time-to-complete",    // 可优化的前置指标
  lagging: "completion-rate",     // 最终成果指标
  guardrail: "error-rate",        // 不可恶化的保障指标
}

// 步骤5：在完整开发前用原型验证
// 基于Figma原型与5位用户进行可用性测试

❌ Wrong

❌ 错误做法

tsx
// Wrong: Building without problem validation
// "Users probably want dark mode, let's add it"

// Wrong: Choosing methodology arbitrarily
// "Let's run a survey" (when you need deep understanding)

// Wrong: Vanity metrics
analytics.track("button-clicks")  // Activity, not outcome

// Wrong: No validation before shipping
// "It looks good, let's ship and see what happens"
tsx
// 错误：未验证问题就开发
// “用户可能想要深色模式，我们来做这个功能”

// 错误：随意选择研究方法
// “我们做个调研吧”（而实际需要的是深度理解）

// 错误：跟踪虚荣指标
analytics.track("button-clicks")  // 仅衡量活跃度，而非实际成果

// 错误：上线前未做验证
// “看起来不错，直接上线看看效果”

References

参考资料