Mission 05 · Applied build

Build a Responsive Enterprise SaaS Dashboard

Assemble a real product screen from the systems you built and design meaningful failure states.

4 hr mission time5 quiz questions+100 XP on clear
LVL 5
Desktop — table columns
StatusRegionRecovery pt.Action
Wireframe — Desktop — table columns
Mobile — stacked card
Name + statusRegion · recovery pt.Recovery action
Wireframe — Mobile — stacked card

The same workload data — desktop table vs. mobile card

Briefing

Your mission objective

Know what “cleared” looks like before opening Figma.

By the end, you can…

  • Assemble an application shell from components.
  • Transform tabular data for mobile without losing accessible structure.
  • Design loading, empty, warning, and error states with real form labels and error identification.

Bring with you

  • Days 1–4
  • Component and variable libraries
Intel

Decode the system

Understand the production logic before following steps.

A dashboard is where local component decisions become a product system. The application shell establishes stable navigation and page regions. Summary cards compress status. Filters change data. Tables support comparison. Each part must remain legible when names are long, data is absent, or actions are unavailable.

Responsive product design is transformation, not scaling. A persistent desktop side navigation may become a compact mobile header. A comparison table may become a list of cards that preserves only the most decision-relevant fields. Secondary actions can move into an overflow menu, while the recovery action remains visible — and the transformation itself must stay accessible: reading order still matches visual order, and nothing that was reachable by keyboard on desktop disappears on mobile.

States are part of the product, not optional decoration. Loading should preserve expected structure, empty states should explain how to begin, warnings should name risk, errors should offer recovery, disabled controls should explain prerequisites, and success should confirm what happened next. An error state needs to say which field is wrong and why — not just turn a border red.

Every filter and form field gets a real, visible label — not a placeholder standing in for one, which disappears the moment someone starts typing. Every tappable control, on any breakpoint, stays at a comfortable touch size; shrinking a desktop icon button for mobile is a common way to quietly drop below it.

01Shell

Stable navigation and content regions.

02Module

Reusable summary, filter, table, or alert pattern.

03State

Loading, empty, warning, error, disabled, or success.

04Transform

A deliberate, still-accessible mobile representation, not a scaled screen.

Build phase

Assemble the Cloud Recovery overview

Follow once, then explain each structural choice.

  1. 01

    Create the application shell with side navigation and top bar.

  2. 02

    Add three summary-card instances bound to tokens.

  3. 03

    Build search, status filter, and region filter as a responsive toolbar — give every field a real visible label, not a placeholder alone.

  4. 04

    Create a workloads table with status, region, recovery point, and action.

  5. 05

    Create loading, empty, warning, and error variants for the data area — the error variant must name the specific field or workload at fault.

  6. 06

    At tablet width, reduce secondary metadata before compressing type.

  7. 07

    At mobile width, replace each table row with a structured workload card, and confirm every tap target is still a comfortable size.

Practice canvas

Cloud Recovery Operations Platform

Build this fictional SaaS project in your own Figma file. No proprietary source file or private embed is required.

Framewise doesn’t yet have a duplicable starter file or a completed reference outcome for this mission — that’s on the roadmap, not something we’re pretending exists. The link below opens a genuinely blank Figma file, not a prepared course file.

Create a new Figma file
Chaos test

Try to break the build

A layout is not responsive until real variation tries to break it.

1

Use a 64-character workload name.

2

Show zero workloads.

3

Show five simultaneous warnings.

4

Disable recovery for one workload.

5

Check every mobile tap target against a comfortable minimum size — not just the desktop icon buttons scaled down.

Solo challenge

Build without the guide

Remove tutorial dependence and work from the outcome.

Create a workload-details screen using the existing library. Include overview data, recovery readiness, recent events, and the primary recovery action.

Independent timebox45:00
MISSION QUIZUP TO +40 XP
Checkpoint

Check your understanding

Five fast retrieval rounds. Land 80% to clear the checkpoint.

01A desktop table is unusable at 390 px. Best response?
02An empty state should include:
03Which action should remain visible on mobile?
04Why build state variants before polishing?
05Shared components across breakpoints help:
Verify

Pass criteria

Self-certify observable results, not effort.

Debrief

Lock in the learning

Write two short answers in your own notes.

  1. 01

    What information did you intentionally remove on mobile?

  2. 02

    Which state caused the largest layout change?

Mission reward · +100 XP

Ready to claim the reward?

Score 80% in the mission quiz and check off all 7 build criteria to claim the reward.