LinkedIn Post Ideas for UX Designers

Five users. One flow. Zero of them completed it. We'd spent three weeks on that onboarding flow. The team loved it — clean progressive disclosure, a slick animated stepper, copy we'd rewritten four times. In the war room before the test, someone said "this is the best onboarding we've shipped." Then we watched five people fail it back to back. Not fail as in "took longer than expected." Fail as in gave up, closed the tab, said out loud "I don't know what this is asking me." The stepper we were proud of hid the one piece of information people needed before they'd commit: what happens after step 3. The room went quiet around user three. By user five, the PM had opened a new Figma file. What we shipped a week later: fewer steps, worse looking, way better tested. Drop-off in the new flow was 9%. The old flow, had we shipped it, we later estimated at 40%+ from the session data alone. The lesson wasn't "test more." We already tested. The lesson was: love your design less than you love the data. Five sessions killed a flow that three weeks of internal reviews had unanimously approved. If your team hasn't watched a real user fail your favorite screen, you're still guessing.

A user told me, in a session, that they always read the terms and conditions before signing up. Then I watched their screen recording. Total time on the terms and conditions page: 0.4 seconds. They scrolled past, clicked accept, never slowed down. This happens in almost every interview I run. Not because people lie. Because we're all unreliable narrators of our own behavior. Ask someone how they'd use a feature and you get their aspirational self. Watch them use it and you get the truth. My rule now: interviews for context, observation for truth. I still ask questions — but about past behavior ("walk me through the last time you did X"), never hypotheticals ("would you use a feature that did Y"). Hypotheticals are where research goes to die. The pushback I get: "but they told us clearly what they wanted." Sure. And then the feature we built to spec sat at 4% adoption, because what they said and what they needed diverged the moment real friction showed up. Observe the workaround, not the wish. Users are excellent at describing symptoms and terrible at diagnosing causes. That's our job, not theirs. What's the biggest gap you've seen between what a user said and what they actually did?

No UserTesting subscription. No recruiting budget. Still ran five usability sessions this week. Here's the exact setup: — Prototype: Figma, clickable, 6 screens, built in an afternoon. — Recruits: three coworkers from other teams, two people from a Slack community for our industry. Cold DM, offered a $15 coffee gift card each. — Script: one task ("you just signed up, get to your first result"), three follow-up questions, nothing else. — Recording: QuickTime screen recording, Figma's observation mode as backup. — Time: 30 minutes booked, 20 used. Five sessions in one afternoon. What I got: two showstopper findings — a CTA label nobody understood, and a step people tried to skip entirely. Both fixed before engineering touched a line of code. What I didn't need: a research ops platform, a $2,000 recruiting budget, or two weeks of scheduling. The fanciest tool in this setup is a $15 gift card. The excuse I hear most is "we don't have budget for research." You have budget for five coffee gift cards and an afternoon. That's the whole barrier, most of the time. Save this if you've been putting off testing because it felt like it needed more than it does.

The button said "Submit." We changed it to "Get my results." Conversion on that step rose 12%, measured over two weeks and roughly 4,000 sessions — enough traffic that it wasn't noise. The hypothesis going in: "Submit" tells people what the system does. It says nothing about what they get. Nobody wakes up excited to submit something. People do want their results. We tested three variants against the control: "Get my results," "See my score," and "Continue." "Continue" performed identically to "Submit" — both generic, both invisible. "Get my results" won outright. "See my score" came close but underperformed slightly, we think because "score" implied judgment and some users hesitated. The bigger point isn't microcopy tips. It's that a one-word change outperformed two sprints of layout work we'd shipped the quarter before, which moved conversion by roughly 1%. Effort-to-impact on copy testing is absurd compared to almost anything else on a roadmap. And it's the cheapest experiment you can run — no engineering time, no design system changes, just an A/B test on text. What's the smallest change that produced the biggest lift you've seen?

I presented what I still think is some of my best design work. The client killed it in the first five minutes. The redesign solved every usability issue we'd found. Clean hierarchy, tested flow, measurably faster task completion in our prototype sessions. I was proud of it. The client's objection had nothing to do with usability. Their sales team used the cluttered old dashboard as a selling point in demos — "look how much data you get." My clean version, to their buyers, read as "less product for the same price." I hadn't asked a single sales rep how they used the interface in a pitch. I'd optimized for the end user and ignored the buyer, and in this business, they were different people with different needs from the same screen. We ended up shipping a hybrid: the density sales wanted on first load, a "simplify view" toggle for the actual end users doing daily work. Both metrics improved — demo-to-close rate and daily task completion. The lesson stuck harder than any usability heuristic: the user isn't always the only stakeholder in the room, and the best design solves the business problem, not just the interface problem. What's a rejection that taught you more than an approval did?

An engineer once handed me back a Figma file with 46 comments. Every one was a variation of the same complaint. Here are the three mistakes I see most, including ones I've made myself: 1. Missing edge states. The happy path looks great. Nobody designed the empty state, the error state, the "zero results" state, or what happens when a name is 40 characters long. Engineers build these anyway — just without you, and usually worse. 2. Unlabeled spacing. "It's however it looks in Figma" is not a spec. Auto-layout helps, but if your gaps aren't using consistent tokens, every engineer eyeballs a different number, and your product develops spacing drift within a month. 3. Dead links and orphaned components. Handoff happens, then you tweak the file post-handoff without telling anyone. The engineer builds from a version that no longer matches what you approved. Now QA finds ten "bugs" that are actually just an out-of-sync source of truth. None of these are about design taste. They're about respecting that someone else has to turn your intent into working code without you standing next to them. Fix all three and the same engineers who used to escalate every gap will start tagging you to review their work instead of avoiding you. That's the real signal you've closed the gap.

Six months ago I added four AI tools to my workflow. Today I actively use one. What stuck: AI-assisted layout generation for first-draft explorations. When I'm staring at a blank canvas for a new feature, generating six rough directions in ten minutes beats staring at a blank canvas for thirty. I never ship the output — I steal one idea from each and redesign properly. It's a brainstorming partner, not a designer. What got abandoned: — AI copy suggestions for microcopy. Consistently generic, needed more editing than writing from scratch would have taken. — Auto-generated component variants. Technically correct, contextually wrong — didn't understand our actual design system constraints. — "AI critique" plugins that flag accessibility and contrast issues. Useful exactly once, as a checklist reminder. After that, I just knew the checklist. The pattern: AI is strong at volume and breadth, weak at judgment and context. It's excellent when the job is "give me twenty options fast" and useless when the job is "tell me which option is right for this specific client, this specific user base, this specific constraint." Nobody at my company got faster at the actual craft because of AI tools. Some of us got faster at the boring 20% before the craft starts. That's a real win. It's just a smaller one than the hype promised. What's actually stuck in your workflow, six months in?

Every design crit at my company follows the same five-part agenda. We haven't skipped a step in over a year, even when we're behind schedule. 1. Silent review, five minutes. Everyone looks at the work before anyone talks. No exceptions — talking first anchors the whole room to the loudest opinion. 2. Presenter states the problem, not the solution. "Here's what we're solving for" before "here's what I made." If the room doesn't agree on the problem, critiquing the solution is pointless. 3. Questions before opinions. "What were you trying to do here" comes before "I think this should be blue." This single rule cuts unhelpful feedback by more than half. 4. One banned phrase: "I don't like it." You can say what's not working and why. You cannot submit a preference as if it were a finding. 5. Presenter states what they're taking away, out loud, before the meeting ends. Not what the room decided — what they personally heard and plan to act on. The ritual isn't about being precious. It's that unstructured crit reliably degrades into whoever's most senior stating preferences and everyone else nodding. Structure is what makes crit about the work instead of about the room's hierarchy. What's the one rule your crit couldn't survive without?

I used to open Figma first and think second. Now I don't touch the canvas until I've answered seven questions on paper. 1. Who is the user, specifically? Not "our users" — the actual persona, the actual context they're in. 2. What does failure look like for them right now? The current pain, in their words if I have research, in my best guess if I don't. 3. What already exists that solves part of this? Competitors, our own product, even a spreadsheet workaround someone built. 4. What's the smallest version of this that would still be useful? Not the full vision — the useful sliver. 5. What constraint will kill this if I ignore it? Engineering timeline, a legal requirement, a platform limitation. 6. How will we know if this worked? The metric, defined before the design, not reverse-engineered after. 7. What am I assuming that I haven't validated? The riskiest guess in the whole plan. Fifteen minutes with these questions has saved me from more bad first drafts than any amount of extra polish ever could. The interfaces I regret weren't badly drawn — they were answers to questions I never actually asked. Try it before your next project. Fifteen minutes, seven questions, zero pixels.

Genuine question for the room: what's the UX deliverable that gets made out of habit, not because anyone uses it? My nominee: the 80-page research report that gets delivered, thanked for, and never opened again. I've written them. I've watched stakeholders skim the executive summary and file the rest. All that synthesis work, and the actual influence came from a two-minute highlight reel I made almost as an afterthought. Runner-up: personas built once during a kickoff workshop, printed, taped to a wall, and never updated or referenced again in an actual design decision eighteen months later. I'm not saying research or personas are worthless — the thinking behind them matters. I'm saying the artifact format we default to often exists because it's what a template said a UX deliverable looks like, not because it's what actually changes a decision. What I've started doing instead: shorter, decision-linked outputs. A one-page brief tied to a specific upcoming choice. A three-minute clip reel timed to land right before a roadmap meeting. Less impressive-looking. Dramatically more used. Your turn — what's the deliverable you keep making that you suspect nobody opens?