Stats
Actions
Tags
From max
Explore multiple radically different interface designs for a feature in parallel before committing to one. Uses parallel sub-agents to generate distinct approaches so you can compare tradeoffs rather than anchoring on the first idea. For UI/UX interface work specifically — not API interface design. Use when the user says "design-interface", "let's explore some designs for X", "what are the options for this screen", or before building any non-trivial UI.
How this skill is triggered — by the user, by Claude, or both
Slash command
/max:design-interfaceThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Generate multiple radically different design explorations for a UI feature in parallel, then compare them. The point is to *avoid* anchoring on the first idea — most designs are worse than they could be because the first sketch becomes the spec.
Generate multiple radically different design explorations for a UI feature in parallel, then compare them. The point is to avoid anchoring on the first idea — most designs are worse than they could be because the first sketch becomes the spec.
Inspired by Matt Pocock's design-an-interface. Adapted for visual/UX design exploration rather than code API design.
Input: a description of what you need to design + (optional) constraints (platform, style guide, accessibility requirements).
Output: 3-5 distinct design explorations as markdown + sketch descriptions, presented side-by-side so the user can compare. No code, no mockups — descriptions detailed enough that a designer or developer could build any of them.
What this skill does NOT do: write implementation code, build actual mockups in Figma, or commit to a design. It produces explorations for the user to evaluate. The follow-up (implementation, prototyping) is a separate workflow.
This is for visual/UX design. For API or type interface design, use max:tech-spec instead.
Before exploring solutions, nail down the problem. Gather just enough to brief parallel agents — not a full PRD.
Intake checklist (ask one at a time, skip what's already answered):
If the user already has a PRD, read it instead of asking. Extract the intake answers from it.
Before spawning explorations, identify the axes along which designs can vary. This is the most important step — without explicit dimensions, parallel agents converge on the average and produce 5 variations of the same idea.
Dimension library (pick 2-3 where variation matters most for this feature):
Navigation & structure
Density & pacing
Interaction style
Visual weight
Orientation
Temporal
Pick 2-3 dimensions where variation matters most for THIS feature. Each parallel exploration will occupy a different corner of that dimension space.
Example — for "a new sidebar to browse workspaces":
That gives up to 3×2×2 = 12 possible corners. Pick 3-5 corners that are maximally different.
Dispatch 3-5 parallel sub-agents, each with a distinct brief. Concurrent dispatch prevents anchoring — if the explorations run sequentially, later ones anchor on earlier ones.
Dispatch mechanism: use the Agent tool with multiple concurrent calls in a single message. Each call is a separate agent instance with a distinct brief. If concurrent Agent tool calls aren't available in the environment, fall back to a single agent with explicit instructions: "Generate N distinct designs, treating each as if it were produced by a different designer who hasn't seen the others."
Brief template for each parallel exploration:
You are designing a <feature type> for <user type> on <platform>.
Context: <1-2 sentences from Phase 1 intake>
Your assigned design corner:
- <Dimension 1>: <value — be specific>
- <Dimension 2>: <value>
- <Dimension 3>: <value>
Constraints:
- <platform>
- <accessibility>
- <any other hard constraints>
Be opinionated. Don't hedge. Propose something that MAXIMIZES your corner's
strengths and accepts its weaknesses. Do not produce a balanced or compromise
design — that's what averaging produces, and averaging is what we're trying
to avoid.
Describe the design in enough detail to visualize it:
- Overall layout (positions, proportions, key regions)
- Interaction flow (how the user accomplishes the primary task)
- Visual treatment (typography, color use, chrome, affordances)
- Key moments (first-run, empty state, error state, success state)
Do NOT:
- Write code or implementation details
- Reference specific Figma components or libraries
- Hedge with "this could also..."
- Propose multiple alternatives within your design
Output: a markdown description of ONE design, 300-600 words, structured as:
- Name (captures the key design choice)
- Overview (2-3 sentences)
- Layout
- Interaction
- Visual treatment
- Strengths (2-3 specific benefits)
- Weaknesses (2-3 specific costs — be honest)
- Best for (the user or use case this excels at)
The goal is that the 3-5 designs are distinguishably different — not 5 variations of the same idea.
Collect the outputs and present them to the user in a comparison format that forces explicit tradeoff visibility:
# Design Explorations: <Feature Name>
## Brief recap
<2-3 sentences of what's being designed, for whom, on what platform.>
## Dimensions explored
- <Dimension 1>: <values we explored>
- <Dimension 2>: <values>
- <Dimension 3>: <values>
## Option A: <Name>
**Corner:** <Dimension 1 value, Dimension 2 value, ...>
**Overview:** <2-3 sentences>
**Layout:** <description>
**Interaction:** <description>
**Visual treatment:** <description>
**Strengths:**
- <specific benefit>
- <specific benefit>
**Weaknesses:**
- <specific cost>
- <specific cost>
**Best for:** <the kind of user or use case this excels at>
---
## Option B: <Name>
...
---
## Comparison matrix
| Attribute | A | B | C | D | E |
|---|---|---|---|---|---|
| Speed to learn | 3 | 5 | 2 | 4 | 3 |
| Density (1=sparse, 5=dense) | 5 | 2 | 4 | 3 | 3 |
| Flexibility | 2 | 4 | 5 | 3 | 4 |
| Accessibility | 4 | 3 | 3 | 5 | 4 |
| Feels Bugbook-y | 5 | 2 | 3 | 4 | 3 |
| Implementation effort | Low | High | Medium | Low | Medium |
(Customize the rows to match what matters for this feature. Don't use generic rubrics — pick attributes that reveal the tradeoffs.)
Don't rank the designs for the user. Present the tradeoffs; let the user decide which tradeoffs matter.
Ask the user: "Which option resonates, or do you want to explore further along a specific dimension?"
Possible user responses:
Write the selected (or synthesized) design to docs/designs/<slug>.md. Include all the explorations that were considered so future-you can see the tradeoff space:
# <Feature Name> — Design
## Selected design: Option C (or synthesis of A + C)
<full description>
## Rationale
<why this one won over the others>
## Explorations considered
<summaries of A, B, C, D, E with links to full descriptions in an appendix>
## Appendix: full exploration writeups
<all 5 explorations in full>
Return the path to the caller.
design-an-interface skill — the parallel-agent framingGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.
npx claudepluginhub max4c/skills --plugin max