Case study design decisions
Skill jpoindexter/design-case-study-skills/skills/case-study-design-decisions
Evidence-backed UX and AI-agent case study skills for Codex and Claude
npx -y skills add jpoindexter/design-case-study-skills --skill case-study-design-decisionsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 14 days oldThe repository was created 14 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Explain and defend pivotal design decisions in a case study using stakeholder context, user and business evidence, alternatives, constraints, trade-offs, consequences, limitations, and follow-up. Use when a portfolio draft shows screens without rationale, lists activities instead of decisions, needs executive credibility, must explain rejected options, or must communicate complex enterprise, platform, system, or AI-agent design choices.
SKILL.md
1.8 KB, as published. Nobody here has run it
Case Study Design Decisions
Make the decision legible to a skeptical non-designer. Read references/decide-record.md.
Workflow
- Identify the reader’s influence, priorities, vocabulary, and likely objection.
- Select only decisions that changed user outcomes, system behavior, risk, cost, or delivery.
- Complete a DECIDE record for each pivotal decision.
- Connect design evidence, business consequences, technical constraints, and limitations.
- Represent rejected alternatives fairly.
- State what agreement enabled and what happened next.
- Remove aesthetic rationale that does not affect use, comprehension, trust, or performance.
Communication pattern
For each decision:
- set context before showing the artifact;
- name the problem and tension;
- explain the choice in the reader’s language;
- ground the rationale in users, business, research, and constraints;
- acknowledge limitations without weakening the argument;
- show the decision or learning that followed.
Do not hide uncertainty or pretend consensus existed. Distinguish the design recommendation from the final organizational decision.
Output
Return a decision shortlist, completed DECIDE records, likely stakeholder questions, and recommended captions or callouts for the associated visuals.