Professional design business templates covering proposals, case studies, pitch decks, design documentation, client handoffs, pricing calculators, project briefs, and design system documentation. Use when the user mentions: proposal, case study, pitch deck, design presentation, client handoff, design documentation, project brief, design specs, style guide, design deliverable, pricing calculator, invoice, SOW, scope of work, design portfolio, client report, design brief.
Installation
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Professional design business templates covering proposals, case studies, pitch decks, design documentation, client handoffs, pricing calculators, project briefs, and design system documentation. Use when the user mentions: proposal, case study, pitch deck, design presentation, client handoff, design documentation, project brief, design specs, style guide, design deliverable, pricing calculator, invoice, SOW, scope of work, design portfolio, client report, design brief.
Business Design Templates — The Business Side of Design
A comprehensive reference for every document a design professional creates outside of the design tool itself: proposals that win work, case studies that prove value, pitch decks that sell ideas, documentation that survives handoff, and contracts that protect both parties.
1. Proposal Structure (Detailed)
A winning proposal is a mirror: the client should see their own problem reflected back, then a clear path forward. Target length: 6-12 pages depending on project size.
1.1 Executive Summary (1 page max)
Write this last, even though it appears first. Summarize the problem, your approach, the expected outcome, and the investment in 3-4 paragraphs.
Template:
[Client Name] is experiencing [specific problem] that impacts [business metric]. Through [your methodology], we will deliver [key deliverables] over [timeline], resulting in [expected outcome]. The total investment is [price range or fixed price].
Our team brings [relevant credential] and has delivered similar results for [comparable client or industry]. We are prepared to begin [start date] and look forward to partnering with [Client Name] on this initiative.
Tips:
Lead with the client's problem, not your capabilities
Include one quantified outcome if possible ("reduce checkout abandonment by 15-25%")
Name the investment upfront — hiding it signals insecurity
Keep to 150-250 words
1.2 Problem Understanding
Demonstrate you listened during discovery. Restate the problem using the client's own language and frame it in terms of business impact.
Template:
Current State: [Description of what exists today — the product, the workflow, the pain point]
Impact: [How the problem affects users, revenue, operations, or brand perception. Use any data the client shared.]
Root Causes: [Your initial hypothesis about why the problem exists — outdated IA, inconsistent patterns, lack of user research, technical debt in the UI layer]
Opportunity: [What becomes possible if the problem is solved — market expansion, reduced support costs, improved NPS]
Tips:
Quote the client directly if they said something powerful in the discovery call
Reference specific metrics they shared ("your current checkout completion rate of 62%")
Show you understand their competitive landscape
Identify 2-3 root causes to demonstrate diagnostic thinking
1.3 Approach and Methodology
Explain how you work, not just what you deliver. Clients buy process confidence.
Template:
Phase 1: Research and Discovery (Weeks 1-2)
Stakeholder interviews (3-5 sessions)
Competitive audit (5-8 competitors)
User research: [method] with [number] participants
Deliverable: Research synthesis report
Phase 2: Strategy and Information Architecture (Weeks 3-4)
User flows and journey mapping
IA restructuring and card sort validation
Content strategy alignment
Deliverable: IA documentation and validated user flows
Phase 3: Design Exploration (Weeks 5-8)
Wireframes for [number] key screens
2-3 visual direction explorations
Design system foundation (tokens, core components)
Deliverable: Wireframe deck, visual direction options
Phase 4: Detailed Design and Prototyping (Weeks 9-12)
Build in 1-week buffer between phases for client review
Specify that timeline assumes feedback within 3 business days
Note that timeline extends day-for-day if feedback is delayed
Include holidays and known blackout dates
1.6 Team and Expertise
Template:
[Your Name], Lead Designer — [X] years of experience in [specialization]. Previously designed for [notable clients or products]. Specializes in [specific skill relevant to this project].
[Team Member], UX Researcher — [Background]. Will lead user interviews and usability testing.
Relevant Experience:
[Project A]: [One-sentence result with metric]
[Project B]: [One-sentence result with metric]
[Project C]: [One-sentence result with metric]
1.7 Investment and Pricing Tiers
Three-tier structure (anchoring strategy):
Essential
Recommended
Premium
Research
Competitive audit only
Audit + 5 interviews
Audit + 10 interviews + diary study
Design
20 screens, 1 direction
35 screens, 2 directions
50+ screens, 3 directions
Prototype
Click-through
Interactive (2 flows)
Interactive (all flows) + motion
Testing
Heuristic review
5-participant usability test
Test + iterate + retest
Support
Handoff docs
Handoff + 1 sprint QA
Handoff + 3 sprint QA
Investment
$XX,000
$XX,000
$XX,000
Tips:
The middle tier should be your target — price it at the project's true value
Essential tier removes scope, not quality
Premium tier adds research depth and extended support
Always present three options: it shifts the question from "should we hire you?" to "which package?"
1.8 Terms and Next Steps
Template:
To proceed: Sign this proposal and return with the 30% deposit by [date]. We will schedule the kickoff within 5 business days of receiving both.
Payment terms: Net 15 on all invoices. 30% at signing, 30% at wireframe approval, 30% at design completion, 10% at handoff.
Revisions: Each phase includes 2 rounds of revisions. Additional rounds billed at [hourly rate]/hour.
This proposal is valid for 30 days from [date].
2. Case Study Structure (Challenge, Process, Solution, Results)
Case studies are your most powerful sales tool. They prove you have done the work, not just that you can talk about it.
2.1 Universal Structure
Header block:
Client name (or "Confidential — [Industry] Client")
Your role and team size
Duration
Key metric outcome (the hero number)
Sections:
Client Context — Who they are, their market, their scale. 2-3 sentences.
The Challenge — The problem in human terms. What was broken, what was the cost. Include a direct quote from the client if possible.
Process and Key Decisions — Your methodology. Show the messy middle: research that changed your assumptions, design explorations that failed, the pivotal decision that shaped the solution.
The Solution — Final designs with context. Annotate key decisions. Show before/after if possible.
Client Testimonial — A direct quote. Get this before the project ends while satisfaction is high.
2.2 Industry-Specific Examples
Example 1: SaaS / B2B Platform
Client: Midsize project management SaaS (150K MAU)
Challenge: Onboarding completion had dropped to 34%. New users churned within 7 days because the setup wizard required 23 steps across 4 screens with no progress indication.
Process: Conducted 12 user interviews revealing that users abandoned at the team invitation step (step 14). Ran a card sort to restructure the flow. Prototyped 3 variations and tested with 8 participants.
Solution: Reduced onboarding to 3 progressive screens with smart defaults. Added "skip for now" to non-critical steps. Introduced a contextual checklist that persists in the dashboard.
Results: Onboarding completion rose to 71% (+109%). 7-day retention improved by 23%. Support tickets related to setup dropped 58%.
Example 2: E-Commerce / DTC
Client: Premium skincare DTC brand ($8M annual revenue)
Challenge: Mobile conversion rate was 1.2% vs. industry average of 2.4%. Cart abandonment at 78%. Product pages had excessive scroll depth with no clear CTA hierarchy.
Process: Heatmap analysis + 6 moderated mobile usability sessions. Discovered users could not find shade/size selectors. Ran A/B test on 3 PDP layouts.
Solution: Redesigned PDP with sticky add-to-cart bar, above-fold variant selector, and compressed social proof into a trust strip. Simplified checkout to 2 steps.
Results: Mobile conversion rose to 2.8% (+133%). Cart abandonment dropped to 61%. Average order value increased 12% via cross-sell module.
Example 3: Healthcare / Patient Portal
Client: Regional hospital network (3 facilities, 200K patients)
Challenge: Only 18% of patients used the portal for appointment scheduling. 72% called the front desk instead, creating 45-minute average hold times.
Process: Contextual inquiry at 2 clinic locations. Observed patients attempting to use the portal on their phones in waiting rooms. Accessibility audit revealed WCAG failures on every key flow. Personas and journey maps for 3 patient archetypes.
Solution: Rebuilt scheduling flow for mobile-first with WCAG 2.2 AA compliance. Added biometric login, natural language appointment search ("I need to see my cardiologist next Tuesday"), and SMS confirmation.
Results: Portal scheduling adoption reached 52% within 6 months. Call volume dropped 35%. Patient satisfaction (CSAT) improved from 3.2 to 4.4/5.
Example 4: Fintech / Banking
Client: Digital bank targeting freelancers (40K accounts)
Challenge: Invoice payment feature had 8% adoption despite being the primary differentiator. Users did not understand how it connected to their balance.
Process: Jobs-to-be-done interviews with 15 freelancers. Competitive analysis of 6 invoicing tools. Discovered users wanted invoicing inside their money context, not as a separate tool.
Solution: Integrated invoicing into the transaction feed. Sent invoices become pending income. Payments auto-reconcile. Added "get paid faster" nudges with fee transparency.
Results: Invoice feature adoption rose to 41%. Average revenue per user increased 28%. NPS jumped from 32 to 61.
Example 5: Education / EdTech
Client: Online learning platform for professional certificates (500K learners)
Challenge: Course completion rate was 12%. Learners dropped off after module 3 of 8-module courses. Mobile usage was 65% but the experience was desktop-adapted, not mobile-native.
Process: Learning analytics review + 10 learner interviews. Found that session length expectations (45 min) conflicted with actual mobile session patterns (8-12 min). Co-design workshop with instructional designers.
Solution: Restructured courses into 10-minute micro-lessons. Added offline mode, progress streaks, and spaced repetition review. Redesigned video player for vertical mobile consumption.
Results: Course completion rose to 34% (+183%). Daily active learners increased 67%. Mobile session frequency doubled. Certificate attainment rate improved 2.4x.
2.3 Case Study Writing Tips
Lead with the result in the headline: "How we increased checkout conversion 133% for [Client]"
Show your process artifacts: photos of whiteboard sessions, screenshot of Figma exploration, research synthesis boards
Include at least one moment where you changed direction based on evidence
Keep each case study to 600-1000 words for portfolio use; expand for blog/long-form
Always get written permission before publishing
3. Pitch Deck Structure (8-12 Slides)
The pitch deck sells a design direction to stakeholders. It is not a Figma walkthrough — it is a narrative.
Slide 1: Title
Project name
Date
Your name/agency
Client logo (if appropriate)
Tip: Set the tone visually. This slide signals the quality of everything that follows.
Slide 2: Context and Problem
Business context in 2-3 bullet points
The problem stated clearly and concisely
Key metric that quantifies the problem ("42% of users abandon the flow at step 3")
Tip: Use the client's own words. Quote from a stakeholder interview if possible.
Slide 3: Research Findings
3-5 key insights from research (not a data dump)
One compelling user quote
One data visualization (chart, heatmap screenshot, or metric callout)
Tip: Insights should directly connect to design decisions you will present later. Every insight earns its slide by justifying a choice.
Slide 4: User Understanding
Key persona or user archetype (1-2, not 5)
Journey map highlighting the pain point
Jobs-to-be-done framing
Tip: Make the user feel real. Name, photo, quote, context of use.
Slide 5: Design Principles
3-4 principles derived from research that guided your design
Example: "Progressive disclosure over upfront complexity"
Example: "Confidence through transparency (show the user what happens next)"
Tip: Principles create shared vocabulary for the feedback conversation.
Slide 6: Design Exploration
Show 2-3 directions you explored (thumbnails, not full screens)
Briefly explain the thesis behind each
Indicate which direction you recommend and why
Tip: Showing exploration proves rigor. It also prevents "what if we tried..." derailments.
Slide 7-9: Recommended Solution (Hero Mockups)
Full-screen mockups of key screens (3-5 screens maximum)
Annotate each screen with 2-3 callouts connecting back to research insights or principles
Show the primary user flow as a sequence
Tip: Present screens in user-flow order, not in order of visual impressiveness.
Slide 10: Prototype Demo
Live prototype walkthrough (Figma prototype, not static screens)
Script the walkthrough: narrate the user scenario, not the UI elements
Tip: Say "The freelancer opens the app to check if their invoice was paid" not "The user taps the hamburger menu and selects Invoices."
Slide 11: Implementation Plan
Phased rollout if applicable
Technical considerations
What engineering needs from design (specs, tokens, assets)
Timeline for design support during development
Tip: This slide builds trust with engineering stakeholders in the room.
Slide 12: Next Steps
Clear ask: "We need approval on direction B to proceed to detailed design"
Timeline for next milestone
Open questions that need stakeholder input
Tip: End with a decision request, not a whimper. "Any questions?" is not a closing slide.
Presentation Delivery Tips
Rehearse timing: 20 minutes max for the deck, then open discussion
Present to one person (the decision-maker), even in a group
Pause after showing each key screen — let it breathe
When receiving feedback, write it down visibly (shared doc or whiteboard)
Separate "I like / I wish / What if" feedback from "this is a blocker" decisions
4. Design Documentation Templates
4.1 Component Specification
## Component: [Name] (e.g., Button — Primary)
### Visual States
| State | Background | Text | Border | Shadow | Opacity |
|---|---|---|---|---|---|
| Default | blue-600 | white | none | sm | 1 |
| Hover | blue-700 | white | none | md | 1 |
| Active/Pressed | blue-800 | white | none | none | 1 |
| Focus | blue-600 | white | 2px blue-300 | sm | 1 |
| Disabled | gray-200 | gray-400 | none | none | 0.6 |
| Loading | blue-600 | — | none | sm | 1 |
### Spacing
- Padding: 12px 24px (md), 8px 16px (sm), 16px 32px (lg)
- Min-width: 120px
- Gap between icon and label: 8px
- Margin between stacked buttons: 12px
### Typography
- Font: Inter Semibold
- Size: 14px (md), 12px (sm), 16px (lg)
- Line-height: 20px (md)
- Letter-spacing: 0.01em
### Interaction
- Hover transition: background-color 150ms ease-out
- Press scale: transform scale(0.98) 100ms
- Focus ring: 2px offset, 2px width, blue-300
- Loading: replace label with spinner (16px), maintain button width
- Ripple: none (not Material)
### Accessibility (ARIA)
- Role: button
- aria-label: required if icon-only
- aria-disabled: true (not HTML disabled, to maintain focusability)
- aria-busy: true when loading
- Minimum touch target: 44x44px
- Color contrast: 4.5:1 minimum (text on background)
- Focus order: follows DOM order
4.2 Interaction Specification
## Interaction: [Name] (e.g., Modal Open/Close)
### Trigger
- User clicks "Delete Account" button
- Keyboard: Enter or Space on focused trigger
### Entry Animation
- Backdrop: opacity 0 → 0.5, 200ms ease-out
- Modal: opacity 0 → 1, transform translateY(16px) → translateY(0), 250ms ease-out
- Stagger: backdrop starts first, modal starts at 100ms
### Exit Animation
- Modal: opacity 1 → 0, transform translateY(0) → translateY(8px), 150ms ease-in
- Backdrop: opacity 0.5 → 0, 200ms ease-in, starts at 50ms
- Total exit duration: 200ms
### Focus Management
- On open: focus moves to the first focusable element (Cancel button)
- Focus is trapped within modal (Tab cycles through modal controls)
- On close: focus returns to the trigger element
### Edge Cases
- If trigger element is removed while modal is open: focus returns to document body
- If modal content overflows: scroll within modal body, header/footer fixed
- Rapid open/close: debounce at 300ms, cancel pending animation
- Escape key: closes modal (same as Cancel)
- Backdrop click: closes modal (same as Cancel)
- Mobile: modal becomes full-screen sheet at <640px breakpoint
4.3 Design Decision Record (DDR)
## DDR-[Number]: [Decision Title]
**Date:** [Date]
**Status:** Accepted | Superseded | Deprecated
**Deciders:** [Names and roles]
### Context
[What is the situation that requires a decision? What constraints exist?]
### Decision
[What was decided, stated clearly in one sentence.]
### Options Considered
**Option A: [Name]**
- Description: [How it works]
- Pros: [Benefits]
- Cons: [Drawbacks]
- Effort: [Low/Medium/High]
**Option B: [Name]**
- Description: [How it works]
- Pros: [Benefits]
- Cons: [Drawbacks]
- Effort: [Low/Medium/High]
**Option C: [Name]**
- Description: [How it works]
- Pros: [Benefits]
- Cons: [Drawbacks]
- Effort: [Low/Medium/High]
### Rationale
[Why Option [X] was chosen. Reference user research, technical constraints,
business requirements, or design principles that informed the decision.]
### Consequences
- [What this decision enables]
- [What this decision prevents or makes harder]
- [What must be true for this decision to succeed]
### Related
- DDR-[XX]: [Related decision]
- Research finding: [Reference]
Consistent naming convention applied to all layers and frames
Components use auto-layout (not fixed positioning)
All text uses text styles (no overrides without documentation)
All colors use color styles or variables
Prototype flows connected and labeled
Version history has meaningful descriptions
Dev mode enabled with annotations
6. Pricing Models for Design Work
6.1 Project-Based (Fixed Price)
When to use: Well-defined scope, clear deliverables, client wants budget certainty.
Formula: (Estimated hours x hourly rate) x 1.2 (buffer) + expenses
Pros: Predictable for client, rewards efficiency, easier to sell.
Cons: Scope creep risk, penalizes thoroughness, requires accurate estimation.
Tips:
Always define what is out of scope
Include a revision limit (2 rounds per phase)
Add a change order process for scope additions
Price based on value delivered, not just hours
6.2 Retainer (Monthly)
When to use: Ongoing relationship, variable needs, client wants priority access.
Structure: [X] hours/month at [rate]. Unused hours do not roll over. Overage billed at 1.25x rate.
Pros: Predictable income, deeper client relationship, less sales overhead.
Cons: Can feel like employment, scope ambiguity, client may underutilize.
Tips:
Set a minimum commitment (3 months)
Define response time SLAs (e.g., 24-hour turnaround on reviews)
Provide monthly utilization reports
Review and adjust quarterly
6.3 Value-Based
When to use: You can tie design work to measurable business outcomes. Best for conversion optimization, revenue-impacting features, or established client relationships.
Formula: Price = (Projected annual impact x probability of success x 10-20%)
Example: If redesigning checkout is projected to increase revenue by $500K/year with 60% confidence, price = $500K x 0.6 x 0.15 = $45,000.
Pros: Highest earning potential, aligns incentives, positions you as a partner.
Cons: Requires business acumen, harder to justify without track record, client must share data.
Tips:
Establish baseline metrics before starting
Define measurement methodology upfront
Include a performance bonus clause tied to exceeding targets
Requires trust and transparency from both parties
6.4 Hourly
When to use: Ambiguous scope, consulting/advisory work, small tasks, design QA.
Example: $150K target / 48 / 25 = $125/hr x 1.3 = $162/hr (round to $165)
Pros: Fair for ambiguous scope, low risk, transparent.
Cons: Penalizes efficiency, creates adversarial dynamic ("that took too long"), income ceiling.
Tips:
Track and share time transparently (Toggl, Harvest)
Set weekly hour caps so clients are not surprised
Bill in 30-minute increments minimum
Never discount your rate — add scope instead
6.5 Rate Benchmarks (USD, 2025-2026)
Level
Hourly
Day Rate
Monthly Retainer
Junior (0-2 yrs)
$50-80
$400-640
$4,000-8,000
Mid (3-5 yrs)
$80-150
$640-1,200
$8,000-16,000
Senior (6-10 yrs)
$150-250
$1,200-2,000
$16,000-30,000
Lead/Principal (10+ yrs)
$250-400
$2,000-3,200
$30,000-50,000
Agency/Studio
$150-350
$1,200-2,800
$15,000-50,000
7. SOW (Scope of Work) Template
SCOPE OF WORK
Project: [Project Name]
Client: [Client Name]
Designer: [Your Name / Studio]
Date: [Date]
Version: [1.0]
1. PROJECT OVERVIEW
[2-3 sentences describing the project, its goals, and expected outcome.]
2. DELIVERABLES
2.1 [Deliverable name] — [Description, format, quantity]
2.2 [Deliverable name] — [Description, format, quantity]
2.3 [Deliverable name] — [Description, format, quantity]
3. TIMELINE
Phase 1: [Name] — [Start] to [End]
Phase 2: [Name] — [Start] to [End]
Phase 3: [Name] — [Start] to [End]
Final delivery: [Date]
4. REVISION POLICY
Each deliverable includes [2] rounds of revisions.
A revision round is defined as a single consolidated set of feedback.
Additional rounds billed at [rate]/hour.
Feedback must be provided within [5] business days or the
timeline extends accordingly.
5. OUT OF SCOPE
The following are explicitly not included:
- [Item 1, e.g., front-end development]
- [Item 2, e.g., copywriting]
- [Item 3, e.g., photography/video production]
Any out-of-scope work requested will require a change order.
6. PAYMENT TERMS
Total project fee: $[Amount]
- [30]% deposit due at signing: $[Amount]
- [30]% at [milestone]: $[Amount]
- [30]% at [milestone]: $[Amount]
- [10]% at final delivery: $[Amount]
Payment due within [15] days of invoice.
Late payments incur [1.5]% monthly interest.
7. INTELLECTUAL PROPERTY
Upon receipt of final payment, all deliverables and associated
IP transfer to [Client Name]. Designer retains the right to
display the work in portfolio with client permission.
Work-in-progress, unused concepts, and underlying tools/templates
remain the property of [Designer].
8. CONFIDENTIALITY
Both parties agree to keep project details confidential until
public launch unless otherwise agreed in writing.
9. TERMINATION
Either party may terminate with [15] days written notice.
Client pays for all work completed through termination date.
Deposit is non-refundable after project kickoff.
10. SIGNATURES
Client: ______________________ Date: __________
Designer: ____________________ Date: __________
8. Design Review Presentation
Structure for Presenting Designs to Stakeholders
Before the meeting:
Send a 1-page preview 24 hours before (build anticipation, reduce surprise)
Identify the decision-maker and their primary concern
Prepare a prototype link for post-meeting exploration
Opening (2 minutes):
Restate the problem and success criteria
Remind the room of research insights that informed the direction
Walkthrough (15 minutes):
Present in user-flow order, not screen-by-screen
Narrate the user's journey: "Sarah opens the app on Monday morning to..."
Pause at each key screen for 10 seconds of silence (let it land)
Annotate decisions: "We chose tabs over a sidebar because research showed..."
Feedback collection (15 minutes):
Use structured feedback: "I like / I wish / What if"
Separate subjective preference from usability concern from business requirement
Write down every piece of feedback visibly
Ask "Is this a blocker or a consideration?" for each item
Do not defend or explain in the moment — absorb, then respond
Closing (3 minutes):
Summarize decisions made
List open items with owners and deadlines
State the next milestone and date
Handling Difficult Feedback
Feedback Type
Response Strategy
"I don't like the color"
"What feeling should it evoke? Let's align on intent."
"My spouse thinks..."
"I appreciate that perspective. Let's check it against our user research."
"Can we make it pop?"
"Can you show me an example of what 'pop' means to you?"
"The competitor does X"
"Yes — let's look at why. Our research suggests our users need Y."
"Just make it like Apple"
"Which aspect? Simplicity, animation, information density? Let's be specific."
"We need to add [feature]"
"Great idea. Let's capture it. Where does it rank against our current priorities?"
9. Project Brief Template
PROJECT BRIEF
Project Name: [Name]
Date: [Date]
Author: [Name]
Version: [1.0]
Status: Draft | Under Review | Approved
1. BACKGROUND
[Why does this project exist? What business event triggered it?
What has been tried before?]
2. GOALS
Primary: [The one thing this project must achieve]
Secondary: [2-3 additional goals]
Non-goals: [What this project is explicitly NOT trying to do]
3. TARGET AUDIENCE
Primary: [Who, demographics, psychographics, tech comfort]
Secondary: [Who else will use this?]
Excluded: [Who is this NOT for?]
4. CONSTRAINTS
Technical: [Platform, browser support, existing tech stack]
Brand: [Guidelines, voice, visual restrictions]
Legal/Regulatory: [Compliance requirements]
Budget: [Range]
Timeline: [Hard deadline and reason]
5. SUCCESS METRICS
| Metric | Current | Target | Measurement Method |
|---|---|---|---|
| [Metric 1] | [Baseline] | [Goal] | [Tool/method] |
| [Metric 2] | [Baseline] | [Goal] | [Tool/method] |
| [Metric 3] | [Baseline] | [Goal] | [Tool/method] |
6. REFERENCES AND INSPIRATION
- [URL or screenshot]: [What you like about it and why]
- [URL or screenshot]: [What you like about it and why]
- [URL or screenshot]: [What to avoid and why]
7. STAKEHOLDERS
| Name | Role | Decision Authority | Involvement |
|---|---|---|---|
| [Name] | [Title] | Final approver | Weekly review |
| [Name] | [Title] | Subject matter expert | As needed |
| [Name] | [Title] | Technical advisor | Sprint review |
8. APPROVAL
Approved by: ______________________ Date: __________
10. Invoice Template
INVOICE
Invoice #: [INV-2026-001]
Date: [Date]
Due Date: [Date + Net 15]
FROM:
[Your Name / Studio Name]
[Address]
[Email]
[Phone]
TO:
[Client Name]
[Client Company]
[Client Address]
PROJECT: [Project Name]
SOW Reference: [SOW-2026-001]
LINE ITEMS:
| # | Description | Quantity | Rate | Amount |
|---|---|---|---|---|
| 1 | Discovery and research phase | 1 | — | $X,XXX |
| 2 | Wireframes (20 screens) | 20 | $XXX | $X,XXX |
| 3 | High-fidelity design | 35 screens | $XXX | $X,XXX |
| 4 | Prototype (2 flows) | 2 | $X,XXX | $X,XXX |
| 5 | Usability testing | 1 session | — | $X,XXX |
| | | | SUBTOTAL | $XX,XXX |
| | | | Tax (if applicable) | $X,XXX |
| | | | **TOTAL DUE** | **$XX,XXX** |
PAYMENT TERMS:
- Due within 15 days of invoice date
- Late payment incurs 1.5% monthly interest (18% APR)
- Accepted methods: bank transfer (ACH), wire, check
- Bank details: [Routing] / [Account] or [Payment link]
NOTES:
This invoice covers [milestone name] per SOW [reference].
Next invoice ([milestone name]) estimated for [date].
Thank you for your business.
11. NDA and Contract Essentials for Designers
Mutual NDA (Key Clauses)
Definition of Confidential Information — Include: designs, research data, business strategy, user data, financial terms. Exclude: publicly available information, information known prior to engagement.
Duration — Typically 2-3 years for design work. Perpetual NDAs are a red flag.
Permitted Disclosure — Subcontractors (with their own NDA), legal requirements, employees who need to know.
Return/Destruction — Upon termination, return or destroy confidential materials within 30 days.
Portfolio Exception — Negotiate this upfront: "Designer may display final deliverables in portfolio after public launch, subject to Client approval."
Design Contract Essentials (Must-Have Clauses)
Scope of Work — Reference the SOW document. Include change order process.
Payment Terms — Amounts, schedule, method, late fees. Specify that work pauses if payment is 15+ days overdue.
Intellectual Property Transfer — IP transfers only upon full payment. Before that, designer retains all rights.
Revisions and Approvals — Number of rounds, definition of a "round," what happens after the limit.
Timeline and Delays — Client-caused delays extend timeline 1:1. Define "business days" for feedback windows.
Termination — Kill fee (typically 25-50% of remaining project value). Payment for all completed work.
Liability Cap — Limit liability to the total project fee. Never accept unlimited liability.
Indemnification — Client provides content/assets legally. You are not liable for client-supplied IP infringement.
Portfolio Rights — Right to display work in portfolio, on social media, and in case studies after launch.
Independent Contractor Status — You are not an employee. Specify tax responsibility.
Red Flags in Client Contracts
"Work made for hire" language (may void your portfolio rights)
IP transfer before final payment
Non-compete clauses (you cannot work for competitors)
Unlimited revisions
Perpetual NDA with no portfolio exception
Liability exceeding project fee
Vague scope with fixed price (scope creep trap)
Payment on "acceptance" with no defined acceptance criteria
12. Portfolio Case Study Format
Optimized for hiring managers (scanning in 30 seconds) and clients (evaluating capability).
Structure
Hero Section:
Project title
One-sentence summary (what you did + the result)
Hero image (best mockup, full-width)
Role, team size, duration, tools used
The Challenge (100-150 words):
Client context in one sentence
The specific problem
Why it mattered (business impact)
Constraints that made it interesting
The Process (200-300 words):
Research method and key insight (show an artifact: affinity map, journey map)
Design exploration (show iterations, not just the final)
The pivotal decision (what you changed your mind about and why)
