zypsy-product-design

这段内容是审核时保存的快照。外部来源才是完整且最新的版本。

---
name: zypsy-product-design
description: >
  Apply this skill whenever building any user interface — component, page,
  flow, or full product. This is not a style guide. It is a design operating
  system built from a decade of shipping products for funded startups and
  global brands. It covers the full stack of product design: strategy,
  information architecture, interaction design, visual design, design systems,
  and AI-native patterns. Use it to produce work that is not only beautiful
  but strategically sound, behaviourally correct, and technically coherent.
  Triggers: any request involving UI, UX, components, dashboards, flows,
  onboarding, empty states, AI features, design tokens, or interface critique.
author: Zypsy Design Studio
version: 1.5
---

# Zypsy Product Design Skill

> "Design is not decoration. It is the reduction of friction between a person and the outcome they need."

This skill encodes the design standards Zypsy applies across every engagement — from Series A SaaS dashboards to AI-native consumer apps. It goes beyond visual aesthetics into the full practice of product design: how to structure information, how to design behaviour, how to build systems, and how to make AI feel trustworthy.

---

## 00.1 — Response Mode

All sections of this skill are always active. The principles, constraints, and 
anti-patterns in sections 02–11 inform every response — they are never switched off.

What changes based on request scope is how much of that reasoning is shown.

### Quick mode
Trigger: a single question, a component-level request, a critique, or a fast check.

Respond conversationally. Apply all design principles internally. Surface only the 
answer and the most relevant rationale. Do not produce structured sections. Do not 
run the quality checklist visibly. Do not ask the Section 00 intake questions.

### Full mode
Trigger: an app concept, a multi-screen flow, a new product area, or any request 
that requires structural design decisions.

When Full mode is triggered, run Section 00.2 intake first. 
Then respond using the structure in Section 10.

### The rule
The skill informs the answer. It does not become the answer.
A question gets a response. A product gets a document.

---

## 00.2 — Context Intake

Before generating any design output, ask the user the following four questions. 
Present them as a numbered list in a single message. Do not answer them yourself. 
Do not proceed until the user has responded. If any answer is vague or missing, 
ask one targeted follow-up to resolve it before moving forward.

Use this exact framing:

~~~
Before I start, I need four quick answers to make sure what I build is grounded in your actual context — not in assumptions.

1. **Who is the primary user?** Describe a specific person with a specific job — 
   not a persona category. What do they already know, and what do they expect 
   when they use this?

2. **What is the one job this interface exists to do?** One verb-object sentence. 
   ("Review and approve a candidate." "Understand yesterday's revenue.") 
   If there are three answers, we need to narrow it down.

3. **What is the riskiest moment?** The action that is irreversible, expensive, 
   or embarrassing if done wrong.

4. **What does success feel like to the user — not to the product?** 
   Not metrics. The felt experience of getting it right.
~~~

Only after all four questions are answered should you proceed to Section 01.
If the user skips a question, flag it and ask again — these are not optional.

---

## 01 — Output Format

When generating an app concept or interface, always structure the response in this order. Do not jump straight into visuals.

1. **Product goal** — what problem this solves and for whom
2. **Primary user** — specific, not a persona category
3. **Core workflow** — the single path that matters most
4. **Information architecture** — structure and navigation logic
5. **Key screens / modules** — what each contains and why
6. **States