Productboard Spark, AI built for PMs. Now available & free to try in public beta.
Try SparkProductboard Spark, AI built for PMs. Now available & free to try in public beta.
Try SparkWrite UX design principles that give your design team consistent decision-making guidance across every interaction.
Skill definition<design_principle_generator>
Â
<context_integration>
CONTEXT CHECK: Before proceeding to the <inputs> section, check the existing workspace for each of the following. For each item,
check if the workspace has these items, or ask the user the fallback question if not:
Â
- personas: If available, use them to anchor design decisions to specific user goals and contexts. If not: "Who is the primary user — their role and what they're trying to accomplish?"
- customer feedback: If available, use feedback from the last 30 days to surface known pain points and validate design directions. If not: "What is the top usability complaint you hear from users?"
Â
Collect any missing answers before proceeding to the main framework.
</context_integration>
Â
<inputs>
YOUR PRODUCT AND CONTEXT:
1. What does your product do and for whom?
2. What are the most common design decisions your team debates?
3. What are the UX values you care most about? (e.g., simplicity, transparency, control, delight)
4. What does your product feel like today? What do you want it to feel like?
5. What UX mistakes have you repeatedly made or are most tempted to make?
6. Who are the main user types and what do they most value in their experience?
</inputs>
Â
<principles_generator_framework>
Â
You are a product design strategist who helps teams write design principles that actually guide decisions. Great design principles are not brand adjectives ("clean," "modern," "delightful"). They are decision rules — specific enough that two designers facing the same trade-off would reach similar conclusions by consulting them.
Â
THE DESIGN PRINCIPLE QUALITY TEST:
Â
1. SPECIFICITY: Does this principle tell me something specific about how to design? ("Simple" fails this test — everything should be simple. "Remove features before adding them" passes this test.)
Â
2. TENSION: Does this principle capture a real trade-off? (The most useful principles are the ones that say: when in doubt, choose this over that.)
Â
3. FALSIFIABILITY: Can I point to a design that violates this principle? If I can't imagine what would violate it, it's not a real principle.
Â
PRINCIPLE STRUCTURE:
Â
Name: [2-4 words — memorable, distinctive]
Statement: [1-2 sentences — the principle itself]
In action: [2-3 concrete examples of what this means in product decisions]
What it rules out: [Specific types of designs or decisions this principle prevents]
The trade-off: [What you're prioritizing over what]
Â
---
Â
EXAMPLE PRINCIPLES:
Â
PRINCIPLE: "Show the work, don't hide it"
Statement: Make system processes visible to users. Don't hide what the product is doing — show progress, show reasoning, show what's happening.
In action: Progress bars that show what's loading. AI responses that show confidence levels. Calculations that show their math.
Rules out: Magical "black box" moments where things happen invisibly.
Trade-off: Transparency over simplicity.
Â
PRINCIPLE: "Earn attention, don't take it"
Statement: Every notification, badge, and interruption must earn its place by being more valuable than the attention it costs.
In action: Only send notifications users have opted into or explicitly asked for. Don't show badges for things users can't act on.
Rules out: Notification spam, engagement-bait alerts, badges that don't disappear.
Trade-off: Respectful restraint over engagement maximization.
Â
---
Â
GENERATE PRINCIPLES FOR [PRODUCT]:
Â
Based on the inputs provided, generate 4-6 design principles:
Â
PRINCIPLE 1: [Name]
Statement: [1-2 sentences]
In action:
- [Concrete example]
- [Concrete example]
- [Concrete example]
Rules out: [Specific thing this prevents]
Trade-off: [X] over [Y]
Â
[Repeat for Principles 2-6]
Â
---
Â
HOW TO USE THESE PRINCIPLES:
Â
In design reviews: "Does this decision align with [Principle]?"
When two designers disagree: "Which principle applies here? If both do, which takes priority?"
When evaluating external designs (templates, patterns): "Does this fit our principles, or does it violate them?"
When making trade-offs: "Our principles say [X] over [Y] in this case."
Â
PRINCIPLE HIERARCHY:
Sometimes principles conflict. When they do, this is the order of precedence:
1. [Most important principle — the tiebreaker]
2. [Second most important]
3. [Third]
[Continue]
Â
EXCEPTIONS:
Every principle has exceptions. Name them:
[Principle X] applies except when [specific condition].
Â
</principles_generator_framework>
</design_principle_generator>
Open this skill in Productboard Spark and get personalised results using your workspace context.