Mental model
These are the artifacts that leave the team. They are read by people who did not attend the meeting, will not read the Figma, and are deciding whether to fund, approve, or hire.
- Lead with the decision you want. A proposal that opens with your process makes the reader hunt for the ask. Put scope, timeline and price in the first screen.
- Show the problem before the solution. A case study that opens on the final UI reads as a portfolio piece. One that opens on the broken funnel reads as evidence.
- Quantify or say you cannot. "Improved usability" is noise. "Cut checkout abandonment from 71% to 54% over six weeks" is an argument. If you have no number, say what you observed instead of reaching for an adjective.
- Scope is a fence, not a wish. Every proposal names what is excluded. The excluded list prevents more disputes than the included one.
Index
| Artifact | Reference |
|---|---|
| Redesign, new product, design system, UX audit, retainer proposals | proposal-templates.md |
| Statement of work, scope fencing, pricing structure | proposal-templates.md |
| Design review deck, stakeholder direction pitch | pitch-presentation-templates.md |
| E-commerce and SaaS case study narratives | case-study-templates.md |
| Portfolio case study structure | case-study-templates.md |
| Figma handoff practice, developer checklist | client-handoff-templates.md |
| Token export, asset export | client-handoff-templates.md |
| Design spec format, component docs, interaction spec | design-documentation.md |
| Invoice structure, line items, payment terms | invoice-and-billing.md |
Reference architecture
| File | Covers | Lines |
|---|---|---|
references/client-handoff-templates.md |
handoff and export | 1054 |
references/proposal-templates.md |
5 proposal types | 1016 |
references/design-documentation.md |
specs and component docs | 978 |
references/case-study-templates.md |
narrative + 2 templates | 920 |
references/pitch-presentation-templates.md |
2 deck templates | 851 |
references/invoice-and-billing.md |
billing artifacts | 53 |
What every reference file contains
- The template as fill-in-the-blank prose, not a description of a template
- A worked example with realistic numbers
- What the reader is deciding, and what they need to decide it
- The section people cut that they should not
Routing
For winning the work — redesign, new-product, design-system, UX-audit and
ongoing-retainer proposals: read references/proposal-templates.md.
For presenting — design review decks and stakeholder decks for pitching a
direction: read references/pitch-presentation-templates.md.
For telling the story afterwards — the case study narrative structure plus
e-commerce and SaaS templates: read references/case-study-templates.md.
For handing off to engineering — Figma handoff practice, the developer
checklist, token export and asset export: read
references/client-handoff-templates.md.
For documenting the system — design spec format, component documentation and
interaction specification: read references/design-documentation.md.
For odds and ends — the patterns that had no home in the files above when this skill was converted to a router: read references/business-supplementary.md.
Cross-References
- figma-design-tool-workflows — Figma-specific handoff and dev mode workflows
- ux-metrics-measurement — Metrics frameworks for case study results sections
- design-systems-architecture — Design system documentation patterns
- ux-research-methods — Research methodology details for proposals and case studies
- design-process-methods — End-to-end process for methodology sections
- sector-style-intelligence — Industry-specific context for proposals and case studies
- conversion-optimization-patterns — Data for value-based pricing and case study metrics
- micro-copy-intelligence — UX writing for documentation and component specs