ui-design-direction

Files (7)

• SKILL.md
• anti-slop.md · references/
• dashboard-data-dense.md · references/
• design-system-component.md · references/
• marketing-editorial.md · references/
• product-app.md · references/
• redesign-existing.md · references/

SKILL.md (first lines)

# Design Direction

Own the product's visual and interaction direction, not its component implementation, React architecture, motion mechanics, or final verification.

This skill is an expanded derivative of the dial-driven and anti-slop ideas popularized by Leonxlnx's MIT-licensed Taste Skill. It broadens the scope from expressive web surfaces to product applications, dashboards, admin/data-dense interfaces, reusable component systems, and redesigns. See the repository's third-party notices for attribution.

## 1. Read the product before styling it

Do not begin from a favorite aesthetic. Infer the interface from the brief, repository, running product, brand assets, existing design system, target users, primary tasks, and constraints.

Classify the dominant surface:

- **marketing/editorial** — narrative, persuasion, identity, storytelling, portfolio, launch, content-led surfaces;
- **product/app** — repeated task completion, navigation, forms, settings, collaboration, workflow UI;
- **dashboard/data-dense** — monitoring, comparison, scanning, filtering, tables, analytics, operations;
- **design-system/component** — reusable primitives, composites, states, tokens and interaction conventions;
- **redesign/existing** — preserve intentional product knowledge while reducing accidental inconsistency.

Mixed products may use more than one mode. Choose one dominant mode per surface rather than averaging everything into a generic compromise.

Load only the matching reference file(s):

- `references/marketing-editorial.md`
- `references/product-app.md`
- `references/dashboard-data-dense.md`
- `references/design-system-component.md`
- `references/redesign-existing.md`
- `references/anti-slop.md` when visual direction risks generic AI output or visual over-decoration.

## 2. Infer the three expressive dials

Use the following 1–10 dials as a compact design-language model. Infer them from context; do not ask the user to numerically configure them unless numbers are explicitly useful.

### DESIGN_VARIANCE
How far composition may depart from conventional symmetry and expected layout patterns.

- 1–3: highly predictable, utility-first, operational
- 4–6: distinctive within familiar product patterns
- 7–10: expressive, asymmetric, art-directed

### MOTION_INTENSITY
How much motion contributes to expression and spatial continuity.

- 1–3: state feedback and restrained transitions
- 4–6: selective continuity and expressive transitions
- 7–10: motion-forward narrative/brand experience

This is a direction dial only. Detailed motion decisions belong to `ui-motion`.

### VISUAL_DENSITY
How much useful information and control is presented per viewport.

- 1–3: spacious, editorial, low task pressure
- 4–6: balanced general product density
- 7–10: compact, operational, data-heavy

Density is not clutter. High-density UI still needs grouping, hierarchy, scan paths, and predictable alignment.

## 3. Infer operational constraints

Expressive dials are not enough for product UI. Also classify these constraints as low / medium / high when relevant:

- **task frequency** — how often users repeat the primary action;
- **information criticality** — cost of overlooking or misreading information;
- **error cost** — impact of an incorrect action;
- **interaction depth** — number and complexity of states/steps involved;
- **navigation complexity** — breadth/depth of destinations and context switching;
- **data complexity** — amount, dimensionality and comparability of data.

Use them to constrain aesthetics.

Examples:

- high task frequency -> faster, quieter interactions; less decorative interruption;
- high error cost -> clearer confirmation, stronger distinctions, less ambiguous minimalism;
- high information criticality -> stronger hierarchy, persistent state cues, less reliance on subtle color alone;
- high data complexity -> stable alignment, strong scan structure, controlled density;
- high navigation complexity -> predictable information architecture beats experimental composition.

## 4. Establish the direction contract

Before substantial implementation, produce a compact direction contract containing only decisions that matter:

1. **surface mode** and dominant user job;
2. **variance / motion / density** direction;
3. important operational constraints;
4. visual hierarchy and layout character;
5. typography character and role structure;
6. color/surface/elevation character;
7. radius and shape language;
8. icon/illustration/media character when applicable;
9. motion character at a high level;
10. must-preserve existing decisions;
11. explicit anti-patterns to avoid for this product;
12. design-system implications: tokens, reusable patterns, states or primitives that need to exist.

Do not turn this into a long mood-board essay. The contract should be actionable by the component system.

## 5. Convert taste into system decisions

Aesthetic adjectives are not sufficient.

Translate accepted direction into reusable rules, for example:

- “quiet cards” -> hierarchy comes from spacing, surface contrast and subtle borders before shadows;
- “compact operations UI” -> smaller vertical rhythm, stable row heights, tabular alignment, restrained animation;
- “editorial premium” -> stronger type contrast, longer composition rhythm, fewer but more deliberate containers;
- “high-trust admin” -> explicit state labels, conservative destructive actions, predictable controls and persistent context.

Route detailed token/component-system work back to the UI Engineering design-system reference and shadcn/component layer.

## 6. Preserve product usefulness over visual novelty

When aesthetics conflict with task performance, use the operational constraints to decide.

Prefer familiarity for high-frequency or high-risk actions. Spend visual novelty on low-risk, low-frequency, identity-bearing surfaces.

Consistency does not mean every product surface must be identical. Reuse interaction patterns where familiarity reduces cognitive load while allowing presentation to adapt to the surface's job.

From hersti/ui-engineering, MIT.

More from hersti/ui-engineering