Experience design
- When to use it
- The experience around a product: the structure people navigate, the content and interface words they read, the components they use, and the service behind it all.
- Covers
- Design the experience (5)
- Where you decide
- No gated loop of its own; the skills run one at a time.
- Size
- 10 skills · 0 loops
1–3 hours for one product area a session
npx skilldrop-cli install --pack experience-design
Installs 10 skills, including core.
Other ways to install
The pack's loops too, each as an invokable skill:
npx skilldrop-cli install --loop --pack experience-design
In Claude Code, as a plugin (after /plugin marketplace add sananthanarayan/skilldrop):
/plugin install experience-design@skilldrop
Into Cursor, Kiro or another IDE:
npx skilldrop-cli install --pack experience-design --ide cursor
Start here: Restructure a menu users get lost in, and get the test that proves the new one works
Paste this into your agent:
Our help centre menu has grown to 15 items and customers can't find refunds or delivery tracking. Current menu: Getting Started, Account, Orders, Shipping, Delivery, Returns, Refunds, Payments, Gift Cards, Promotions, Membership, Privacy, Terms, Contact Us, Community. Design the information architecture and the tree test to validate it.
- Before you start
- A current menu, page list or feature list for the product, and who uses it
- How to tell it worked
- information-architecture returns an inventory with a keep/merge/cut status for every item, a sitemap tree and a Mermaid diagram that match, a label rationale table, findability risks for refunds and tracking, and tree-test tasks that don't use the menu's words.
- If nothing happens
- If you get a journey map instead, ask for it by name ("use information-architecture"). If labels look invented, give it your search terms or support ticket themes and ask it to tag every label's evidence.
A typical session
When: You're designing or fixing the experience around a product or service: how it's organised, what it says, how its components behave, and what happens behind the scenes. About 1–3 hours for one product area.
You bring:
- who the users are and their top tasks
- the current menu, page list or feature list
- existing page text, screenshots or wireframes for the flow you're working on
- your design tokens or brand kit, if you have one
- what you know about the teams and systems that deliver the service
-
- You
- Hand over the content or feature list and the users' top tasks.
- You get
- A sitemap and nav model with a label rationale table, findability risks, and a tree-test plan.
- You decide
- Run the tree test before building, or accept the structure as a hypothesis.
-
- You
- Pick a key page from the sitemap and give it the current text or the facts it must contain.
- You get
- User-need statements, the questions in priority order, a plain-language draft with a before/after readability check, and a cut list.
-
- You
- Give it the flow's screens or steps and your voice.
- You get
- A string table with budgets and variants for every button, label, error and empty state, plus a terminology list.
-
- You
- Name a component the flow needs and your token set.
- You get
- A component spec with anatomy, every state by token, keyboard and ARIA behaviour cited to WCAG 2.2, and open questions for engineering.
-
- You
- Describe one customer scenario and what you know about the teams and systems behind it.
- You get
- A blueprint table and Mermaid diagram with fail points, waits, pains traced to causes, and 2–3 ranked fixes.
- You decide
- Which fix becomes committed work.
-
- You
- Run it on any of the specs before you share them.
- You get
- A verdict and severity-tagged findings with a fix for each.
You end with: A tested-or-testable structure, the content and strings for a key page and flow, a buildable component spec, and a service blueprint with the fixes ranked.
Compare Experience design with another pack
Skills in this pack (5)
- content-design Write a content spec for a page or journey from user needs — user-need statements ("As a… I need… so that…"), the questions the page must answer in priority order, the page structure, a plain-language rewrite at a target reading level with a before/after readability check, and an explicit list of what to cut and why. Use when the user wants a content spec, content design, "rewrite this page in plain English", "what should this page say", "our page is too long and nobody reads it", or content for a service or journey. standard
- design-system-spec Write a design system component spec — purpose, anatomy, variants, every state (default, hover, focus, active, disabled, error, loading), the design tokens each part uses by name, behaviour, content rules, accessibility (keyboard, focus order, ARIA role, contrast, target size) cited to WCAG 2.2 criteria, do/don't examples, and the open questions engineering must answer. Use when the user wants a component spec, design system documentation, "spec out this button / modal / text field", a component's states and tokens, or a design-to-engineering hand-off for a component. standard
- information-architecture Design the information architecture for a product or site — a content inventory grouped by how users think, labels in their words, a navigation model split into global, local and utility nav, an indented sitemap plus a Mermaid diagram, a label rationale table, the findability risks, and the card-sort or tree-test plan that would validate it. Use when the user wants a sitemap, IA, navigation structure, menu design, "reorganise our help centre", "where should this page live", or says users "can't find anything". standard
- service-blueprint Build a service blueprint — per step, the evidence the customer sees, the customer's actions, frontstage staff and system actions, backstage actions, and support processes, separated by the lines of interaction, visibility and internal interaction, with fail points, wait times and owners marked — as a table plus a Mermaid diagram and the ranked fixes. Use when the user wants a service blueprint, "what happens behind the scenes when a customer does X", to find where a service breaks or stalls, or to take a journey map down to the people, systems and handoffs that deliver it. standard
- ux-writing Write the interface copy for a flow or component — buttons, labels, hints, errors, empty states, confirmations, loading and success messages — as a string table where each string has its context, a character budget, a recommended version and one variant, with error messages that say what happened and what to do next, and a terminology list so the same thing has the same name everywhere. Use when the user wants UI copy, microcopy, button text, error messages, empty states, "write the strings for this screen", or "our wording is inconsistent". standard
Included from core (5)
- brief-intake Turn raw mess — a Slack thread, meeting transcript, Jira ticket, half-written Notion page, email chain, or paragraph of free-form context — into a structured brief that the downstream skill (adr-generator, design-doc, runbook-generator, exec-summary, slide-outliner) can consume without further intake. Use whenever the user has unstructured source material and is about to invoke another skilldrop skill, or when a draft is missing the load-bearing context the next step will need. standard
- context-graph Map the decisions behind a codebase from its ADRs, RFCs and design records — each record's status and date, what supersedes or amends what, which records cite which, the files and folders each decision governs, and with git the commits that implemented it and the commits that changed each decision's code since it was made, and who made them — then answer "why is it like this?" from the record and check the record is still true. Finds supersessions only one side records, current decisions pointing at code that is gone, code that has drifted from its decision, two current decisions governing the same path, and references to records that don't exist. Use when the user asks "why do we use X", "which decisions govern this file or service", "is this ADR still current", "has the code drifted since we decided this", "are our ADRs out of date", "what was decided before I change this", wants a map of the architecture decisions, or is onboarding onto a codebase's history. standard
- council-review Convene a council of distinct senior-engineer personas (Architect, Security, Operator/SRE, Pragmatist, User-Advocate, plus optional bench seats) to deliberate a decision, design, or code change — each takes an independent stance, the genuine disagreements are surfaced as named cruxes, and a Chair issues a reconciled verdict that records dissents and states what would change the decision. The "Claude Council." Use when a choice has real tradeoffs and one reviewer's voice isn't enough: architecture decisions, risky changes before merge, RFC/design scrutiny, "should we adopt X?", rewrite-vs-refactor, or a pre-mortem. heavy
- doc-critique Review an existing document — ADR, design doc, runbook, exec summary, tech-comparison matrix, deck outline, decision log — and produce a structured critique against the same quality bars the skilldrop generators enforce. Categorizes findings by severity (blocker / major / minor / nit), points to the exact section/line, and suggests a concrete fix for each. Use when the user wants a second-pair-of-eyes review before sharing a doc, or has been handed someone else's artifact and wants to know what to push back on. heavy
- output-hygiene Review agent-written text before it ships and strip the machine artifacts it carries — invisible Unicode, non-breaking spaces, homoglyphs, harness-added provenance trailers, trailing chat closers — then flag the prose tells a script cannot catch, each quoted with a rewrite. Use when the user wants to clean up AI-generated output, asks to remove a Claude watermark, attribution footer, or "Generated with" line, wants a draft that does not read as machine-written, or needs a pre-ship hygiene pass on a document, commit message, or pasted chat answer. standard