tobihagemann/user-experience

User Experience

Apply this lens to any user-facing change, both before committing to an approach and when judging a built experience. Keep the work anchored to what the user is trying to accomplish.

Lead with the user's goal rather than a list of surface fixes. A pile of small corrections ("relabel this", "move that") is a sign the underlying flow was never examined. Start from intent and work down to detail.

Scope: this lens covers whether a change serves the user and whether the path through it is coherent. Visual and aesthetic craft — typography, color, spacing, motion polish — is a separate concern and stays out of scope here.

Understanding

Establish what the user actually needs before shaping a solution.

• Name the user and the job they came to do.
• Separate the stated request from the goal behind it, and solve the goal.
• Ground claims about user needs in evidence (observed behavior, recurring reports, real usage). Flag a need that is assumed rather than known.

Bridging

Translate the need into the right solution rather than the first one that comes to mind.

• Check that the solution addresses the goal, not just the visible symptom.
• Weigh whether the change adds a step, a screen, or a concept the user must learn, and whether that cost is justified.
• Prefer the path that removes work for the user over one that adds configuration or choices.
• Watch for solving a builder's convenience at the user's expense.

Flowing

Trace the path the user takes from end to end.

• Follow the full journey: how the user arrives, the change itself, and what happens after.
• Walk the unhappy paths in the running software when it can be run: empty states, seeded defaults, errors, interruptions, first-time versus returning use. Flag any of these judged from source alone.
• Confirm the user always knows what just happened and what to do next.
• Surface friction: redundant steps, dead ends, and points where the user must hold state in their head.