customer-centric-design

Customer-obsessed design methodology. Use when designing features, validating problems, choosing research methods, or measuring design success.

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "customer-centric-design" with this command: npx skills add moderndegree/agent-skills/moderndegree-agent-skills-customer-centric-design

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

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

  • 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

// 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

❌ Wrong

// 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"

References

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

Automation

design-systems

No summary provided by upstream source.

Repository SourceNeeds Review
Automation

dialogs-modals

No summary provided by upstream source.

Repository SourceNeeds Review
Automation

shadcn-best-practices

No summary provided by upstream source.

Repository SourceNeeds Review
Automation

form-design

No summary provided by upstream source.

Repository SourceNeeds Review