Capstone: Redesign a Tool Surface

By the end of this lesson, you will be able to...

• Produce an evidence-backed redesign dossier for one bounded product surface.

• Connect task pressure, system state, information structure, hierarchy, restraint, product promise, and reusable patterns in one proposal.

• Defend your changes with an explicit rubric, trade-offs, edge cases, and a testable next step.

Idea in one sentence: A good redesign makes a user's next safe action clearer while preserving the evidence, control, and product promise that make the action worth trusting.

Core Insight

Imagine Lena is reviewing a release in an internal deployment console. The team has shipped many improvements, but the approval screen still asks her to translate the system every time:

Release 2.4.0       status: green
service: checkout   owner: core-platform
build: 8812         checks: 17 passed
[Deploy] [More]

Lena knows that the database migration is still running. The screen's green status represents the build, not the release. The Deploy button starts a production change, but the affected region, rollback plan, and current approval are hidden behind More. An expert can remember a keyboard shortcut; a new teammate does not know which object is being changed.

The screen is not missing a fashionable framework. It is missing a coherent argument about pressure, state, structure, attention, control, promise, and reuse.

This capstone asks you to make that argument for one real or carefully observed tool surface. The redesign can be a dashboard, billing page, developer tool, support flow, settings screen, or other bounded interface. It must remain grounded in a user task and the system behavior behind that task.

The trade-off is not “old versus beautiful.” A redesign can improve flow and reduce translation, but it must preserve expert speed, edge-case control, accessible reading, and honest uncertainty. Your dossier should make those costs visible instead of hiding them in a polished mockup.

The Capstone Contract

Choose one surface with a clear boundary. A useful boundary has:

• one primary user task;
• a small set of related objects and states;
• at least one meaningful decision or action;
• enough observable detail to compare the current experience with your proposal.

Good choices include:

approve a deployment
review a partial refund
investigate a failed webhook
configure an access policy
triage an incident
compare an analytics segment

Do not redesign an entire product or invent a brand-new feature set. The capstone proves judgment on a bounded surface. You may use screenshots, notes, a text wireframe, a prototype, or annotated diagrams. The artifact matters less than the reasoning that connects evidence to decisions.

Your final dossier should contain:

1. an intent-and-pressure brief;
2. a current-state map and evidence log;
3. a proposed structure and task path;
4. a state and feedback trace;
5. an annotated hierarchy and reading order;
6. a control inventory with simplification decisions;
7. a promise-to-evidence map;
8. a component decision sheet with variants and exceptions;
9. a before/after comparison, rubric score, and next test.

Step 1: Name the Pressure and Promise

Start with the user, not the screen.

Write one sentence in this form:

[Person] needs to [job] while [constraint or uncertainty], so they need to [next safe action].

For Lena:

A release engineer needs to approve a production deployment while one migration is still running, so she needs to verify the release state and choose whether to wait, proceed with a safeguard, or stop.

Now name the product promise in practical language:

The console shows the real release state, explains consequences, and keeps rollback or escalation available.

This sentence gives later decisions a test. A larger title is not automatically useful. A hidden migration status is a failure if it prevents Lena from evaluating the promise.

Record the cost of confusion. It may be a duplicate refund, a production outage, a lost hour, an incorrect permission, or a support escalation. The cost tells you which evidence and recovery paths deserve first-view attention.

Step 2: Map the Current Surface

Capture the current interface without judging it yet. List:

• objects: release, build, service, migration, region, approval, rollback;
• states: queued, running, passed, blocked, deployed, failed, unknown;
• actions: inspect, approve, deploy, pause, rollback, escalate;
• relationships: which build belongs to which release, which migration affects which region;
• labels: the words users see and the internal names they may not recognize;
• entry paths: where the user comes from and where they go next.

Then trace one task using the format:

input -> transition -> intermediate state -> decision -> output

For the current deployment screen:

release link
-> open approval page
-> see green build status, hidden migration
-> click Deploy without knowing whether migration is safe
-> production change begins

Mark unknowns separately from facts. If you cannot tell whether green means build, release, or environment, that ambiguity is evidence. Do not fill it with a confident assumption.

Step 3: Rebuild the Information Path

Use the information-architecture method from 003. Start from the user's question:

Is this release safe to deploy now, and what can I do if it is not?

A task-shaped structure might be:

Release 2.4.0
  Current state: migration running in eu-west
  Evidence: build checks, migration progress, affected region
  Decision: wait / deploy with safeguard / stop
  Recovery: rollback plan, owner, incident link
  Supporting details: raw logs, audit events, export

The team ownership (core-platform) remains useful for escalation, but it should not replace the user's path. Navigation, search, and contextual links should converge on the same canonical release object.

Test the path with a person who does not know your internal naming. Ask them to find the migration state and explain what happens after Deploy. Record the words they expect, not only their completion time.

Step 4: Make State and Feedback Observable

Use the heuristic and behavior lessons to list what the system can show:

Do not collapse these into a single color badge. A system state is part of the product promise. Feedback should answer what changed, what is still uncertain, and what action is safe now.

Step 5: Tune Hierarchy and Reading Rhythm

Apply the attention jobs from 004. Annotate every visible element as:

orient · state · evidence · action · support

For Lena, the first view might read:

Release 2.4.0 · Checkout · Production

Migration running in eu-west
Build checks: 17 passed · release readiness: blocked

What you can do
[Wait for migration] [Review safeguard]

Rollback plan available · Owner: Core Platform
View checks · View audit trail · Open incident

Use scale, weight, spacing, alignment, and contrast to make that order visible. Keep state text explicit; do not rely on green or red alone. Check the screen with enlarged text, a narrow viewport, and a grayscale view. If the decision changes when color disappears, the hierarchy is carrying too much meaning in one channel.

Step 6: Simplify Without Deleting Control

Create the control inventory from 005:

For every removed or hidden element, write where its job went. A clean screen that removes the rollback plan has not simplified the decision; it has transferred risk to memory and guesswork.

Defaults need the same scrutiny. If the console defaults to the last environment, show the environment and require review. If the system blocks deployment while migration runs, explain the rule and offer a safe alternative rather than a dead button.

Step 7: Show the Promise in Several Moments

Use the promise-to-evidence map from 006:

Adapt the tone to the moment. A concise status line can orient. A failure needs precise evidence. A support handoff may need more context. The promise remains stable even when the expression changes.

Step 8: Define Reusable Patterns

Use the review from 007 to create a small system, not a catalog. For each proposed component, document:

• protected user promise;
• states and required evidence;
• content and behavior owned by the component;
• content owned by the surrounding task;
• valid variants;
• one justified exception;
• accessibility or localization constraint;
• signal that would show the component is stale or misused.

Example:

Component: ReleaseState
Promise: show readiness honestly.
States: checks-running, migration-running, ready, deploying, failed, unknown.
Owns: state label, explanation, timestamp, semantic status.
Surrounding task owns: release details and available action.
Variant: compact list row versus detailed review panel.
Exception: security incident state includes escalation guidance inline.
Boundary signal: teams replace the label with local colors or add flags for unrelated workflows.

Reuse the contract, not just the badge shape. A component that cannot express unknown is not complete for a system that sometimes lacks evidence.

Worked Example: Before and After

Before

Release 2.4.0     green
[Deploy] [More]

After

Release 2.4.0 · Checkout · Production

Blocked: migration running in eu-west
17 build checks passed · release readiness is not yet confirmed

[Wait for migration] [Review safeguard]

Rollback plan available · Owner: Core Platform
View checks · View audit trail · Open incident

The after version is not “better” because it contains more copy. It is better if users can answer the task question, distinguish state from evidence, choose a safe action, and recover when the state changes. Test that claim with observation.

Capstone Rubric

Score each dimension from 0 to 3:

A passing dossier should average at least 2 and score at least 2 on state and feedback, hierarchy and access, restraint and control, and evidence. A beautiful screen with a hidden state is not a passing redesign.

Common Confusions

Confusion: the capstone is a visual makeover

Why it is tempting:

Before-and-after screens are easy to present.

Better model:

The artifact is a decision argument. Visual changes are evidence only when they make a task, state, hierarchy, promise, or recovery path clearer.

Confusion: more content means more rigor

Why it is tempting:

A long dossier can feel safer than a small set of explicit decisions.

Better model:

Rigor comes from traceable choices, intermediate states, constraints, and tests. Remove details that do not change a decision; keep evidence that protects safe action.

Confusion: consistency is the final goal

Why it is tempting:

One visual language can make a product feel finished.

Better model:

Consistency is a tool for reducing repeated confusion. Preserve meaningful exceptions when a uniform rule would hide state, risk, or user control.

Confusion: speed is the only success metric

Why it is tempting:

Shorter completion time is easy to measure.

Better model:

Task success also includes correct interpretation, safe action, recovery, expert control, and confidence grounded in evidence. A fast wrong deployment is not an improvement.

Final Practice: Submit the Dossier

Choose your surface and produce the nine artifacts in the capstone contract. Before calling it complete, ask another person to perform the primary task using only your proposed flow.

Record:

• what they thought the object and state were;
• where they looked first;
• which words they used for the same concept;
• what they expected each action to change;
• where they hesitated, searched, or used a workaround;
• whether they could recover from an edge case;
• which component rule or exception they questioned.

Revise one decision after this observation. The final dossier should state what changed, why it changed, and what remains unknown. That last section is part of good design: a redesign is a reasoned hypothesis, not proof that every user will succeed.

Resources

• [ARTICLE] Design Thinking: Getting Started — Focus: Use the cycle of evidence, framing, ideation, and testing without turning the capstone into a generic process exercise.
• [ARTICLE] Usability Testing 101 — Focus: Observe task interpretation, errors, and recovery rather than asking only whether someone likes the redesign.
• [ARTICLE] Material Design: Foundations — Focus: Compare system-level guidance with the capstone's need to justify states, hierarchy, accessibility, and exceptions.

Key Takeaways

• A capstone redesign begins with a pressured task, a product promise, and the cost of confusion.
• The dossier should make objects, paths, states, hierarchy, controls, recovery, and evidence visible before polishing the surface.
• Minimalism, typography, brand, and design systems are means to make the next safe action clear; none replaces observation.
• Reusable patterns should encode a tested contract with states and exceptions, not only shared visual tokens.
• The trade-off is flow versus control: a successful redesign reduces translation while preserving expert speed, edge-case safety, accessibility, and honest uncertainty.