AgentSkillsCN

complaint-storming-for-product-polish

通过集体共情诊断产品摩擦，并以专注的“爱之冲刺”加以化解。当团队对新用户失去同理心、UX 上的“小伤口”不断累积，或当路线图过于聚焦于 1% 的指标微调，却忽视了用户的真正体验与愉悦感时，可选用此技能。

SKILL.md
--- frontmatter
name: complaint-storming-for-product-polish
description: A two-part workflow to diagnose product friction through collective empathy and resolve it via dedicated "Love Sprints." Use this when the team has lost empathy for new users, when "UX paper cuts" are accumulating, or when the roadmap is too focused on 1% metric shifts at the expense of delight.

Complaint-Storming for Product Polish

Complaint-storming is a tactical ritual to combat "owner's delusion"—the bias where builders assume users care about their software as much as they do. It transforms abstract "UX debt" into a high-momentum "Customer Love Sprint" that raises the craft bar and improves user activation.

The Complaint-Storming Workflow

1. The External Calibration

Before looking at your own product, conduct a "storm" on an adjacent or competitor product. This lowers the team's defensive barriers and calibrates their "taste."

  • •Pick a Journey: Choose a specific flow (e.g., "The first 30 minutes" or "Setting up a new project").
  • •Live Walkthrough: One person shares their screen and goes through the flow in real-time.
  • •The Documentation: The rest of the team fills a document or Slack thread with every single point of confusion, friction, or visual "ugh" moment.
  • •Goal: Identify what makes a product "unpleasant" vs. "pleasant" without the bias of ownership.

2. The Internal Complaint-Storm

Repeat the process with your own live software. Do not use static mocks or Figma files; you must "smell the software" to feel the latency, awkward transitions, and copy issues.

  • •Adopt the Beginner’s Mind: Specifically look for "comprehension" (Do they know what this is?) and "desirability" (Why should they care?).
  • •Audit for Principles:
    • •Be a Great Host: Are we "putting clean towels on the bed," or is the user hunting for basic features?
    • •Don't Make Me Think: Is this step truly necessary? Can we save the user three clicks here?
    • •Confidence Over Clicks: Sometimes more clicks are better if they provide clarity and reduce user stress.

3. The Customer Love Sprint

Once you have a "burndown list" of complaints, dedicate a specific window (typically 2 weeks) to fix them.

  • •Selection Criteria: Focus on "lowest effort, highest delight" items. These are the small things that don't move a top-level KPI 1% but make a user say, "I love this tool."
  • •The "Ship-to-Learn" Rule: This is not a hackathon. The goal is to ship every single improvement to production by the end of the sprint.
  • •Frequency: High-user-facing teams should do this quarterly; backend/platform teams twice a year.

Application Example: The "Day 1" Journey

Context: A team building a messaging tool notices that while power users are happy, sign-ups from non-technical industries are dropping off after 48 hours.

The Complaint-Storm:

  • •External: The team walks through a simple consumer app (like Instagram) and notes how they feel "successful" within 30 seconds.
  • •Internal: They realize their own onboarding requires understanding Markdown to format a message.
  • •Complaint: "Why do I have to learn code just to bold a word?"

The Love Sprint Output:

  • •Implement a "What-You-See-Is-What-You-Get" (WYSIWYG) editor.
  • •Add a "Welcome Bot" that sends a delightful animation when the first 5 teammates join.
  • •Reduce the number of sidebar sections visible by default to prevent "Information Overload."

Success Metrics: The "Successful Teams" Threshold

Instead of focusing on raw sign-ups, measure the impact of your Love Sprints against an activation milestone.

  • •Slack's Threshold: 5 people using the tool for most of a work week.
  • •The Goal: Use Love Sprints to remove the friction preventing a team from reaching your specific "critical mass" number.

Common Pitfalls

  • •Storming in Figma: Static designs hide the most painful friction points like loading states, janky animations, and broken keyboard shortcuts. Always storm in the live product.
  • •Treating it as "Optional" Work: If Love Sprints aren't a dedicated block on the roadmap, they will always be deprioritized for "feature work."
  • •Ignoring the "Soup Tasting": Leaders should join the final session of a Love Sprint to "taste the soup" and ensure the level of polish meets the company's craft bar.
  • •Only Storming Your Own Product: Without the external calibration step, teams often become "blind" to their own product's flaws.