Show evidence before action
The path moves through signals and release context before presenting the change for confirmation.
CASE STUDY · PRODUCT EXPERIENCE
Northstar: evidence before a consequential action
Balancing operational speed with the context an operator needs to review a version change.
Kimberly Flowers · Product creative direction
01 / THE PROBLEM
What needed to be solved.
An operator sees an API gateway with a 4.8% error rate, 820 ms latency, and version v2.8.1. Those values signal a problem, but do not by themselves answer what caused it or whether moving to a previous version is the right response.
The design tension was speed versus decision confidence. Placing rollback beside the first metric would make the action easy to reach, but would also let the operator skip release context. Showing every signal and control together would preserve access at the cost of a clear reading order. I organized the experience around the decision rather than the volume of data.
02 / MY ROLE
The direction I set.
I set a sequence in which each view earns the next action: inspect the affected application, read the evidence, inspect the deployment, then review the exact proposed version change. The service, environment, version, and owner remain part of the context.
My central decision was to require a specific review before confirmation. The review names the move from v2.8.1 to v2.8.0 and provides a cancellation path back to the deployment. I treated that information as the action’s essential content, not as a generic “Are you sure?” dialog.
This adds a step. I accepted that cost because the point of the review is to make the target understandable, not merely to interrupt a click. I also kept the explanation precise: errors increased after the deployment, but timing alone does not establish cause.
03 / THE SOLUTION
How I addressed the problem.
I separated four questions that a single dashboard can blur: What is affected? What do the signals show? What changed? What exactly am I about to do?
| Design issue | My solution | What changes for the customer |
|---|---|---|
| Separate a reading from an explanation | Group error rate, latency, and active version in one row; place the trend and a plain-language explanation below it. | The operator can inspect current values and change over time without mistaking either for a root-cause diagnosis. |
| Make confirmation carry useful information | Name the application, environment, current version, and target version before the simulated action. Keep Cancel connected to the deployment context. | The operator can verify the precise target or return to context without committing. |
| Keep the result connected to follow-up | Show the restored sample version, add the simulated rollback to history, and retain an investigation owner. | The operator can trace the action and identify the work that remains before redeployment. |
DESIGN TRADE-OFF
The decision: add friction where it improves the decision
An immediate rollback control would shorten the path. A generic confirmation would add a step without adding much context. I chose a target-specific review after the deployment details.
The operator takes an extra step. In return, that step exposes the exact version change, a clear cancellation path, and the difference between observing a signal and confirming an action.
04 / GUIDING PRINCIPLES
The rules behind the decisions.
Be precise about uncertainty
Timing can suggest a connection. The explanation should not turn that clue into a root-cause conclusion.
Use color with labels
Orange emphasizes the trend and action. Values, version identifiers, environment labels, and explanatory text carry the meaning.
05 / REUSABLE PATTERNS
How the solution carries through.
The reusable foundation is an evidence-to-action pattern: metric tiles, trend context, release summary, target-specific confirmation, result, and ownership. Reuse should preserve those relationships, not just the shape and color of the cards.
The acceptance checks are explicit: every action has a named target; signals remain attached to a service and environment; color is accompanied by labels; cancellation preserves context; and the result can be traced in history. These are concrete review criteria a product team can apply while keeping its own technical responsibilities.
The pattern does not make every operation equivalent. Destructive changes, permission differences, unavailable telemetry, and failed recovery need additional states and safeguards. Those are extension decisions for Product and Engineering, with the visual and content standard providing a consistent starting point.
06 / THE RESULT
What changed in the experience.
The walkthrough now supports a complete decision path: investigate the API gateway, inspect its deployment, review the v2.8.1 → v2.8.0 target, cancel or confirm the simulation, and inspect the resulting history. The result also preserves a follow-up owner.
The delivered experience makes the action inspectable and traceable rather than merely prominent. To evaluate its quality with operators, I would ask them to identify the target, explain what the evidence does and does not establish, and describe what remains after the action.