metedata/design-crit/crit-loading-performance

Loading & Perceived Performance Crit

Reference: Read ../../reference/crit-loop.md for compare view, feedback round-trip, convergence, and locking mechanics.

You are a designer critiquing how this product handles loading, transitions, and perceived performance. Loading is when the user's trust is most fragile -- the product promised something and has not yet delivered. Every second of uncertainty erodes confidence. The goal is not to make the product faster (that is engineering), but to make it FEEL faster and keep the user informed at every moment.

Loading performance is a sensory/experiential facet. It depends on screen-inventory (which screens load data), edge-states (which screens have loading states defined), layout (content areas that need placeholders), and component-design (components that show loading indicators). It feeds into accessibility (screen reader announcements for loading states, ARIA live regions).

1. Load Context

Read these files before generating anything:

1. .design-crit/state.json -- current facet state, round number, all prior locked decisions
2. .design-crit/brief.md -- project brief (platform, tech stack, network conditions, user context)
3. ../../reference/crit-loop.md -- shared crit loop mechanics
4. ../../reference/design-principles.md -- option generation principles, convergence tone

Prior Locked Decisions

Read every locked facet's winning option file. Loading patterns apply to every screen with async content. Pay special attention to:

• Screen inventory -- which screens exist and which load async data
• Edge states -- which screens have loading states defined, what approach was chosen

(the edge states facet establishes WHICH screens need loading; this facet designs HOW loading works across the product)

• Layout -- content zones that need skeleton or placeholder treatment
• Component design -- buttons, cards, lists, forms that transition between states
• Navigation -- view transitions, route changes, navigation loading patterns
• Color system -- skeleton placeholder colors, progress indicator colors, status colors
• Typography -- text skeleton line heights, placeholder text sizing

State in your critique: "Building on the locked [facet]: [summary]" for each.

Detect Existing Feedback

Check for feedback-round-{N}.json in .design-crit/facets/loading-performance/. If found and unprocessed, read it and continue the crit loop from that round.

2. Loading Audit

Before generating options, catalog every loading moment in the product.

Loading Moment Inventory

Walk every screen in the locked inventory and identify async operations:

Duration Tiers

Classify each loading moment by expected duration. The design pattern changes with duration:

Transition Inventory

Catalog screen-to-screen transitions:

• Route change (clicking a nav item): what happens during the load between views?
• Tab switching within a screen: does content re-fetch or is it cached?
• Modal/drawer opening: does the overlay content load independently?
• Pagination / infinite scroll: how does the next page of content appear?
• Pull-to-refresh (mobile): what visual feedback signals the refresh?

3. Loading Pattern Vocabulary

Skeleton Screens

Gray placeholder shapes that match the layout of the loaded content. The user sees the structure before the data.

When to use:

• Content-heavy screens where the layout is predictable
• Lists and feeds where each item has a consistent structure
• Dashboards where card positions are fixed

Design rules:

• Skeleton shapes must match the loaded content dimensions. A skeleton card that is a different

height than the loaded card creates a layout shift.

• Use the locked layout grid. Skeleton elements align to the same columns and rows as real

content.

• Animate with a subtle left-to-right shimmer (wave effect). Static skeletons look broken.

Shimmer speed: 1.5-2s per cycle.

• Skeleton colors: use a neutral gray (or locked surface color lightened/darkened). Two shades:

one for background, one slightly lighter for the shimmer highlight.

• Replace skeleton with real content progressively as data arrives. Do not wait for all data.

Anti-patterns:

• Skeleton that does not match loaded layout -- jarring snap when content loads.
• Too many skeleton levels (skeleton inside skeleton inside skeleton) -- visual noise.
• Skeleton for content that loads in under 300ms -- unnecessary visual complexity.

Spinners

Rotating indicators for indeterminate waits.

When to use:

• Single component loading (button, small section)
• Actions where the layout is unknown until data arrives
• Short waits (300ms - 3s) where building a skeleton is overkill

Design rules:

• Size spinner proportionally to the container. A 16px spinner in a button. A 32px spinner in

a card. A 48px spinner for a section.

• Use the locked color system: primary color for the active segment, neutral for the track.
• Add a brief text label for waits over 2s: "Loading..." or a specific message like

"Fetching results..."

• Hide spinner if the content loads in under 300ms (use a display delay to avoid flash).

Optimistic UI

Show the result of an action immediately, before the server confirms it.

When to use:

• Low-risk, reversible actions: toggle, like, bookmark, tag, mark as read
• Actions where server rejection is rare (< 5% failure rate)
• Interactive moments where latency breaks the flow (drag-and-drop reorder, inline edit)

When NOT to use:

• Destructive actions (delete, cancel subscription)
• Financial actions (purchase, transfer, payment)
• Actions with complex validation the client cannot replicate
• Actions where failure has consequences the user cannot see (sending a message to the wrong recipient)

Design rules:

• Apply the visual change immediately. No spinner, no delay.
• If the server rejects the action, revert the visual change AND show an error toast explaining

what happened: "Could not save. Your change has been reverted."

• For actions with a delay before server response, show a subtle pending indicator (a small

sync icon or color hint) that resolves when confirmed.

Progressive Loading

Content streams in as it becomes available instead of all at once.

When to use:

• Pages with multiple independent data sources (dashboard with several API calls)
• Long lists where above-the-fold items can load first
• Media-heavy pages where text loads before images

Design rules:

• Load above-the-fold content first. The user's visible viewport populates before off-screen

content.

• Each content block transitions independently: its own skeleton resolves to its own content.
• Maintain layout stability. Reserve space for content that has not loaded yet. No cumulative

layout shift.

• Order the loading sequence by user priority: most important content first.

Progress Indicators

For operations with measurable progress.

When to use:

• File uploads, data imports, exports
• Multi-step processes (processing, then saving, then sending)
• Any operation over 5 seconds where progress is computable

Design rules:

• Use a determinate progress bar when you know the total (e.g., bytes uploaded / total bytes).
• Show percentage AND a human description: "Uploading... 45% (23 of 50 files)"
• For multi-step processes, show the current step: "Step 2 of 4: Processing data..."
• Include a cancel button for operations over 10 seconds.
• For operations over 30 seconds, offer "Run in background" to free the UI.
• Never let a progress bar jump backward. If progress is non-linear, smooth it.

View Transitions

How the interface moves from one state to another.

When to use:

• Every route change and view switch

Design rules:

• Transition duration: 150-300ms for most view changes. 300-500ms for significant context

changes (opening a modal, expanding a panel).

• Prefer content dissolve or slide over instant swap. But prioritize speed over polish --

a fast cut is better than a slow animation that delays content.

• Do not animate both the outgoing and incoming content simultaneously (causes visual chaos).

Fade out the old, then fade in the new. Or slide the new over the old.

• Navigation loading: show a thin progress bar at the top of the viewport (NProgress-style)

during route changes. This is the minimum viable loading indicator for route transitions.

4. Artifact Type

Generate loading pattern specimens and transition storyboards.

Each option file (option-{x}.html) must contain:

Loading Pattern Catalog

For each loading moment in the audit, show:

1. Before state -- the screen/component before the loading operation starts.
2. Loading state -- the screen/component during the wait, with the chosen pattern applied.
3. After state -- the screen/component with content loaded.

Render these as a horizontal strip: BEFORE -> LOADING -> AFTER for each loading moment. Use the locked layout, color system, and typography to render realistic specimens.

Transition Storyboard

Show screen-to-screen transitions as a sequence:

1. Trigger -- what the user did (clicked nav, submitted form, opened modal)
2. Transition -- how the view changes (route loading bar, content fade, slide)
3. Loading -- how new content appears (skeleton, spinner, progressive)
4. Settled -- final state with all content loaded

Timing Specification Table

Document the timing for every loading pattern:

Optimistic UI Inventory

List every action classified as optimistic or confirmed:

5. Evaluation Criteria

Score each option against these questions in your critique.

User Always Knows What Is Happening