# Design Narrative

> DesignAgent Guardrails (Contract Compliance)

- Skill: `ahaoai/design-narrative` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add ahaoai/design-narrative`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ahaoai/design-narrative/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ahaoai (https://skillmd.com/u/ahaoai)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ahaoai/design-narrative

---

## DesignAgent Guardrails (Contract Compliance)

These are hard constraints. Do NOT violate:

- Do not skip any step in contract.json entry.steps
- Do not merge or reorder output sections
- Do not invent data or hallucinate facts
- Do not execute outside the defined step order
- If input is incomplete, ask only for missing required fields

---
name: design-narrative
description: "Use when presenting design work to clients, stakeholders, or portfolio — structure the design story, build persuasive rationale, and defend decisions with reasoning not just taste."
---

# Design Narrative

## Non-Negotiable Rule
**HARD GATE: Start with the problem, not the solution.** Present research and rationale before showing the work. Every design choice must trace to a strategic reason. No "I liked it" as defense.

## Overview
Design doesn't sell itself — it needs a story. This skill governs how to structure design presentations, build narratives around creative decisions, and defend work with rationale rather than "I liked it." Good narrative turns subjective preference into objective argument.

## When To Use
- Presenting concepts to clients or stakeholders
- Writing case studies or portfolio entries
- Defending design decisions in reviews
- Creating design proposals or pitches
- Documenting design rationale for handoff

## When NOT To Use
- "How do I present this?" as a vague question → use when you have content to structure
- Internal working sessions where narrative structure isn't needed
- Quick Slack updates (this is for formal presentations and documents)

## The Design Story Structure

### 1. Start With the Problem, Not the Solution
- "Here's what we learned about [users/context/challenge]"
- Frame the stakes: what happens if this isn't solved well?
- Make the audience feel the problem before seeing the answer

### 2. Show the Journey
- "We explored [X] directions because [rationale]"
- Show the thinking, not just the result
- Include what you tried and rejected — it proves rigor

### 3. Present the Solution as Inevitable
- "Given [research finding] and [constraint] and [goal], this direction follows naturally"
- Every visual choice should trace to a strategic reason
- Color choice → tied to brand personality or user need
- Typography choice → tied to tone of voice or readability requirement
- Layout choice → tied to user behavior or content hierarchy

### 4. Anticipate Objections
- Pre-empt the obvious concerns
- "You might wonder why we didn't [alternative approach] — here's why"
- This builds trust: you've already thought harder than they have

### 5. End With Next Steps, Not Questions
- Don't end with "What do you think?" — that invites subjective opinion
- End with "Here's what we recommend and why. Next step: [specific action]"
- You're the expert. Lead.

## The 3-Layer Rationale System
For every design decision, be prepared to defend at three levels:

| Layer | Question | Example Answer |
|-------|----------|----------------|
| **Strategic** | Why does this matter for the business/goal? | "This color system differentiates us from every competitor in the category." |
| **Functional** | Why does this work for the user? | "The high contrast ratio ensures readability for our older demographic." |
| **Aesthetic** | Why does this feel right? | "The rounded forms echo the brand's warmth and approachability." |

Weak presentations operate only at the aesthetic layer. Strong presentations lead with strategy.

## Case Study Format
For portfolios and documentation:
1. **Context**: client, challenge, constraints, timeline
2. **Problem**: what needed solving (specific, measurable)
3. **Process**: research → ideation → development (show the work)
4. **Solution**: the final design (visuals first, explanation second)
5. **Impact**: what happened? (metrics, testimonials, before/after)
6. **Reflection**: what would you do differently?

## Rationalization Prevention

| Excuse | Reality |
|--------|---------|
| "The work speaks for itself" | It doesn't. Great design unexplained is just decoration. |
| "I'll just walk them through the screens" | Stakeholders need narrative, not a tour. Tell the story or they'll write their own. |
| "I don't need to explain every choice" | Unexplained choices become targets for subjective revision. |

## Red Flags
- Your presentation starts with the logo
- You can't answer "why" for a key design choice
- You're nervous about objections you haven't pre-addressed
- The story is just "here's what I made"

- [ ] Problem stated before solution shown
- [ ] Every major design choice has strategic rationale
- [ ] At least one alternative shown and explained why not chosen
- [ ] Common objections pre-addressed
- [ ] Presentation ends with concrete next step, not open-ended question

## Ethical Design & Responsible Narrative

### Design Ethics Checklist
- [ ] **Representation**: Do the visuals represent the intended audience truthfully and respectfully?
- [ ] **Accessibility**: Can people with disabilities perceive, understand, and engage?
- [ ] **Dark Patterns**: Are any interaction patterns manipulative or deceptive?
- [ ] **Environmental Impact**: Do the design choices (print run, data load, material specs) consider sustainability?
- [ ] **Cultural Appropriation**: Are cultural symbols used with understanding and permission, not as decoration?
- [ ] **Data Privacy**: If the design involves user data, is consent clear and control in the user's hands?
- [ ] **Inclusive Language**: Is the copy free from bias related to gender, race, age, ability, or socioeconomic status?
- [ ] **Algorithmic Transparency**: If AI/ML systems are involved in the design, can users understand how decisions are made?

### Principles
- Design ethics is not a final checkbox — it runs through every phase.
- When an ethical concern surfaces at any stage, pause and raise it. The best narrative acknowledges hard choices.
- If you must compromise on an ethical dimension, document the trade-off explicitly.

## Verification
- [ ] Problem stated before solution shown
- [ ] Every major design choice has strategic rationale
- [ ] At least one alternative shown and explained why not chosen
- [ ] Common objections pre-addressed
- [ ] Presentation ends with concrete next step, not open-ended question
- [ ] Design ethics checklist reviewed