MVD Ticket Templates

🔍 Phase 1: Discovery

🔍 Phase 1: Discovery

🎨 Component Discovery Ticket – [Component Name]

Type: Discovery Stage: Definition / Visual Exploration Component: [Component Name]

---

🎯 Goal

Explore and define the structure, properties, accessibility, and styling for the [Component Name] component.

This discovery ticket ensures:

• Consistency across the Universal Design System (UDS)

• Foundation for scalable, accessible components

• Alignment on naming, tokens, and structure before iteration

---

🧰 Activities

🔎 Reference Collection & Analysis

• Collect 3+ examples of the component from design systems or live products

  • Include at least 1 from shadcn/ui

  • Others may include: Material, Carbon, Primer, HIG, or trusted live apps

• Annotate with insights:

  • Component structure (container, trigger, content)

  • Interaction patterns (animation, collapse logic)

  • ARIA roles and accessibility best practices

---

⚙️ Property & Variable Planning

• Review [UDS Component Properties Documentation]

• Identify and align on:

  • Component property names (e.g., is-expanded, size, icon)

  • States and variants required (e.g., default, hover, disabled, etc.)

Define Tokens/Variables:

• Color & appearance:

  • surface, content, border

  • status variables for states (focus, active, etc.)

• Layout:

  • padding, gap, border-radius, border-width

• Note any collection dependencies (e.g., cta, grey, alert, etc.)

---

🧱 Component Structure

• List nested or dependent components:

  • e.g. AccordionTrigger, AccordionContent, IconWrapper

• Define:

  • Expansion logic (multi-open or single-open behavior)

  • Default open/closed state

  • Expected interaction flow

---

♿ Accessibility

• Plan for keyboard and assistive tech interaction:

  • Tab and arrow navigation

  • aria-expanded, aria-controls, roles

• Define focus ring treatment and test contrast in light/dark modes

---

📎 Output Expectations

• Figma or FigJam reference board with:

  • Examples + annotations

  • Visual dissection of structure and logic

• Summary of insights and early decisions

• List of scoped properties and variants

• Accessibility notes or gaps

• (Optional) Wireframe or schematic for structure

• Token usage table by category

• Risks, challenges, or deviations from existing systems

---

📚 Resources

🔗 Design System References

• ShadCN UI – Accordion

• Material – Accordion

• Carbon – Accordion

• Primer – Expandables

• Apple HIG – Disclosure Controls

🔗 Accessibility

• WAI-ARIA – Accordion Pattern

• Deque University – Accordion Accessibility

• Accessible Components – Hidde de Vries

---

👥 Assignees

• Designer: @[Name or Handle]

• Reviewer (Lead or PO): @[Name or Handle]

---

💡 Phase 2: Ideation & Iteration

💡 Phase 2: Ideation & Iteration Issue Template

💡 Phase 2: Ideation & Iteration – Component Concept Ticket Type: Exploration / Early Design Stage: Ideation & Experimentation Component Name:

---

🎯 Goal

Explore and experiment with visual direction, structure, and variations for <Component Name>. This phase supports creative iteration while aligning with system conventions.

This ticket should:

• Encourage rapid concept development

• Identify potential variants and flexibility

• Ensure early alignment with tokens, naming, and accessibility patterns

---

🧪 Activities

• Rough mockups of structural layouts and visual styles

• Explore possible variants:

  • States, sizes, and other identified variants from Discovery

  • Optional properties (e.g. icons, labels, badges, descriptions)

• Conduct async feedback loop:

  • Share mocks with design team for early feedback

  • Log decisions and rationale in ticket comments or shared doc

• Align structure with Universal Design System conventions:

  • Variable use: padding, gap, radius, content, status

  • Layout: consistent use of auto layout, hugging behavior, nesting

  • Token readiness: Use proper semantic and style variables

---

📦 Exploration Output Checklist

• Mocks are organized and labeled in Figma

• Key variations are annotated with rationale

• Decisions regarding structure, properties, or UX trade-offs are documented

• Any accessibility concerns or visual challenges are noted

• Design system naming conventions applied to layers and variants

---

🔁 Progression Readiness

If exploration is approved:

• Promote to a "🆕 New Component – Minimum Level Design Ticket"

• Transfer mockups and notes

• Flag any known edge cases or deviations for follow-up in the next phase

---

📎 Resources

• 🔗 Component Properties Documentation

• 🔗 UDS Tokens + Variables Overview

• 🔗 ShadCN / Material / Carbon / HIG References

---

👥 Assignees

• Designer: @

• Reviewer : @

---

🧱 Phase 3: Design

-

🧱 Phase 3: Design Issue Template

🎨 Phase 3: Design – Minimum Level Type: Design Stage: Polish & Structure Finalization Component Name:

---

🎯 Goal

Refine the component structure, styling, and variables from Ideation to align with the Universal Design System’s standards. Capture rationale and decisions to support the upcoming Prototyping and Documentation phases.

---

🧰 Activities

🎯 Refine Visual Design

• Finalize layout structure and alignment

• Polish spacing, padding, corner radius, borders

• Confirm proper use of iconography, type styles, and visual hierarchy

📐 Variable Integration

• Apply correct variables for:

  • Padding / spacing

  • Border radius / border width

  • Text styles / font size / weight

  • Colors (semantic, status, content, surface, border)

🔧 Component Setup & Structure

• Use Auto Layout for all containers

• Check layer naming and nesting logic

• Verify Hug / Fill behavior is appropriate for intended usage

• Breakpoint logic is defined (if relevant)

🧠 Capture Design Decisions

• Log reasoning behind chosen layout, visual treatments, or variant exclusions

• Flag any unresolved decisions, constraints, or deviations

• Include known accessibility considerations or trade-offs (e.g. touch targets, contrast risks)

---

✅ Definition of Done (DoD: Design – Minimum)

• Component follows system layout and structural conventions

• All spacings, sizes, and styles use approved Figma variables

• Finalized component variants reflect intended usage

• Layers are clean, logically grouped, and nested correctly

• Edge cases and variant behavior have been considered

• Rationale and decisions logged on Figma page

• Ready for prototyping and documentation next steps

---

📎 Output Expectations

• Updated Figma component in working file

• Notes added in Figma for rational

• Screenshot or short Loom (optional) capturing design intent

---

👥 Assignees

• Designer: @

• Reviewer: @

---

⚙️ Phase 4: Prototyping (Baseline Only)

⚙️ Phase 4: Prototyping (Baseline Only) Issue Template

🧪 Minimum-Level Prototyping Ticket – [Component Name]

Type: Prototyping Level: Minimum Component: [Insert Component Name] Stage: Prototyping (Base Interactions Only)

---

🎯 Goal

Set up base-level functional interactions for the component using Figma’s native prototyping tools. This phase does not include animations, micro-interactions, or high-fidelity flows. Focus is on state transitions only (e.g., default → hover → active → disabled → focus).

---

✅ Definition of Done (Minimum – Prototyping)

• All relevant interaction states are connected using Figma Prototype tab:

  • Hover → While hovering

  • Focus → While focused (keyboard tab simulation) Key press: Tab

  • Active (mouse/touch) → On click or On tap

  • Active (keyboard) → Key press: Enter

  • Return to Default → After delay or Key press: Tab

  • Disabled → No interactivity; use is-disabled: true toggle

• Component prototype is structured using frame-to-frame transitions with no animation settings (no smart animate, bounces, dissolves, etc.)

• Starting point is clearly defined for preview/testing

• All interactive hotspots are tied to the appropriate destination frames

• Prototype accurately reflects logical interaction flow, even if simplified

• Prototype has been tested with Tab, Enter, and hover actions

• Reviewer can tab through component states to simulate real keyboard interaction

---

📎 Additional Notes

• No motion or micro-interactions are required at this stage.

• This is not a final handoff. The goal is to validate functionality and ensure state logic works as expected.

• Interaction structure should reflect real product behavior where possible, even in basic form.

---

👥 Assignees

• Designer: @

• Prototype Reviewer: @

---

🔄 Phase 5: Review + Iteration

🔄 Phase 5: Review + Iteration Issue Template

✅ Minimum-Level Review & Iteration Ticket – [Component Name]

Type: Review & Iteration Level: Minimum Component: [Insert Component Name] Stage: Final Design QA before Documentation

---

🎯 Goal

Conduct a thorough design review of the component created during the Minimum design and prototyping phases. Address any necessary refinements, log future improvements, and ensure readiness for documentation and system integration.

---

🔍 Review Criteria Checklist

🔧 Structure & Layout

• Uses Auto Layout appropriately (no manual padding or alignment)

• Consistent hugging/fixed layout behavior

• Nesting follows UDS best practices

• Padding, gap, and radius values are linked to number variables

🎨 Visual & Token Consistency

• Uses semantic color and type variables

• Surface, content, and border tokens are applied correctly

• Status tokens used for interaction states (e.g. hover, focus, active)

• Spacing and sizing follow system scale

🧩 Component Logic

• States and variants are implemented via component properties

• Boolean and num props behave as expected

• Variants reflect the correct state logic and follow naming conventions

• Color props function as designed (if applicable)

• Size props function as designed (if applicable)

♿ Accessibility

• Minimum contrast AA met (recommend Contrast plug-in)

• Touch targets ≥ 44px

• Semantic roles identified or noted for dev (labels, regions, buttons, etc.)

• Focus ring exists and is visible in dark/light mode

🧪 Prototype & Interaction

• Hover, focus, active, and disabled interactions function logically

• Tab and keyboard nav mimic real behavior (e.g., tab for focus, enter for select)

• No animation or micro-interactions present at this level

---

📌 Iteration Notes

List any adjustments made during review:

- Padding reduced from 24 → 16px to match token scale
- Nested icon component updated to use `icon/circle/check`
- Hover color updated to match `status/hover/base`

---

📘 Future Improvements / Notes for Next Level

- Add microinteraction animation for active → success state
- Consider size-sm variant for mobile patterns
- Explore icon alignment override support

---

👥 Assignees

• Designer: @

• Reviewer (Lead): @

---

📝 Phase 6: Documentation

📝 Component Documentation Issue Template

📝 Component Documentation Issue Template

Type: Documentation Level: Minimum Component Name:

---

✨ Goal

Document the <Component Name> at the Minimum Level, embedded directly within the Figma component configuration panel. This ensures consistent, accessible guidance and sets the foundation for progressing to more advanced documentation levels.

---

✅ Definition of Done: Minimum Level Documentation

The following sections must be completed directly in Figma’s component configuration panel:

---

📘 Overview

• 📘 Overview

  • Describe what the component is and its purpose in the system

  • Include key use cases and how it supports scalable, accessible design

---

📚 Usage Guidelines

• 📚 Usage Guidelines

  • Provide instructions for using the component correctly in designs and handoff

  • Clarify where and when to use this component (e.g., not suitable as a button)

  • Mention expected patterns (e.g., spacing, outlined vs filled usage)

  • Call out considerations for responsiveness, accessibility, or variants

---

♿ Accessibility Considerations

• ♿ Accessibility Considerations

  • Confirm contrast compliance (use Figma Contrast plugin)

  • Mention semantic tags (e.g., utility-semantic-tag) if applicable

  • Include expectations for keyboard navigation, focus, and screen reader behavior

---

⚙️ Component Properties

• ⚙️ Component Properties

  • List all interactive or visual properties clearly

  • Confirm naming aligns with Component Properties documentation

Document all configurable properties using this format:

<property-name> (<type>):

* Purpose: What this property controls
* Usage: How it should be used or when to toggle it
* Context: (Optional) Any design/system constraints

📌 Example:

size (Select):

* Purpose: Adjusts the size of the tag
* Usage:

  * sm – for dense UI or compact elements
  * base – default size for most contexts
  * lg – for emphasis or large display areas

---

🔀 Appearance Layer Modes & Variations

• 🔀 Appearance Layer Modes & Variations This component supports dynamic styling through Figma’s Appearance panel, which allows toggling between variable collections (e.g., theme, status, device).

✅ Supported Variable Collections

• List all supported variable collections used by this component

📌 Example:

* theme: light, dark
* status: default, hover, focus, active, disabled
* device: desktop, tablet, mobile

✅ Behavior When Modes Are Applied

• Ensure tokens (surface, content, border, spacing) adapt correctly

• Describe layout, visibility, or interaction changes

• Confirm all supported modes are previewed and validated

📌 Example:

Responsive Text Size

* What changes: Font size adjusts based on `device` mode using responsive tokens
* To test:

  1. Place the component inside a responsive parent frame
  2. Toggle `device` mode in the Appearance panel
  3. Confirm font size and spacing adapt as expected

ℹ️ Note any unsupported collections or edge cases

---

🧱 Nested Components

• 🧱 Nested Components

  • List and describe all nested or reusable subcomponents

  • Clarify their function, interaction (if any), and visibility rules

📌 Example:

* TagIcon: Displays a leading icon
* CancelButton: Affordance to dismiss the tag
* LabelText: Tokenized text element

---

📝 Additional Notes

• 📝 Additional Notes

  • Provide usage tips across screen sizes or layouts

  • Mention related component families

  • Warn about common usage mistakes or confusion

---

🧠 Developer Notes

• 🧠 Developer Notes

If no developer notes: No current notes.

• Include logic expectations, prop notes, or code mapping

• Mention if this maps to a frontend component (e.g., <Tag />)

• Document known quirks or implementation constraints

---

🐛 Known Issues

• 🐛 Known Issues

If no known issues: No known issues.

• Document limitations, bugs, or incomplete functionality

• Include open questions or gaps

---

Reference Links

If no reference links: No current reference links.

---

📎 Additional Info & Resources

• Minimum documentation must be written within the Figma configuration panel

• This documentation is a prerequisite for advancing to Production or Lovable levels

---

👥 Assignees

• Primary Owner: @

• Reviewer: @

---

📋 To Copy – Example Template Format for Figma Panel

<Component Name>

Overview: <Brief summary of what this component is and its purpose in the system.>

---

Usage Guidelines:
\<Explain when, where, and how this component should be used.
Clarify any restrictions or best practices (e.g., not for navigation, only used in filters, etc.).>

---

Component Properties:

<property-name> (<type>):
Purpose: <What this property controls>
Usage: <How to use or when to toggle this property>
Context: \<Optional – design system constraints or special behavior>

<Repeat for each property>

---

Appearance Modes:
Supports the following variable collections:

**theme:** <Describe how the component adapts visually or functionally between light and dark mode.>

**status:**
\<Describe how the component changes across interaction states (e.g., hover, focus, active, disabled).>

**device:**
\<Describe how the component responds to different device contexts (e.g., layout changes for desktop, tablet, mobile).>

> ℹ️ Note any unsupported collections or edge cases

---

Nested Components:

* <Subcomponent Name>: <Purpose and when it appears>
* <Subcomponent Name>: <Purpose and when it appears>

---

♿ Accessibility Considerations:

* Contrast: Meets WCAG AA in all supported modes
* Keyboard navigation: \<Describe expected focus/tab order>
* Screen reader support: \<ARIA roles or live regions, if any>
* Semantic tags: \<e.g., utility-semantic-tag for structure/meaning>

---

🧠 Developer Notes:
\<Add implementation notes or component mappings (e.g., maps to `<Tag />`).>

If no developer notes:
**No current notes.**

---

Known Issues:
\<List bugs, limitations, or open UX gaps.>

If no known issues:
**No known issues.**

---

Reference Links:

* <Link to design spec, storybook, or dev handoff doc>  
* <Link to external references or accessibility specs>