日本語

Common UX Designer Pitfalls (And How to Stop Repeating Them in Year Two)

The performance review didn't go badly. "Solid execution. Needs more strategic impact." You nodded. You said the right things about owning more outcomes. You walked back to your desk and felt the floor tilt, because you've been busy for fourteen months and you couldn't name a single business metric you've moved.

Six months from now nothing changes unless one of the patterns below gets named and broken. The split between year-two designers who compound into senior ICs and year-two designers who plateau as ticket-takers happens around month eighteen. It's almost never about Figma skill. It's about seven habits, every one of them invisible to the designer doing them and obvious to the manager writing their review.

This is the mirror, not the TED talk. Pick the worst one. Fix it. Come back next month for the next one.

Why This Hits at Month Eighteen

The first twelve months of a UX role are forgiving. You're learning the product, the team, the design system, the tooling. Nobody expects strategic impact in month four. By month eighteen the grace period is over and the calibration committee is asking a different question: is this person going to be senior in two years, or are they going to be the junior who reliably ships polish work forever?

The answer almost never lives in their craft. It lives in seven recurring patterns. Each one feels productive in the moment. Each one shows up as missing context in the promotion packet.

The Seven Pitfalls

Pitfall 1 — Becoming the "make it pretty" interrupt-driven IC

Symptom: Slack DMs from PMs asking for "a quick polish on this screen" four to six times a week. Your calendar is 70% reactive, 30% your own work. You finish Friday feeling tired and useful, and you can't point to anything you owned.

Real number: Designers who accept more than five unscheduled requests per week ship 40% fewer owned projects per quarter than peers who batch them into a single block. Here's the kicker. The unscheduled work doesn't show up as your work in the promotion doc. The PM gets credit for the feature. You get credit for "being responsive."

Fix: One office-hours block per week (Tuesday and Thursday, 2-4pm) for polish requests. Everything else gets a Linear ticket and goes through normal triage. Tell the team once. Hold the line for two weeks. The inbound stops because PMs adjust to the constraint, not because they respect it. Reactivity is a habit on both sides.

Pitfall 2 — Skipping user research because "PM already talked to customers"

Symptom: Every design rationale starts with "PM said users want…". Zero direct user contact in the last sixty days. When engineering pushes back on a flow, you can't say what users actually do, only what the PM remembers them saying.

Real number: Features designed without designer-led research have roughly 2.3x the post-launch redesign rate of features where the designer ran at least one user session. PMs are great at problem framing and bad at design implications. The signal you need is in the second-order behavior (where the cursor hesitates, what gets reread, which fields get abandoned), and PMs aren't watching for that.

Fix: Five user calls per quarter. Non-negotiable. On your calendar before the quarter starts, not slotted in when there's room. Thirty minutes each. Even unmoderated UserTesting clips count if you watch them end-to-end and write up two patterns. Bring receipts to your next design crit. Your manager will fight for headcount for a designer who shows up with verbatims; they won't fight for one who paraphrases the PM.

Pitfall 3 — Over-relying on Figma without spec discipline

Symptom: Engineers ask the same questions every handoff. Empty states. Error states. Loading. Breakpoints. You answer in Slack threads and never update the file. Three weeks later the same question comes back from a different engineer because the Slack thread is buried.

Real number: Average engineering question backlog per Figma handoff is 12-18 questions when specs are missing, 2-3 when specs are tight. That's four to six dev hours saved per ticket, plus the bigger win: your reputation. Half of your "design quality" reputation lives in this artifact. Engineers don't see the polish; they see whether the file answers their questions before they have to ask.

Fix: A handoff checklist pinned to every cover frame. Empty / loading / error / 320px / disabled / hover / a11y notes. Not optional. Not "I'll add it if there's time." If a state isn't in the file, the engineer assumes it doesn't exist and ships their best guess, and you'll spend the next sprint redesigning around their guess. Make the checklist a Figma component. Drop it on every cover frame on day one.

Pitfall 4 — Making one-off components instead of using the design system

Symptom: Three slightly different button styles in your last release. "I needed it slightly bigger." "The DS one didn't quite work for this layout." "I'll back-port it to the system later." You never back-port it.

Real number: Audit any six-month-old product without DS discipline. You'll find 30-60 button variants, 8-12 modal patterns, and a maintenance bill measured in engineering quarters. Every one-off you ship today is technical debt that the DS team has to either absorb or fight. They notice. They remember.

Fix: If the design system doesn't have it, file a DS request before you start designing the screen. Treat "I'll just make a one-off" as a code smell. When you genuinely must deviate (and there are real reasons, like a marketing surface that doesn't follow product rules), document why in the file. The DS team needs that signal more than they need your apology. One-offs without rationale look like carelessness. One-offs with rationale look like design judgment.

Pitfall 5 — Ignoring accessibility until QA flags it

Symptom: Contrast failures, missing focus states, and keyboard traps caught in the last forty-eight hours before launch. Twice a quarter, minimum. Every time, you promise yourself you'll bake a11y in earlier next time. Every time, the next sprint starts and the deadline pressure pushes it back to QA.

Real number: Roughly 96% of homepages have detectable WCAG failures, per the WebAIM Million annual scan. The fix cost is 10x higher post-launch than caught in design. Partly because retrofitting accessible patterns into shipped code touches more files than designing them right the first time, partly because the people best-positioned to fix it (the original designer, the original engineer) have moved on to the next thing.

Fix: Run the Stark plugin on every frame before review. Include keyboard-flow notes in handoff specs ("tab order, focus ring color, escape key closes modal"), three lines, every modal. Treat WCAG AA as a P1 acceptance criterion in the ticket, not a nice-to-have you'll get to. Most a11y wins are decisions, not work. Picking the right contrast ratio costs zero extra hours when you do it during component selection. Picking it after QA flags a failure costs a full day of re-work plus a rebuild.

Pitfall 6 — Saying "trust me" instead of showing data

Symptom: Your design crit answers sound like "users will find this confusing" with no source. PMs and engineers stop pushing back, which feels like you won. Then you notice your proposals stop getting prioritized. They stopped trusting you; they just stopped arguing.

Real number: Designers who cite at least one data point per major design review get their proposal accepted 2x more often than designers who lead with intuition. The data point doesn't have to be quantitative research. It can be a support ticket count. A funnel drop. An NPS verbatim. A timestamped clip from a session recording. The bar isn't "rigorous study." The bar is "one piece of evidence outside your own head."

Fix: Every proposal opens with one number. One. Not five (five reads as defensive). Not zero (zero reads as opinion). Funnel drop, support ticket count, NPS verbatim, session recording timestamp. Whichever you have. The number doesn't have to be the strongest argument; it has to exist. Once it does, the rest of your reasoning lands as analysis instead of preference.

Pitfall 7 — Not measuring post-launch impact

Symptom: Ship date is the finish line. Two weeks later you can't say whether the redesign moved the metric it was supposed to move. When your manager asks "how did the checkout redesign do?" you say "I think conversion went up?" and change the subject.

Real number: Designers with named launch metrics get promoted to senior 30-40% faster than designers who only ship features. The reason isn't mystical. Promotion committees evaluate impact, and impact requires a before-number and an after-number. If you don't define the before-number at kickoff, the after-number is meaningless and your work shows up in the packet as "shipped X" instead of "moved Y from A to B."

Fix: For every project, write the success metric and target before kickoff. One sentence in the design brief. "Goal: lift checkout conversion from 2.1% to 2.5% within four weeks of launch." Two weeks post-launch, send a one-paragraph result note to the team. Bad results count too. "We shipped, conversion didn't move, here's what we learned" is career-positive. It signals you're tracking outcomes, not just outputs. Designers who hide bad results read as junior; designers who publish them read as senior.

Putting It Together — The Year-Two Designer Self-Review

Here's the artifact. Steal it. Ship it Friday.

A 15-minute weekly habit. Open a Notion doc. Score yourself 1-5 on each of the seven pitfalls every Friday at 4pm before you log off. Track the trend over time. Three months of data is worth a year of vague self-improvement.

Week of: ___________

1. Interrupt-driven IC          [1-5]  Notes:
2. Skipped user research        [1-5]  Notes:
3. Figma without spec           [1-5]  Notes:
4. One-off components           [1-5]  Notes:
5. A11y deferred to QA          [1-5]  Notes:
6. "Trust me" instead of data   [1-5]  Notes:
7. No post-launch measurement   [1-5]  Notes:

Lowest score this week: ___________
Single fix I'm applying next week: ___________

Scoring rubric. 5 means you're modeling the right behavior and could mentor someone on it. 3 means you're aware of the pattern but it slips when deadlines hit. 1 means you didn't even notice until you sat down to score it. Most year-two designers start with three or four 2s. That's normal. The point isn't the absolute score; it's whether the trend line is moving.

The handoff checklist for Pitfall 3, in case you want to ship that this week too:

Handoff Checklist (pin to cover frame)
□ Empty state designed and labeled
□ Loading state designed (skeleton or spinner)
□ Error states (network, validation, server)
□ 320px / mobile breakpoint
□ Disabled / hover / focus states
□ A11y: contrast, keyboard flow, focus ring, ARIA notes
□ Edge cases (long strings, zero data, 100+ items)
□ Analytics events documented

That's it. Eight bullets. Pin it on every cover frame. Engineers will start asking better questions because the basic ones are already answered.

What to Do This Week

Pick the one pitfall scoring lowest. Apply only its fix. The other six can wait.

Stacked fixes don't stick. Single fixes do. The designer who tries to overhaul their week-one habits across all seven dimensions is the same designer who's back to interrupt-driven Slack DMs by week three. The designer who picks the lowest-scoring pitfall (say, Pitfall 7, post-launch measurement) and does only that for three weeks is the one who shows up to their next review with one new line item: "Tracked post-launch impact on three projects this quarter; two hit target, one didn't, here's what we learned." That sentence is what senior reads like.

Naming the pattern is 80% of the fix. Year-two designers don't need more theory. They need a mirror.

Score yourself Friday. Pick one. Run it for a month. Repeat.

Learn More