Capstone: Creating a Mini UI Kit and Stakeholder-Ready Prototype in Figma

This capstone is a guided build that combines your existing skills into two stakeholder-ready deliverables: (1) a mini UI kit you can reuse across screens, and (2) a clickable prototype that demonstrates a small, complete feature flow. The goal is not to design “everything,” but to prove you can build a consistent system and assemble screens quickly using instances, patterns, and predictable spacing.

Capstone deliverables (what you will ship)

Deliverable A: Mini UI kit

• Styles: color styles, text styles, effect styles (only what you actually use in the screens).
• Core components: buttons, inputs, top app bar, list item, avatar, icon button, toast/snackbar, modal sheet.
• Variants: at minimum for buttons and inputs (state + size), plus toggles/switches if used.
• Auto Layout patterns: reusable rows/stacks (e.g., “Form Field Row,” “Settings Row,” “Card,” “Section Header”).

Deliverable B: Stakeholder-ready prototype

• A small feature flow such as: Onboarding → Login → Home → Settings.
• Includes at least one overlay (e.g., “Forgot password” sheet, “Saved” toast, or confirmation modal).
• Includes at least one interactive state (e.g., button hover/pressed, input error, toggle on/off).

Build order (follow this sequence)

Use this order to avoid rework: structure → styles → components → patterns → screens → constraints → prototype → review → share.

1) Set up capstone pages and naming conventions

Create pages that separate system assets from screens so stakeholders and teammates can navigate quickly.

• 00 Cover & Summary (one frame that explains what’s included and how to click through)
• 01 UI Kit (styles + components + patterns)
• 02 Screens (final assembled screens only)
• 03 Prototype Playground (optional: experiments, discarded ideas)

Naming rule: choose a consistent prefix system so search works. Example:

Styles: Color/Primary/500, Text/Body/Regular, Effect/Shadow/Sm
Components: Button/Primary, Input/Text, Nav/TopBar
Patterns: Pattern/FormFieldRow, Pattern/SettingsRow
Screens: Screen/Onboarding-01, Screen/Login, Screen/Home, Screen/Settings

Quality gate: file hygiene check

• Pages are in the same order as the build order.
• Every frame/component has a clear, searchable name (no “Frame 12”).
• Only one “final” version of each screen lives on the Screens page.

2) Define the mini UI kit scope (keep it minimal)

Before building, list the smallest set of UI pieces needed for your chosen flow. This prevents you from overbuilding a design system.

Continue in our app.

• Listen to the audio with the screen off.
• Earn a certificate upon completion.
• Over 5000 courses for you to explore!

Or continue reading below...

Download the app

Quality gate: scope sanity check

• Every planned component appears on at least one screen.
• No component is “nice to have” unless it supports a prototype moment (overlay, state, navigation).

3) Create styles that match your screens (not a full palette)

Instead of building a huge style library, define only what you will use. Your UI kit should feel complete for this feature, not universal for every product.

• Color styles: Primary, Background, Surface, Text (primary/secondary), Border, Success/Error (if you show validation).
• Text styles: at least Heading, Body, Caption, Button label.
• Effect styles: one shadow for elevated surfaces (e.g., modal, card) if needed.

Quality gate: consistency check for styles

• All text layers on your screens use text styles (no one-off font sizes).
• All fills/strokes that represent the same meaning use the same color style.
• Effects (shadows) are reused via effect styles, not manually tweaked per card.

4) Build core components with variants (start with the “spine”)

Build components in the UI Kit page in the order that unlocks screen assembly fastest. Prioritize components that appear on multiple screens.

Recommended component build sequence

1. Button (Primary + Secondary; states like Default/Hover/Pressed/Disabled; sizes if needed)
2. Input (Default/Focus/Error/Disabled; with/without helper text; optional leading/trailing icon)
3. Top App Bar (title + optional back button + optional action icon)
4. List Item / Card (title + subtitle + optional icon + optional chevron)
5. Toggle / Switch (On/Off + Disabled if used)
6. Toast or Modal (for overlay prototype moment)

Variant planning tip: keep variant properties predictable and limited. Example for a button:

Button variants (example properties)
- Type: Primary | Secondary | Tertiary
- State: Default | Hover | Pressed | Disabled
- Size: Sm | Md | Lg
- Icon: None | Leading | Trailing

Quality gate: component/variant audit

• Variant properties are named consistently (e.g., “State” not sometimes “Status”).
• Each variant has the same internal structure (same layers, same padding logic) to avoid layout jumps.
• Text uses text styles; colors use color styles inside the component.
• Components resize cleanly: labels don’t overflow, padding stays consistent.

5) Create Auto Layout patterns (reusable building blocks)

Patterns are not “new components” so much as repeatable layout recipes. They speed up assembly and keep spacing consistent.

Patterns to include for this capstone

• Pattern/Form Stack: vertical stack with consistent gaps for login fields + buttons.
• Pattern/Settings Section: section header + list of settings rows.
• Pattern/Settings Row: left label + optional description + right control (chevron/toggle).
• Pattern/Card Grid or List: consistent padding, corner radius, and internal spacing.

Pattern rule: patterns should be built so you can swap child components (e.g., replace chevron with toggle) without breaking alignment.

Quality gate: spacing and alignment review

• Spacing tokens are consistent (e.g., 4/8/12/16/24). Avoid random numbers.
• Left edges align across sections; baseline alignment looks intentional.
• Touch targets are reasonable (buttons and rows feel tappable).

6) Assemble screens using instances (no “detached” UI)

Build screens on the Screens page by pulling in instances of your components and patterns. Treat the UI kit as the source of truth: if you find yourself drawing a new button, stop and add/adjust the component instead.

Screen build checklist (apply to each screen)

• Start with layout containers (top bar + main content stack).
• Drop in pattern instances (form stack, settings section).
• Fill with component instances (inputs, buttons, rows).
• Apply styles only through styles/components (avoid manual overrides).

Quality gate: instance integrity check

• No duplicated “fake components” (e.g., a rectangle + text pretending to be a button).
• Overrides are intentional (label text, icons) and not structural (padding, corner radius).
• If you needed a new state (e.g., input error), it exists as a variant, not a one-off.

7) Apply constraints and resizing behavior for realistic layouts

Make screens behave predictably when frames resize (useful for stakeholder demos and future iteration). Focus on the few behaviors that matter most: headers stay pinned, content scrolls, and key elements stretch appropriately.

• Top bar: pinned to top, stretches horizontally.
• Primary buttons: stretch to fill container width when appropriate (e.g., login CTA).
• Cards/rows: text area expands, trailing icons stay pinned to the right.
• Overlays: centered modal or bottom sheet anchored to bottom.

Quality gate: resize test

• Resize the frame width slightly: nothing overlaps or clips unexpectedly.
• Longer text strings still look acceptable (try a long username or setting label).
• Spacing remains consistent; no elements drift off-grid.

8) Wire the prototype (flows, transitions, overlays)

Now connect the screens into a single, easy-to-understand flow. Keep interactions simple and stakeholder-friendly: clear next steps, minimal branching, and at least one overlay moment.

Suggested prototype map

• Onboarding “Get started” → Login
• Login “Sign in” → Home
• Home “Settings” icon → Settings
• Settings “Save” → Toast overlay (“Saved”) or modal confirmation

Prototype interaction checklist

• Use consistent transitions (e.g., Smart Animate for in-place changes, Move In for navigation).
• Overlays: set background dim, click outside to close if appropriate.
• Include at least one error state: e.g., Login “Sign in” with empty fields triggers Input/Error variant screen or overlay message.

Quality gate: prototype flow testing

• Start from the first onboarding screen and click through without getting stuck.
• Back navigation works where expected (or is intentionally absent).
• Overlay opens and closes cleanly; no accidental double overlays.
• Interactive states don’t cause layout jumps (variants maintain size/padding).

Stakeholder-ready packaging (make it easy to review)

1) Create a “Summary” frame for reviewers

On the 00 Cover & Summary page, create one frame that explains what the reviewer is looking at and how to navigate. Keep it short and scannable.

Summary frame contents (template)

• Prototype goal: “Demonstrate onboarding → login → home → settings flow.”
• How to view: “Open prototype, click through primary actions; use top-left back where available.”
• UI kit contents: list the components and styles included (buttons, inputs, top bar, settings row, toggle, toast/modal).
• Notes: any known limitations (e.g., “Only one error scenario shown”).

2) Present mode navigation setup

• Set the starting frame to the first onboarding screen.
• Ensure the flow is named clearly (e.g., “Capstone Prototype”).
• Verify the prototype fits typical device dimensions for your screens.

3) Share/export guidance for comment-ready stakeholder review

Prepare a share link that supports feedback without confusion.

• Share link settings: allow comments for stakeholders who should provide feedback; restrict editing.
• Link target: point to the prototype flow (not the UI kit page) unless the stakeholder needs system review.
• Comment instructions: ask reviewers to comment on the specific screen and UI element, and to describe expected behavior if something feels unclear.

Quality gate: stakeholder review readiness

• The summary frame exists and is the first thing a reviewer sees in the file.
• The prototype opens at the correct starting screen and runs end-to-end.
• UI kit page is organized: styles grouped, components labeled, variants visible and understandable.
• No unfinished screens are mixed into the final Screens page.