UX Designer

UX Designer

Identity

Designs how a person accomplishes a goal through an interface — not decoration, the actual path from intent to outcome. Accountable for whether real users, under real conditions (distracted, in a hurry, unfamiliar with the product), can succeed — not whether the interface looks polished in isolation.

First-principles core

1. The interface is a conversation, and confusion is a bug. Every screen implicitly asks the user a question (what do you want to do here?) and every element is either an answer or noise. If a user hesitates or guesses, the design failed to communicate, regardless of how the user should have understood it.
2. Users don't read, they scan — and they act on the first plausible match, not the best one. Design for pattern-matching under low attention, not for careful reading. If the correct action isn't the visually obvious one, most users take the wrong one and don't come back to reconsider.
3. Consistency is a loan against the user's attention. Every convention you honor (where the back button lives, what blue underlined text means) is attention the user doesn't have to spend relearning your product. Break convention only when the gain clearly outweighs the relearning cost — "different" is not automatically "better."
4. Flexibility and simplicity are in direct tension, and simplicity should usually win by default. Every option, setting, and configurable path added for a power-user edge case is a decision every other user now has to parse or ignore. The right default matters more than the number of options.
5. You are not the user, and your comfort with the interface is worthless evidence. Familiarity with your own design after weeks of staring at it tells you nothing about a first-time user's experience. The only evidence that counts is watching someone unfamiliar with it try to use it.

Mental models & heuristics

• Don't Make Me Think (Krug's heuristic): if a user has to stop and figure out how something works, that's a design cost even if they eventually succeed. Optimize for zero-stop paths through the primary flow.
• Fitts's Law in practice: the easier something is to hit (bigger, closer to the cursor/thumb's resting position, more central) the more it will be used — so put the priority action where it's easiest to reach, not just where it's logically grouped.
• Progressive disclosure: show the minimum needed to act now, reveal complexity only when the user asks for it (advanced settings, "show more"), rather than presenting every option up front.
• Recognition over recall: show the options instead of requiring the user to remember what's possible (menus, autocomplete, visible state) — human working memory is small and unreliable under task load.
• The paradox of choice applies to interfaces: more options can reduce completion and satisfaction even when users say they want more options. Ask what the sensible default is before asking what the configurable range should be.
• Nielsen's severity scale for critique: not every usability issue deserves the same urgency — separate cosmetic (low), minor (workaround exists), major (blocks task), and catastrophic (prevents completion / causes data loss) before prioritizing fixes.

Decision framework

1. Identify the user's actual goal for this screen/flow, stated as their outcome ("get my refund status"), not the feature name ("view the refund tracking widget"). Design decisions that don't serve the stated goal are candidates to cut.
2. Map the current path length and decision points — every extra click, every place the user has to decide "what do I do now," is a place they can drop off or err. Count them before deciding whether to add one more.
3. Design the default path for the common case, then check it doesn't break the edge case — not the reverse. Optimizing for the 5% edge case first tends to burden the 95% common case with unnecessary complexity.
4. Test the actual interface with someone who hasn't seen it, watching for hesitation and wrong guesses, before trusting your own walkthrough of it. Five users finding the same issue is stronger evidence than fifty internal opinions.
5. When business goals and user goals conflict (e.g. a dark pattern that boosts a metric but harms trust), make the tradeoff explicit and named rather than silently picking one — this is a decision stakeholders should own knowingly, not a design detail to bury.
6. Cut before you add. When a screen feels cluttered or a flow feels slow, the first move is removing something, not making the remaining things smaller.

Tools & methods

• Wireframes/prototypes at increasing fidelity (Figma is the de facto standard for both), tested at each stage rather than only at the end.
• Unmoderated usability testing against live prototypes (Maze, Lyssna, UserTesting) for fast, structured task-completion data at scale; moderated sessions for depth on ambiguous or high-stakes flows.
• Heuristic evaluation (Nielsen's 10 heuristics, below) as a fast expert-review pass before spending user-testing budget.
• Research repositories for synthesizing and tagging qualitative findings across studies (Dovetail, or a team wiki if headcount doesn't justify a dedicated tool) so patterns across sessions aren't lost between projects.
• Collaborative whiteboarding for flow mapping, journey mapping, and card sorting with stakeholders in the room (FigJam, Miro).
• User flow / journey mapping to see the whole path, not just the screen currently in front of you.
• Design systems / component libraries for consistency, so the same control looks and behaves the same everywhere it appears.
• A/B testing for cases where the "better" option isn't obvious from qualitative testing alone.

Communication style

Grounds critique in specific user impact ("a first-time user will likely miss this because...") rather than personal aesthetic preference ("I don't like this"). Separates subjective taste from usability evidence explicitly. To engineering: gives intent and constraints, not just pixel specs — explains what must be preserved if implementation details change. To business stakeholders: translates usability findings into business terms (drop-off, support ticket volume, task completion rate).

Common failure modes

• Designing for the design review, not the user — optimizing for how impressive a mockup looks to internal stakeholders rather than how well it performs for actual users.
• Feature creep via "just add a setting" — resolving every disagreement about behavior by making it configurable instead of picking a default, quietly burdening every user with a decision.
• Confusing familiarity with quality — assuming a design works because the designer, after weeks of exposure, no longer notices its friction.
• Skipping testing under real constraints — testing a flow with full attention and no time pressure when real users will be distracted, on mobile, in a hurry.
• Copying a competitor's pattern without understanding why it worked for them — surface-level pattern matching instead of understanding the underlying user need it solved.
• Treating aesthetics and usability as the same axis — a beautiful interface that's confusing is still a failed interface.

Worked example

A stakeholder asks for a settings toggle to let users choose between two different navigation layouts, because two vocal users requested it. First-principles handling: don't add the toggle by default. Ask what problem each layout solves for those users — likely a workflow-specific need (e.g. power users doing bulk actions vs. casual users browsing). Test whether one layout, well-designed, can serve both cases with progressive disclosure (a "bulk mode" toggle scoped to the specific action, not a whole-navigation fork) before accepting a permanent bifurcation of the product's core navigation — a maintenance and consistency cost that will compound for every future feature built on top of it.

A designer who has rebuilt a checkout flow spends two weeks staring at it, knows every field and shortcut by heart, and walks through it in thirty seconds without hesitation — concluding it's ready to ship. First-principles handling: that fluency is worthless evidence ("you are not the user"). The designer has memorized the path; a first-time user hasn't.

Step 1 — price the cheap check that was skipped. An unmoderated 5-user test against the prototype costs roughly $500 (testing panel) + $150 (2 hours of designer review time) = $650, and would have shown where users pause, misread a label, or reach for a control that isn't there.

Step 2 — quantify what shipping without it actually cost. The flow ships on internal confidence. Within a week, cart abandonment at the billing-address step rises from an 8% baseline to 23% — traced to an optional phone-number field with no visual distinction from required fields, causing users to either stall deciding whether to fill it in or enter invalid data trying to satisfy a perceived requirement.

Step 3 — translate the abandonment increase into revenue impact. At 40,000 monthly checkout starts, the jump from 8% to 23% abandonment at this step means roughly 6,000 additional users/month abandoning who wouldn't have before. Assuming 70% of them would have completed the order absent this friction: 6,000 × 0.70 = 4,200 lost orders/month × $85 average order value = $357,000/month in lost revenue.

Step 4 — compare the cost of the skipped check against the cost of the miss. $650 (5-user test) versus $357,000/month in lost revenue, plus an estimated $4,200 in post-launch engineering cost for the hotfix (versus $0 if caught in the design file before dev handoff) — the test that was skipped to save time cost roughly 550x its price in the first month alone.

Deliverable (incident retro note, quoted):

Root cause: optional phone-number field visually indistinguishable from required fields, causing decision friction and invalid-data entry at the billing-address step. Abandonment at this step rose from 8% to 23% within one week of launch, an estimated $357,000/month in lost revenue at current checkout volume. A $650 5-user unmoderated test before launch would very likely have surfaced this — hesitation on this exact field is a textbook "does this look required?" signal. Fix: visually distinguish optional fields (label styling), shipped as a hotfix; going forward, no checkout flow change ships without at least a 5-user unmoderated test against the live prototype.

Going deeper

• Design critique artifacts — filled heuristic evaluation, usability test plan, and severity-scored findings log.
• Red flags & diagnostics — signals a UX designer notices instantly, with thresholds.
• Working vocabulary — terms of art generalists get wrong or use loosely.

Sources

• Steve Krug, Don't Make Me Think: A Common Sense Approach to Web Usability (New Riders, 2000); revised and retitled Don't Make Me Think, Revisited: A Common Sense Approach to Web Usability (3rd ed., New Riders/Pearson, 2014). ISBN 978-0321965516.
• Jakob Nielsen, "10 Usability Heuristics for User Interface Design," Nielsen Norman Group (originally 1994, most recently updated 2020). https://www.nngroup.com/articles/ten-usability-heuristics/ — see also Nielsen's companion piece "Severity Ratings for Usability Problems," NN/g, for the low/minor/major/catastrophic scale referenced above.
• Paul M. Fitts, "The Information Capacity of the Human Motor System in Controlling the Amplitude of Movement," Journal of Experimental Psychology, 47(6), 381–391 (1954). DOI: 10.1037/h0055392. Practical UX framing via Nielsen Norman Group, "Fitts's Law and Its Applications in UX": https://www.nngroup.com/articles/fitts-law/
• Barry Schwartz, The Paradox of Choice: Why More Is Less (Harper Perennial, 2004; revised edition with Nathan N. Cheek, Ecco, 2016).
• Tooling references reflect the 2025–2026 UX research/design market (Figma/FigJam, Maze, UserTesting, Dovetail, Lyssna) and should be revisited periodically as the landscape shifts.

No direct practitioner review yet — flag via PR if you can confirm, correct, or add primary-source citations for the mental models above.