That era is over.

The European Accessibility Act came into effect June 28, 2025. What was best practice is now a legal requirement. And with fines reaching €3 million and potential market bans for non-compliance, the conversation has moved from “we should do this” to “we have to do this before someone comes looking.”

Most teams are not ready. This issue is about what that means and what to do about it.

In This Issue:

• What actually changed and why it matters now

• What the law requires in plain terms

• Where most UX teams currently stand

• What this means for designers specifically

• What this means for researchers specifically

• How to start without overhauling everything at once

• Resource Corner

What Actually Changed And Why It Matters Now

The European Accessibility Act went into effect June 28, 2025, with full compliance required by 2030. Similar laws are progressing in the US through ADA digital updates, and in Australia, Canada, India, and Brazil. Medium

This is not a European problem for European companies. Any product that serves European users falls under its scope. And the direction of travel globally is unmistakable. Digital accessibility is moving from a voluntary standard to a legal obligation across most major markets simultaneously.

Designing accessible experiences is now a legal requirement rather than an option. The shift is significant because the consequences are no longer reputational. They are financial and operational. A product that fails accessibility compliance is now a business risk in a way it was not two years ago. Slickplan

The timing also matters. 53% of UX practitioners expect AI-powered accessibility tools to have a major impact in 2026, suggesting that AI might finally help make accessibility the default rather than an afterthought. The tools are getting better. The legal pressure is getting real. There has never been a better-resourced or more urgent moment to take this seriously. everyday ux

October 8 - where will you be?

Because the best UX professionals in the world already know the answer.

UXCON26 is the one day every year where design teams leave with clarity, new skills, and the kind of connections that actually change careers.

Talks, workshops, and conversations with the people shaping the future of product design. All in one room. One day only.

Secure your spot!

What The Law Requires In Plain Terms

The technical standard underpinning most accessibility legislation is WCAG, the Web Content Accessibility Guidelines. The current version is WCAG 2.2. Most legislation requires at minimum Level AA compliance.

What that means practically:

→ Perceivable: Information must be presentable to users in ways they can perceive. This includes text alternatives for non-text content, captions for video, sufficient color contrast, and content that does not rely solely on color to convey meaning.

→ Operable: Users must be able to operate the interface. Keyboard navigation for all functionality. No content that flashes more than three times per second. Clear focus states that are visible without a mouse.

→ Understandable: Content and interfaces must be understandable. Readable text, predictable navigation, clear error identification and suggestions when users make mistakes in forms.

→ Robust: Content must be robust enough to be reliably interpreted by assistive technologies including screen readers, voice control software, and switch access devices.

Non-compliance means fines up to €3 million and potential market bans. Beyond the financial risk, the more immediate practical reality is that if your product cannot be used by people with disabilities, you are excluding a significant portion of your potential users by design. Medium

Where Most UX Teams Currently Stand

Honest assessment: most teams are behind.

Accessibility audits get deprioritized. Automated testing catches roughly 30% of issues. The rest require manual testing with actual assistive technologies that most teams have never used in a structured way. Designers are often building on component libraries that were never audited for accessibility. Researchers are rarely recruiting participants who use assistive technology.

What used to be considered best practice is now becoming legally required, and many teams are operating without the infrastructure to meet that bar. Smashing Magazine

The gap between where most teams are and where the law requires them to be is real. But it is also closeable. The teams making progress are not the ones trying to fix everything simultaneously. They are the ones who started somewhere specific and built momentum.

What This Means For Designers Specifically

Accessibility is not a final-stage audit. It is a design decision made at every step.

🔵 Color and contrast are not aesthetic choices anymore WCAG 2.2 requires a contrast ratio of at least 4.5:1 for normal text. Designing a color system without checking contrast is designing something that will fail the audit and potentially the law. Figma plugins like Stark and A11y Color Contrast Checker make this checkable in seconds. There is no good reason not to do it from the start.

🔵 Focus states are a design element, not an engineering afterthought Every interactive element needs a visible focus indicator. WCAG 2.2 requires that the focus indicator encloses the focused component or meets minimum size requirements. If your designs do not specify focus states, engineering will either invent them or skip them. Either way you have lost control of a critical part of the experience for keyboard and switch access users. Slickplan

🔵 Touch targets have a minimum size WCAG 2.2 introduced a new success criterion requiring touch targets to be at least 24x24 CSS pixels. Small tap targets are one of the most common and most easily preventable accessibility failures in mobile design.

🔵 Error messages need to tell users what to do, not just what went wrong “Invalid input” is not an accessible error message. “Please enter a phone number in the format 07911 123456” is. The difference is not just better UX. It is a WCAG requirement.

What This Means For Researchers Specifically

Accessibility research is one of the most consistently underdone practices in the field. Most usability testing recruits participants who do not use assistive technology. Most research questions do not include participants with disabilities. This produces a fundamental blind spot in almost every UX team’s understanding of their product.

🔵 Recruit participants who use assistive technology Screen reader users. Voice control users. Switch access users. Keyboard-only navigators. These are not edge cases. They are a significant user population who interact with digital products in ways that reveal failures invisible in standard usability testing. If your research never includes them, your findings are incomplete.

🔵 Accessibility is a research question, not just a design requirement What do users with disabilities actually need from this product? Where do they encounter friction that sighted, able-bodied users do not? What workarounds have they built because the product does not accommodate them? These are researchable questions with answers that should shape product decisions. They rarely get asked.

🔵 Disability disclosure in recruitment needs care Recruiting participants with disabilities requires thoughtfulness about how you ask, how you frame the sessions, and how you accommodate different needs in the research environment. This is not optional sensitivity. It is methodological rigour. Research conducted in ways that exclude or burden participants with disabilities is not accessible research.

How To Start Without Overhauling Everything At Once

The teams making real progress on accessibility are not treating it as a separate workstream that runs alongside everything else. They are embedding it into existing processes.

✓ Run an accessibility audit on your highest-traffic flows first Not everything at once. The login flow. The checkout. The primary navigation. The places where the most users encounter the product. Automated tools like axe DevTools and Lighthouse will surface the issues that automated testing can catch. Manual testing with a screen reader will surface the rest. Start with the flows that matter most.

✓ Add accessibility criteria to your definition of done A feature that is not keyboard navigable is not done. A design that has not been checked for color contrast is not ready for handoff. Making accessibility criteria explicit in your team’s definition of ready and done means it stops being an afterthought and starts being a requirement at the point where it is cheapest to fix.

✓ Include one accessibility-related question in your next research study Not a dedicated accessibility study. Just one question, or one task, that reveals something about how your product works for users with different needs. Start building that knowledge base gradually rather than waiting for a large dedicated effort that may never get prioritized.

✓ Get familiar with a screen reader VoiceOver on Mac and iOS. NVDA on Windows. Both are free. Spending one hour navigating your own product with a screen reader will teach you more about its accessibility gaps than any audit document. It is also the fastest way to build genuine empathy for what the experience is like for users who depend on it.

THIS WEEK’S JOB FIND 🔍

Allegis Group is growing their UX Research team and looking for a Senior / Team Lead UX Researcher in Hanover, MD.

If you have experience leading research strategy, shaping discovery, and working closely with Product, Design, Architecture, and Business to influence outcomes, this one’s worth a look.

The role includes: → Leading end-to-end UX research across enterprise-level initiatives → Driving early discovery to help teams make informed decisions before build → Partnering with cross-functional stakeholders to align user needs with business goals → Mentoring researchers and elevating research practices across the org

Apply Here!

📦 Resource Corner

WebAIM The most practical, no-jargon resource for understanding accessibility requirements. Their contrast checker and screen reader guides are used daily by practitioners who take this seriously.

Stark Figma plugin that checks color contrast, simulates color blindness, and audits focus order directly in your design files. The fastest way to catch accessibility issues before they reach engineering.

axe DevTools The browser extension used by most accessibility specialists for manual auditing. Free version catches the automated issues. Pair it with manual screen reader testing for a complete picture.

European Accessibility Act Summary The actual legislation, summarized. Worth understanding directly rather than through secondhand summaries if your product serves European users.

Inclusive Design Principles Seven principles for designing for human diversity. More useful as a daily reference than a one-time read. Bookmark it.

Accessibility for UX Researchers (UX Design Institute) Specifically about how to conduct research that includes participants with disabilities. Covers recruitment, session design, and analysis considerations.

💭 Final Thought

Accessibility was always the right thing to do. That argument, on its own, was not moving the needle fast enough for most organizations.

Now there is a different argument available. It is a legal requirement in a growing number of markets. Non-compliance carries real financial consequences. And the population of users who depend on accessible design is large enough that ignoring them was never a good business decision, even before the law got involved.

What is different in 2026 is the focus on infrastructure. Design is less about visible novelty and more about systemic intelligence, making complexity understandable and experiences genuinely usable for everyone. Smashing Magazine

Accessibility is not a constraint on good design. It almost always makes the experience better for everyone. Clearer error messages help all users. Better color contrast is easier to read in sunlight. Keyboard navigation helps power users who never touch a mouse. Designing for the edges improves the center.

The law caught up with what good UX always required. Now there are fewer excuses and more reasons than ever to build it in from the start.

--- The UXU Team

Most researchers have not stopped to consider which one they are actually doing.

Leo Hoar, PhD has. And what he has found is not reassuring.

Every research decision you make sits on top of a layer of smaller decisions you are barely aware of. Which questions to ask. Which signals deserve your attention. Which gaps are worth chasing and which ones you can afford to leave alone. These micro-decisions shape everything that comes after them. And right now, a lot of researchers are quietly outsourcing them to AI without realising it.

That is not a workflow problem. That is a thinking problem.

And he’s unpacking all of it at UXCON26.

Join Leo Hoar, PhD at UXCON26

Bad research does not fail loudly. It drifts. By the time the insight lands wrong, or the product ships something that should never have made it through, the error is already weeks behind you. The moment it could have been caught has passed.

Leo has worked at this intersection for a long time. From Samsung to founding UXR Institute, because he looked at where the industry was headed and decided the education it needed did not yet exist. He is not theorising about this. He has watched it happen to experienced teams, senior researchers, people who should have known to slow down and did not.

At UXCON26, he is running a full workshop on exactly this. Not a talk. Not a panel. A proper working session where you will examine how AI is reshaping the research process, where the real risks live, and what rigorous practice actually looks like when AI is in the room.

October 8th. Silver Spring Civic Center, Maryland.

One day. Real work. The kind of questions this industry needs to sit with.

Join Leo Hoar, PhD at UXCON26

Most of them are not sure if the outputs they are getting are any good.

Using a tool and using it well are two completely different things. And right now, the gap between those two things is producing a lot of confident work built on shaky foundations. This issue is about that gap, why it matters specifically for UX, and what AI literacy actually looks like in practice.

In this issue:

In This Issue, we’ll cover:

• Why using AI is not the same as understanding it

• What bad AI use looks like in UX specifically

• What AI literacy actually means for practitioners

• The questions worth asking before you trust any output

• How to build this skill without starting from scratch

• Resources to help shape your understanding in AI

Why Using AI Is Not The Same As Understanding It

Every UX practitioner knows the difference between a user who can operate a product and a user who actually understands it.

One clicks through.

The other knows why things work, notices when something is off, and adapts when the expected path breaks.

Right now, most practitioners are the first kind of user when it comes to AI.

Designers who understand how AI tools work can make better decisions about when and how to use them, while still applying strong UX fundamentals. That understanding is the part most people are skipping. They are adopting the tools without interrogating the outputs.

The value of AI in research is entirely dependent on the quality of the human judgment surrounding it. Which means the field’s most urgent project is not learning to use the tools. It is being honest about what human judgment in research actually consists of. Lyssna

What Bad AI Use Looks Like In UX Specifically

It does not usually look like an obvious mistake. It looks like a small confidence that should not be there.

🔴 Synthesis that skips the hard part

AI is genuinely fast at pulling themes from interview transcripts. It is also genuinely bad at knowing which themes matter. AI averages where research needs to differentiate. It finds what shows up most. It does not find what is most significant. A researcher who hands synthesis entirely to AI and presents the output as findings is presenting a statistical summary, not insight. Lyssna

🔴 Outputs mistaken for conclusions

AI cannot accurately prioritize research questions or determine appropriate methods. It can suggest. It can generate. It can produce something that looks like a research plan or a set of interview questions or an analysis framework. But it does not know your specific users, your product context, or what actually matters in this study. Using AI output as a starting point is smart. Treating it as a conclusion skips the part where a practitioner actually thinks. LinkedIn

🔴 Bias going undetected

AI outputs skew toward what the user wants to hear: optimistic, agreeable, unchallenging. If you prompt an AI to analyze research and it tells you users love the concept, that output is shaped by how you asked as much as by what the data actually says. Practitioners who do not know this are not catching it. And uncaught bias in research shapes product decisions in ways nobody traces back to the AI prompt that started it. Lyssna

🔴 Old insights recycled at scale

AI tools learning from organizational repositories will automatically propagate outdated insights at scale. If your research repository is full of studies from two years ago and your AI synthesis tool is pulling from it, you are producing fast, confident, stale insight. Speed without accuracy is not an improvement. Lyssna

Quick interruption. This one is for you.

🎯 Not sure where you fit right now? This workshop was built for that moment.

If you have been laid off, watching your field shift, or applying and hearing nothing back, this is not a lecture about what you should have done differently. It is 4 practical hours of working on your actual stuff. Your resume, your pitch, your positioning in a market that keeps moving.

No theory. You leave with something finished and one clear next step.

📅 July 23, 2025 · 12:00 to 4:00 PM 📍 Silver Spring Civic Building, Silver Spring, MD

RSVP HERE!

What AI Literacy Actually Means For Practitioners

✅ Knowing what the tool is actually doing

Not at an engineering level. At a practical level. AI language models predict likely next words based on patterns in training data. They do not reason. They do not verify. They do not know when they are wrong. Knowing this changes how you read every output they produce.

✅ Treating outputs as drafts, not answers

Always review AI outputs. Use them as drafts or hypotheses rather than final answers. This sounds obvious. It is not practiced consistently. The speed of AI output creates a psychological pull toward acceptance. Literacy means resisting that pull by default. LinkedIn

✅ Prompting with context, not just instructions

Provide context and constraints in your prompts. Specify the user segment, product maturity, and research goal. Break big tasks into smaller, modular prompts. A vague prompt produces a vague output that looks specific. A well-constructed prompt that includes real context produces something you can actually work with. LinkedIn

✅ Keeping a human at the center of every AI-assisted workflow

The question worth asking honestly is whether the infrastructure exists to protect and develop human judgment in research, not just accelerate the parts AI can handle. Literacy means knowing where in the process your judgment is irreplaceable and protecting that space, even when the AI could technically fill it. Lyssna

The Questions Worth Asking Before You Trust Any Output

Before using AI-generated content in your work, run it through these:

→ Does this reflect the actual context of my users or a generalized version?
→ What would this output look like if my prompt had been slightly different?
→ Am I agreeing with this because it is accurate or because it sounds confident?
→ Who is accountable for this output if it turns out to be wrong?
→ What would I need to verify before I present this to a stakeholder?

None of these questions take long. Together they change the quality of everything you produce with AI assistance. Maintaining an audit trail of AI-generated and human-edited content and labeling what was machine-produced is not just an ethical practice. It is how you stay honest with yourself about where your judgment ends and the tool’s output begins. LinkedIn

How To Build This Skill Without Starting From Scratch

AI literacy does not require becoming technical. It requires becoming deliberate.

✓ Start with one tool and go deep Most practitioners are dabbling across many tools. Pick one you use most, read about how it actually works, and develop real intuition for where it is reliable and where it breaks down. Depth with one tool teaches you more than surface exposure to ten.

✓ Make verification a habit before it becomes a crisis Every time an AI output surprises you, pleasantly or otherwise, investigate why. That investigation builds the intuition that catches problems before they reach a stakeholder presentation.

✓ Talk to other practitioners about what is not working The questions UX leaders are fielding right now are less about what tools to use and more about how to adapt, how to evolve research practices and ensure AI becomes an accelerator rather than an obstacle. The most useful conversations happening in the field right now are the honest ones about where AI is failing, not just where it is impressive. Index.dev

✓ Apply your own UX skills to how you use AI You already know how to observe behavior, identify friction, and design around constraints. Apply that to your own AI workflow. Where does it break down? Where do you reach for it out of habit rather than genuine usefulness? Where is it saving time on the right things versus the wrong ones?

📦 Resource Corner

Maze Future of User Research Report 2026 The most comprehensive data available on how research teams are actually using AI right now. Particularly useful on the gap between adoption rates and confidence in outputs.

AI for UX Research: What Actually Works in 2026 (Great Question) A five-part series written by practitioners for practitioners. Honest about what AI does well and where it falls apart in a research context.

HEARTS Framework (UXinsight) A practical audit for checking whether an AI-assisted workflow still has a human at its center. Human-led, Experience-focused, Amplification not Automation, Rigorous and Responsible, Trustworthy and Transparent, Safe and Sustainable. Worth bookmarking.

How to Use AI for UX Research (Parallel HQ) Practical walkthrough of the research lifecycle showing specifically where AI adds value and where human judgment cannot be substituted. Good on prompt construction.

AI Fundamentals for UX (UX Design Institute) If you want structured learning rather than self-directed exploration, this is the most relevant course available for UX practitioners building practical AI literacy.

💭 Final Thought

The field does not have an AI adoption problem. It has an AI literacy problem.

Getting to 93% adoption is impressive. But adoption without understanding produces something that looks like progress and functions like risk. Confident outputs from poorly constructed prompts. Synthesis that skips interpretation. Bias that nobody caught because nobody knew to look.

The practitioners who will get the most from AI in 2026 are not the ones using the most tools. They are the ones who understand what the tools are actually doing well enough to know when to trust them and when to push back.

That skepticism is not resistance to AI. It is exactly the kind of critical thinking this field has always been built on. Apply it to the tools the same way you apply it to everything else.

--- The UXU Team

One is about how your users are actually navigating information right now, which is probably not what you are designing for. The other is about how UX teams learn from what they ship, which most teams are either skipping or doing badly enough that it does not matter.

Both are about the same underlying thing: using the right tool for the right problem.

In This Issue, We’ll Cover:

• GenAI vs. search: what users are actually doing

• What this means for how you design

• Project postmortems: why most teams skip them or do them badly

• What a good postmortem actually looks like

• How both topics connect

• Resource Corner

A note before we dive in

“Before we get into it...”

Happy Memorial Day 🇺🇸

Today we pause to honor the men and women who gave everything so we could keep building, creating, and connecting. It’s a day worth slowing down for - a moment of gratitude before we jump back into the work we love.

In that spirit, we’re passing along a little something to you. Click the link below to save on your tickets

Claim discount

GenAI vs. Search: What Users Are Actually Doing

The story being told in most headlines is wrong.

AI is not replacing search. Users are not abandoning Google for ChatGPT. What is actually happening is more interesting and more relevant to how you design information experiences.

ChatGPT adoption does not reduce Google usage. It expands overall information-seeking behavior. Users are searching more overall, not simply shifting between platforms. Imidef

Users are developing sophisticated mental models about which tool fits which need. And the split is consistent enough to be designed around. Nielsen Norman Group

✅ People reach for GenAI when:

→ The question is complex or multi-part and requires synthesis across maUXCON26

ny sources → They are starting from a vague place and do not know exactly what to search for
→ The task involves ideation, content creation, or complex problem-solving that benefits from conversational interaction
→ They want a summarized answer without clicking through multiple pages Nielsen Norman Group

✅ People reach for traditional search when:

→ Accuracy is critical and they need to verify the source
→ They want control over where the information comes from
→ The stakes of getting it wrong are high
→ The query is transactional or navigational, where familiar formats and trusted sources matter more Nielsen Norman Group

42% of people now prefer using AI chatbots over search engines for multi-step research. But that same group is still opening Google when they need to verify something specific. These are not competing loyalties. They are complementary behaviors triggered by different kinds of need. UX Design

What This Means For How You Design

If you are designing any experience that involves information retrieval, decision-making, or research, this data should change your assumptions.

🔵 Your users are task-switching, not platform-loyal

Consumers do not delete old behaviors. They stack new ones on top. AI is creating new types of information-seeking behavior that did not exist three years ago: multi-turn research conversations, real-time synthesis of multiple sources, task completion inside a single interface. These coexist with traditional search rather than replacing it. Uxuniversity

Designing as if your users arrive with a clear, formed query is designing for a behavior that is increasingly rare. Many of them are arriving in exploration mode, using conversational tools to figure out what they are even looking for before they come to you.

🔵 Exploration and verification are different modes with different needs

When users are exploring, they want synthesis, flexibility, and low friction. When they are verifying, they want sources, dates, authors, and transparency about where the information comes from. These are not the same experience. A product that collapses both into one interaction is likely underserving both.

🔵 Trust signals matter more now, not less

As AI-generated content becomes more prevalent, the traditional search format, with its multiple perspectives and familiar integrations, continues to inspire greater trust for high-stakes decisions. Users are getting more deliberate about when they trust an AI summary and when they want to trace information back to a source. Designing clear trust signals into your information experiences is not a nice-to-have. It is a response to a real behavioral shift. Nielsen Norman Group

🔵 This is a research question worth investigating in your specific context

General data gives you a direction. It does not tell you where your specific users sit on the exploration-to-verification spectrum or at what point in their journey they switch modes. That is worth a study. Session recordings, interview questions about how people arrived at your product, and usability testing that starts before the product opens are all ways to surface this in your specific context.

Project Postmortems: Why Most Teams Skip Them Or Do Them Badly

Staying on the theme of using the right tool for the right problem: after a project ends, the right tool is a postmortem. Most teams either do not use it at all or use it so poorly it produces nothing actionable.

A postmortem is a structured analysis of a completed project that asks three questions. What happened? Why did it happen? What do we change because of it?

The first misconception worth clearing up: postmortems are not just for failures. You should absolutely run one when your new onboarding flow tanks, but you should also run one when your redesigned checkout process works. Success often teaches us more than failure, but only if we actually interrogate it. Baymard

The teams skipping postmortems entirely are leaving institutional knowledge on the table. The teams running them badly are doing something arguably worse: creating the feeling of learning without any of the actual change.

Here is what makes most postmortems useless:

🔴 Running them too late Memory fades within days. Emotional context evaporates. A postmortem run six weeks after a launch is reconstructing history, not examining it. Schedule it within two weeks of completion. One week is better.

🔴 Blame dressed up as analysis The best postmortems reveal that incidents were caused by decisions that seemed reasonable at the time but turned out to be wrong. Getting there requires an environment where people can say that without consequence. If the culture does not support that, the postmortem becomes a performance rather than a practice. Phygital+

🔴 Lessons that go nowhere A postmortem report sitting in a shared drive nobody opens is not a learning system. It is a filing system. Every lesson needs to be linked to specific types of deliverables, checklists, and knowledge systems that people actually reach for on the next project. If the insight does not change a template, a process, or a default decision, it did not actually land. Superhuman

🔴 Only looking at what went wrong Identifying what worked effectively matters just as much. Postmortems that only examine failure miss the opportunity to understand what to deliberately repeat. TechCrunch

What A Good Postmortem Actually Looks Like

✓ Set the scope before anyone walks into the room

What project? What time period? What decisions are in scope? Without clear boundaries, postmortems drift into unfocused venting. Put the scope in the calendar invite.

✓ Start with facts, not interpretations

What happened, in sequence, as a matter of record? Get everyone aligned on the timeline before anyone starts explaining why. This prevents the meeting from becoming a competition between narratives.

✓ Ask the question most teams skip

What would we have needed to know earlier to make a better decision? This surfaces the real systemic gaps: the research that was missing, the brief that was unclear, the stakeholder misalignment that caused a problem two months before the problem showed up visibly. Fixing those is worth far more than fixing the symptom.

✓ End with owners, not intentions

Every action item needs one person accountable and one deadline. Not “the team will consider this going forward.” One person, one date, one specific change. Intentions without owners are wishes.

✓ Feed the findings back into the system

Link every lesson to specific deliverables so teams can retrieve relevant lessons when working on similar tasks in future. A postmortem that changes a research brief template or adds a question to a stakeholder kick-off checklist has actually changed something. One that produces a PDF has not. Superhuman

📦 Resource Corner

Semrush: ChatGPT Is Not Replacing Google: 260 billion rows of clickstream data on what actually happened to Google usage after people started using ChatGPT. The expansion hypothesis explained with real numbers.

How ChatGPT Is Challenging Google’s Dominance in 2026: Breakdown of query types and which platform wins each one. Useful for understanding exactly where the split happens between exploration and verification behavior.

Post-Mortem Meetings: How to Run Them Effectively: Practical guide on running the meeting itself, including how to build the psychological safety that makes honest postmortems possible rather than performative ones.

Blameless Postmortem Guide and Free Checklist: Step by step walkthrough covering before, during, and after. The free checklist is worth downloading before your next project wraps up.

Dovetail If you want postmortem findings to actually be findable and usable on the next project, this is the most purpose-built place to store them. Institutional knowledge needs a home to be worth anything.

💭 Final Thought

Both topics this issue are about the same thing: knowing which tool fits which problem and actually learning from what happens when you get it wrong.

Your users have already figured out the first part. They are switching between AI and search based on what each task actually requires, without overthinking it. The design implication is to stop assuming they arrive at your product in one mode and start designing for the reality that they arrive in several.

Your team is still figuring out the second part. Most UX teams are not running postmortems consistently. The ones that are, are often doing it in a way that produces documentation instead of change. The gap between a team that learns from every project and one that does not compounds over time in ways that are hard to see until they are obvious.

Run the postmortem. Actually close the loop. Use the right tool for the right moment.

--- The UXU Team

“Team player with strong communication skills”
“Collaborative designer who works well with cross-functional teams”
“Passionate about creating user-centered experiences”

Hiring managers see this hundreds of times per role. It means nothing. Worse than nothing, actually, because it takes up space where you could be saying something that actually differentiates you.

Here’s what’s happening: everyone’s trying so hard to sound hireable that they’ve all started sounding identical. And in a market where 200+ people apply for every open role, identical gets ignored.

What we’re covering:

• Why “team player” language is a red flag, not a strength

• The phrases hiring managers immediately skip over

• What actually makes someone memorable in applications

• How to show collaboration without saying “collaborative”

• What to say instead when you have nothing specific to point to

The words that make hiring managers stop reading

Let’s be specific about what kills your resume the moment a hiring manager sees it:

❌ “Team player”

Translation: “I don’t have anything specific to say about my actual contribution, so here’s a generic trait everyone claims.”

Every single person applying to this role says they’re a team player. You’re not differentiating. You’re blending in.

❌ “Strong communication skills”

Translation: “I can speak and write, which is the baseline expectation for any professional job.”

This is like saying “shows up on time” or “uses a computer.” It’s assumed. Saying it out loud makes you sound junior.

❌ “Passionate about user experience”

Translation: “I’m applying for a UX role and I’m supposed to care about UX, so here’s the mandatory statement.”

Passion is demonstrated through work, not declared through adjectives. Saying you’re passionate without showing it is meaningless.

❌ “Detail-oriented”

Translation: “I don’t make obvious mistakes, which again, is baseline expectation.”

Everyone claims this. It’s unverifiable. It fills space without adding information.

❌ “Creative problem-solver”

Translation: “I solve problems, which is literally the job description for design.”

This is so generic it could apply to any role in any industry. It says nothing about what makes you different.

❌ “Works well under pressure”

Translation: “I don’t completely fall apart when things get stressful.”

Again, baseline expectation. Not a differentiator.

❌ “Self-starter who takes initiative”

Translation: “I do my job without needing constant supervision, which you definitely expect at this level.”

If this is your selling point, you’re admitting you have no actual accomplishments to highlight.

The pattern:

All of these phrases are traits, not evidence.

They’re adjectives describing how you see yourself, not specific examples of what you’ve actually done.

Hiring managers don’t care how you describe yourself. They care what you’ve delivered and how you work.

When your resume is full of traits and empty of specifics, you sound inexperienced or like you’re hiding a lack of real accomplishments.

Reality check: If you deleted every generic trait from your resume and it became 30% shorter, your resume was 30% fluff.

What hiring managers actually want to see

Instead of traits, show evidence:

Instead of: “Collaborative team player”

Write: “Partnered with PM and 3 engineers to ship checkout redesign that reduced abandonment from 68% to 34% in 8 weeks”

Why it’s better:

• Shows who you worked with (PM, engineers)

• Shows what you delivered (checkout redesign)

• Shows measurable impact (abandonment rate)

• Shows timeline (8 weeks)

That’s collaboration demonstrated through outcomes, not claimed through adjectives.

Instead of: “Strong communication skills”

Write: “Presented research findings to C-suite, resulting in 6-month roadmap pivot and $200K budget reallocation to user-facing features”

Why it’s better:

• Shows you communicated to senior leadership (C-suite)

• Shows your communication had impact (roadmap pivot, budget shift)

• Shows scale ($200K)

Your communication skills are proven through what happened as a result, not stated as a trait.

Instead of: “Passionate about user experience”

Write: “Initiated and led quarterly usability testing program that identified 12 high-priority issues across 3 products, 8 of which were fixed within 2 sprints”

Why it’s better:

• Shows you created something that didn’t exist (initiated program)

• Shows consistency (quarterly)

• Shows impact (identified issues, got them fixed)

• Shows initiative (you started this, it wasn’t assigned)

That’s passion demonstrated through action, not claimed through words.

Instead of: “Detail-oriented designer”

Write: “Established component library documentation system that reduced design-to-dev handoff errors by 40% and saved team 5 hours/week”

Why it’s better:

• Shows what you built (documentation system)

• Shows measurable improvement (40% error reduction)

• Shows efficiency gain (5 hours/week)

Your attention to detail is proven by the system you created, not stated as a personality trait.

Instead of: “Creative problem-solver”

Write: “Redesigned complex B2B workflow that reduced 12-step process to 4 steps while maintaining compliance requirements, resulting in 60% faster task completion”

Why it’s better:

• Shows specific problem (12-step process)

• Shows constraint (compliance)

• Shows solution (reduced to 4 steps)

• Shows outcome (60% faster)

Your problem-solving is proven through what you solved, not claimed as an attribute.

The shift:

Stop describing yourself. Start showing what you’ve done.

Traits are claims. Outcomes are evidence. Evidence is what gets you hired.

How to show value when you’re early in your career

“But I don’t have big outcomes yet. I’m junior. What do I say?”

Fair question. Here’s how to write a compelling resume even without senior-level impact:

→ Focus on contribution, not outcome

Weak: “Team player on redesign project”

Strong: “Conducted 8 user interviews and synthesized findings into 3 key insights that informed navigation redesign direction”

You might not own the final outcome, but you can own your specific contribution.

→ Highlight process quality and learning

Weak: “Detail-oriented designer”

Strong: “Iterated through 5 wireframe versions based on usability testing feedback, shipping final design that scored 8.5/10 on SUS scale”

Shows you know how to work through a process and measure results, even on smaller projects.

→ Point to things you initiated

Weak: “Self-starter who takes initiative”

Strong: “Created weekly design critique practice for team of 4 designers, increasing feedback frequency from monthly to weekly”

Starting something, even small, shows initiative better than claiming initiative.

→ Show technical skills through usage

Weak: “Proficient in Figma and design tools”

Strong: “Built component library in Figma with 40+ documented components used across 3 product teams”

Don’t list skills. Show how you applied them to build something real.

→ Include relevant side projects or spec work

Weak: “Passionate about accessibility”

Strong: “Redesigned local nonprofit website to meet WCAG 2.1 AA standards, improving accessibility score from 68 to 94”

Real work, even unpaid, beats empty claims about passion.

The principle:

Even without senior-level impact, you can show what you built, learned, or initiated.

You just have to get specific instead of hiding behind generic traits.

What to do right now

Take 20 minutes and audit your resume:

Step 1: Highlight every generic trait

Find every instance of:

• Team player

• Strong communication

• Passionate

• Detail-oriented

• Creative

• Self-starter

• Any other adjective that describes personality

Step 2: Delete them all

Yes, all of them. Your resume just got shorter. That’s good.

Step 3: Replace with evidence

For every trait you deleted, write one specific example of work that demonstrates that trait through outcomes.

Format: “[Action verb] [specific thing] that [measurable result]”

Examples:

• Led [project] that [outcome]

• Built [system] that [impact]

• Redesigned [feature] resulting in [metric]

• Conducted [research] that informed [decision]

Step 4: Add numbers everywhere possible

How many users? How much time? How many interviews? What percentage? How much money?

Numbers make vague contributions concrete.

Step 5: Read it out loud

If it sounds like it could be anyone’s resume, keep revising.

If it sounds like specific things you actually did, you’re getting close.

The test:

Could someone else copy-paste your resume and claim it as their own work?

If yes, it’s too generic. Get more specific.

If no, because the work is clearly yours and nobody else’s, you’ve got it.

🎯 Your Next Move: A 4-Hour Reality Check That Actually Helps

Look, you can read another article about AI and upskilling and feel motivated for 20 minutes before going back to scrolling LinkedIn and wondering why your applications go nowhere.

Or you can spend four hours in a room with people who are actually doing something about it.

July 23, 2025 · 12:00–4:00 PM Silver Spring Civic Building at Veterans Plaza 1 Veterans Pl, Silver Spring, MD 20910

RSVP HERE!

This isn’t a talk. You’re not sitting there listening to someone pontificate about the future of work. You’re working, on your actual resume, your actual positioning, your actual next move, with AI tools, with real feedback, with people who do this professionally.

You walk in unclear. You walk out with something finished. A resume that’s actually competitive. A pitch that lands. A clearer sense of where you fit in this new economy.

No jargon. No theory. No “10 trends to watch in 2026.” Just practical work on your real stuff with people who are serious about their next move.

RSVP HERE!

📦 Quick Resources

Indeed Resume Guide
Practical examples of showing impact vs stating traits.

Harvard Resume Guide
Action verb lists and accomplishment statement formulas.

Google XYZ Formula
“Accomplished [X] as measured by [Y] by doing [Z]” - simple structure that works.

💭 Final Thought

Being a team player isn’t bad. Having communication skills isn’t bad. Being passionate isn’t bad.

But saying these things on your resume is bad. Because everyone says them. And when everyone says the same thing, no one stands out.

Hiring managers reviewing 200 applications don’t have time for generic traits. They’re scanning for evidence of real work, real impact, real thinking.

Your resume has maybe 30 seconds to prove you’re worth interviewing. Every generic phrase wastes those seconds saying nothing.

Show, don’t tell. Specifics over adjectives. Evidence over claims.

Then maybe you’ll actually get a callback.

— The UXU Team

Not in how they use it. In where they shouldn’t.

Leo Hoar, PhD calls this the difference between using AI and thinking with AI. And it sounds like a small distinction until you realize what it actually means for your work.

Join Leo Hoar, PhD at UXCON26

Every research decision you make is a series of micro-decisions happening underneath the surface. Which questions to ask. Which signals to trust. Which gaps to investigate and which ones to let go. Most people hand all of that to AI without a second thought.

That’s where things start breaking. Not at the end when the insights land wrong. At the beginning, before you even knew there was a problem.

Bad research doesn’t announce itself. It compounds quietly. By the time you see it, it’s already in the product.

Leo has spent his career at the intersection of research rigour and real-world practice, from Samsung to building UXR Institute from the ground up because the advanced education this industry needed simply didn’t exist. He sees this mistake everywhere. Senior researchers. Experienced teams. People who know better.

And he’s unpacking all of it at UXCON26.

One day. October 8th. Silver Spring Civic Center, Maryland. A room full of practitioners who care enough about getting this right to show up in person and wrestle with the hard questions together.

If reading this made you uncomfortable, that’s the point. It means you need to be in that room.

Don't wait... Secure your spot

CANT WAIT? JOIN US FOR A 4-Hour Reality Check That Actually Helps

Look, you can read another article about AI and upskilling and feel motivated for 20 minutes before going back to scrolling LinkedIn and wondering why your applications go nowhere.

Or you can spend four hours in a room with people who are actually doing something about it.

July 23, 2025 · 12:00–4:00 PM Silver Spring Civic Building at Veterans Plaza 1 Veterans Pl, Silver Spring, MD 20910

RSVP HERE!

This isn’t a talk. You’re not sitting there listening to someone pontificate about the future of work. You’re working, on your actual resume, your actual positioning, your actual next move, with AI tools, with real feedback, with people who do this professionally.

You walk in unclear. You walk out with something finished. A resume that’s actually competitive. A pitch that lands. A clearer sense of where you fit in this new economy.

No theory. No “10 trends to watch in 2026.” Just practical work on your real stuff with people who are serious about their next move.

July 23, 2025 · 12:00–4:00 PM
Silver Spring Civic Building at Veterans Plaza
1 Veterans Pl, Silver Spring, MD 20910

RSVP HERE

Four hours. Real work. Real results. That’s it.

Update your resume. Quantify your impact. Tailor every application. Network authentically. Build your personal brand. Use AI tools. Stay consistent. Trust the process.

You have read all of it. You have probably done most of it. And you are still refreshing your inbox waiting for a response that is not coming.

Here is the thing nobody says out loud: the problem is almost never information. There is more career advice available right now than at any point in history. UX practitioners who are stuck are not stuck because they lack knowledge. They are stuck because something specific in their actual materials, their actual pitch, their actual positioning is not working, and reading another article does not fix a specific problem.

This issue is for the people who are done reading and ready to actually work on the thing.

In this issue:

• Why the UX job hunt feels different right now and it is not just in your head

• Where AI fits into all of this honestly

• Why articles and advice are not the bottleneck

• The specific ways AI is helping UX practitioners get hired right now

• What actually creates movement

• The one thing worth four hours of your time this month

• Resource Corner

Why the UX job hunt feels different right now

Because it is different. And not just a little.

One open UX role easily gets 1,000 or more applications. Most of those applications never reach a person. AI screening tools now filter through thousands of applications before a human ever sees them. Which means you could have genuinely strong work and a well-written resume and still get filtered out before anyone with judgment ever looks at your name. TechCrunchTechCrunch

That is not a you problem. That is a system problem. But knowing it is a system problem does not make it less exhausting to live inside.

The job market in 2026 is still competitive, especially at the junior level, where the supply of aspiring UX professionals significantly outpaces open roles. Senior roles are recovering faster. But across the board, the process is longer, more opaque, and more demoralizing than it was three years ago. Yahoo!

If you have been wondering whether you are imagining how hard this is, you are not.

Where AI fits into all of this honestly

Three years ago the UX field was loudly debating whether AI would take our jobs. It was theoretical, charged, and mostly unresolved.

Here is what actually happened.

AI did not eliminate UX. It restructured the work, raised the expectations, and quietly changed the job hunting process itself. The same technology that was supposed to be the threat became the gatekeeper between practitioners and the interview. And it also became one of the most practical tools available to anyone trying to get through that gate.

The UX practitioners who are moving through this market are not the ones with the most impressive portfolios. They are the ones using every available tool, including AI, to work on the specific things that are not landing.

Interviewers are now asking about AI directly. Having real examples of how you integrate it into your process is increasingly expected, not optional. UXPin

This is not about becoming an AI expert. It is about using what is available to close the specific gap between you and the next conversation.

Why articles and advice are not the bottleneck

Here is the honest version of why most career content, including this newsletter, has a ceiling.

Reading about what to do creates awareness. It does not create change. And the specific thing that is not working in your job search almost certainly requires someone to actually look at your stuff and tell you what is off.

Is it the resume not getting through screening? Diagnosable. Is it interviews happening but no offers? Completely different problem, completely different fix. Is it not knowing how to talk about a gap, a pivot, or a specialization that does not fit a clean narrative? Specific problem. Is it the pitch feeling flat even though the experience is strong? Also specific.

You cannot diagnose these things by reading general advice. You diagnose them by having someone who knows what they are looking for actually look at your materials and tell you the truth.

That is the real bottleneck. Not information. Honest, specific, actionable feedback on the actual thing in front of you.

The one thing worth four hours of your time…

Pause for something urgent.

🎯 Your Next Move: A 4-Hour Reality Check That Actually Helps

Look, you can read another article about AI and upskilling and feel motivated for 20 minutes before going back to scrolling LinkedIn and wondering why your applications go nowhere.

Or you can spend four hours in a room with people who are actually doing something about it.

This is not a talk. You are not sitting there listening to someone pontificate about the future of work. You are working. On your actual resume, your actual positioning, your actual next move, with AI tools, with real feedback, with people who do this professionally.

You walk in unclear. You walk out with something finished. A resume that is actually competitive. A pitch that lands. A clearer sense of where you fit in this new economy.

No jargon. No theory. No “10 trends to watch in 2026.” Just practical work on your real stuff with people who are serious about their next move.

📅 July 23, 2025 · 12:00 to 4:00 PM 📍 Silver Spring Civic Building at Veterans Plaza, 1 Veterans Pl, Silver Spring, MD 20910

RSVP HERE

Four hours. Real work. Real results. That is it.

back to where we stopped…..

The specific ways AI is helping UX practitioners get hired right now

Not in theory. In practice. Here is what is actually working.

🔵 Getting past the algorithm before a human ever sees the resume

AI screening tools scan resumes for keywords, formatting, and relevance. A resume that reads well to a person but does not mirror the exact language in the job description gets filtered before anyone sees it. Practitioners who are getting through are using AI to compare their resume against specific job descriptions, identify the gaps, and close them before applying. Tools like Jobscan do this in minutes. What used to require guessing is now diagnosable. TechCrunch

🔵 Reframing experience from activity to impact

Most UX resumes describe what the person did. The ones that land describe what changed because of what the person did. Instead of “designed new checkout experience,” something like “redesigned checkout flow that lifted conversion 25% and added $150K quarterly revenue” lands completely differently. AI can help you find that framing for your own work faster than you can alone. Paste a bullet point and ask it to rewrite it leading with the outcome. Do that across your whole resume in an hour. UXPin

🔵 Practicing the interview before it happens

The parts of an interview that go badly are almost always predictable. The vague answer about a stakeholder conflict. The stumble when asked about a project that did not go well. The moment where you know what you want to say but cannot find the words under pressure. AI lets you practice those moments specifically, get pushed on the weak parts, and arrive prepared for the version that actually matters.

🔵 Researching the role like an insider

Walking into an interview having read the company’s job description is table stakes. Walking in having used AI to map the company’s likely product challenges, understand their competitive landscape, and anticipate what problems they are trying to solve is a different conversation entirely. Hiring managers notice the difference immediately. One sounds like a candidate. The other sounds like someone who already understands the context.

🔵 Building a pitch that works for algorithms and humans

The pitch that gets you past ATS screening and the pitch that resonates with a tired hiring manager who has read forty applications today are not identical. AI can help you write both versions and understand where they need to differ. Most practitioners are optimizing for one. The ones getting responses have figured out both.

What actually creates movement

Not more applications. Fewer, more targeted ones.

Not longer case studies. Shorter ones with clearer outcomes.

Not a complete reinvention of your experience. A sharper framing of the experience you already have.

✓ Get specific about what is broken

Not “the market is hard.” The market is hard and something specific in your approach is also not working. Those are two separate problems. One you cannot control. The other you can. Start by naming the specific place where the process is breaking down. That is where to put your energy.

✓ Get your actual materials in front of someone who will tell you the truth

Not a friend who says it looks great. Someone who has seen what gets through screening, what lands in interviews, what makes a hiring manager stop scrolling. That feedback applied to your specific materials is worth more than anything you will read this week.

✓ Use AI for the actual work, not just thinking about it

Open ChatGPT right now. Paste your resume. Ask it what the weakest part is for someone applying for the specific role you are targeting. Be specific about the role. The feedback will not be perfect. It will be faster and more direct than most feedback you will get and you can act on it today.

📦 Resource Corner

Jobscan Paste your resume and a job description. Get a specific ATS compatibility score with exact gaps identified. Do this before your next application and you will understand something concrete about why response rates are low.

ChatGPT Treat it like a tireless thinking partner. Use it to rewrite bullet points, practice interview answers, research companies, and get pushed on the parts of your pitch that are vague. Ask specific questions about specific materials, not general questions about general situations.

Navigating the UX Job Hunt in 2026 by Craig Moser Written from inside the experience, not from a distance. Practical on what is actually moving the needle for people right now, including how to reach out to your network without it feeling like a transaction.

Resume Worded AI-powered resume feedback specifically built around what hiring managers and ATS systems are looking for. More targeted than a general AI tool for the specific problem of getting your resume seen.

💭 Final Thought

You do not have an information problem.

You have a specificity problem. Something specific in your materials, your pitch, or your positioning is not working, and the fix for that is not another article. It is someone looking at your actual stuff and telling you the truth, and then doing something about it in the same session, not next week, not when you feel ready.

The practitioners who are moving through this market are not the ones who found the perfect advice. They are the ones who stopped consuming and started working on the specific thing. They used the tools available, got honest feedback, made the change, and sent the application.

You have been in this field because you are good at figuring out what is broken and making it better. The job hunt is just another broken experience to work through.

Stop reading. Go work on it.

--- The UXU Team

“ChatGPT can design entire websites now.”
“AI generates production-ready UI in seconds.”
“Designers replaced by automation at major tech company.”

And you’re wondering: Should I be worried? Should I learn AI? Is my job about to disappear?

Here’s the uncomfortable answer: AI won’t take your job. But a designer who knows how to use AI will.

The threat isn’t the technology. The threat is staying static while the ground shifts under you. And right now, that ground is moving faster than most designers realize.

This isn’t another “AI is coming” panic piece. This is about what’s actually happening in 2025, who’s surviving it, who’s not, and what you need to do about it in the next six months,, not five years from now.

What’s really changing:

• Why junior design roles are vanishing (and it’s not just AI)

• The skills that actually protect you from automation

• What “AI-assisted design” means in practice right now

• How to upskill without learning to code or becoming a prompt engineer

• Which designers are getting hired in 2025 vs. which ones aren’t

• What companies actually want when they say “AI literacy”

The junior designer bloodbath nobody’s talking about

Let’s start with what’s actually happening in the job market right now, because the data is brutal.

Entry-level UX roles are down 67% from 2022. (Source)

That’s not a recession dip. That’s structural change.

Why companies aren’t hiring juniors anymore:

AI does what juniors used to do

Junior designers traditionally handled:

• Creating component variations

• Resizing designs for different breakpoints

• Generating icon sets and illustrations

• Building simple wireframes from requirements

• Cleaning up design files and documentation

Figma AI, Midjourney, ChatGPT, and Claude now do all of this in seconds. A senior designer with AI tools produces what used to require a senior + two juniors.

The math is simple: Why hire a junior at $65K when your existing team can use AI tools for $20/month per person?

The skill gap widened, fast

Five years ago, the gap between junior and mid-level was: more experience, more speed, more judgment.

Today, that gap is: strategic thinking, stakeholder management, business acumen, complex problem-solving.

AI accelerated execution skills so much that companies don’t need people who are just “learning to execute.” They need people who can think strategically from day one.

Bootcamp grads who can make pretty screens but can’t frame business problems or navigate stakeholder conversations? The market doesn’t need them anymore. AI made execution cheap. Thinking is what’s expensive.

Remote work killed the apprenticeship model

Junior designers used to learn by osmosis: sitting next to seniors, overhearing conversations, seeing how decisions really get made.

Remote work + economic pressure killed that. Companies won’t invest in developing juniors when they can hire experienced designers who produce value immediately.

The path of “graduate bootcamp → get hired junior → learn on the job → promote to mid-level” is functionally dead at most companies.

The survivors: Juniors who don’t act junior

The few junior roles that still exist? They’re going to people who:

✓ Already understand AI tools and use them to amplify output
✓ Can talk about business impact, not just design process
✓ Have built real things (even if small) that show strategic thinking
✓ Communicate like mid-level designers who happen to have less experience
✓ Bring adjacent skills (research, data, front-end, domain expertise)

If you’re purely “I learned Figma and took a UX bootcamp,” you’re competing with AI for execution tasks. And AI is winning.

Reality check: The market isn’t going to magically create more junior roles again. The shift is permanent. Either level up fast or get left behind.

What “AI-native designer” actually means (and what it doesn’t)

Every job post now says “AI experience preferred” or “familiarity with AI tools a plus.”

But what does that actually mean? Because most designers are guessing wrong.

❌ What companies DON’T mean:

“You need to learn prompt engineering”

You don’t need to be a prompt expert. You need to be competent enough to get results. The difference between an expert prompt and a decent prompt is maybe 15% better output. That’s not what gets you hired.

“You need to code AI models”

Nobody expects designers to train models or understand ML architecture. That’s not the job. Understanding what AI can and can’t do? Yes. Building it yourself? No.

“You need to abandon traditional design skills”

AI doesn’t replace core design skills, composition, hierarchy, user psychology, research synthesis, strategic thinking. It amplifies them. The fundamentals matter more than ever because AI handles the rote stuff.

✓ What companies ACTUALLY mean:

“You use AI to work faster and better”

Can you use ChatGPT/Claude to draft research plans, synthesize interview data, generate copy variations?

Can you use Midjourney/DALL-E to rapidly explore visual directions instead of spending hours in Photoshop?

Can you use Figma AI to speed up component creation and responsive design?

If these tools make you 2-3x more productive than someone who doesn’t use them, you’re hireable. If you’re still doing everything manually, you’re expensive.

“You understand what AI can and can’t do”

Knowing when to use AI vs. when human judgment is critical is the skill.

AI is great for:

• Generating options quickly for evaluation

• Handling repetitive execution tasks

• Synthesizing large amounts of information

• Creating first drafts of basically anything

AI is terrible for:

• Understanding context and nuance

• Making strategic decisions with competing priorities

• Navigating organizational politics

• Knowing what problem to solve in the first place

Designers who know this distinction and use AI strategically? Valuable.

Designers who either ignore AI entirely or let it make decisions it shouldn’t? Not valuable.

“You can explain your process even when AI was involved”

If you used AI to generate concepts, can you articulate why you picked one over the others?

If you used AI to draft research synthesis, can you defend the insights and explain what the raw data showed?

Using AI and still demonstrating clear thinking is the bar. Using AI as a crutch that prevents you from developing judgment is the problem.

“You’re adaptable as tools evolve”

AI tools change every month. New capabilities. New interfaces. New workflows.

Companies want people who can learn new tools quickly and integrate them into their process. Not people who learned one specific tool and can’t adapt.

The skill isn’t “I know how to use ChatGPT 4.” The skill is “I can evaluate new tools, figure out how they fit my workflow, and start using them productively within days.”

The real signal companies look for:

Can you produce senior-level output with AI assistance even if you’re mid-level?

That’s it. That’s what “AI literacy” means in hiring. If AI lets you punch above your weight class, you’re valuable. If you’re ignoring AI and working at the same pace as three years ago, you’re getting lapped by people who aren’t.

Pause for something urgent.

🎯 Your Next Move: A 4-Hour Reality Check That Actually Helps

Look, you can read another article about AI and upskilling and feel motivated for 20 minutes before going back to scrolling LinkedIn and wondering why your applications go nowhere.

Or you can spend four hours in a room with people who are actually doing something about it.

July 23, 2025 · 12:00–4:00 PM Silver Spring Civic Building at Veterans Plaza 1 Veterans Pl, Silver Spring, MD 20910

RSVP HERE!

This isn’t a talk. You’re not sitting there listening to someone pontificate about the future of work. You’re working, on your actual resume, your actual positioning, your actual next move, with AI tools, with real feedback, with people who do this professionally.

You walk in unclear. You walk out with something finished. A resume that’s actually competitive. A pitch that lands. A clearer sense of where you fit in this new economy.

No jargon. No theory. No “10 trends to watch in 2026.” Just practical work on your real stuff with people who are serious about their next move.

July 23, 2025 · 12:00–4:00 PM
Silver Spring Civic Building at Veterans Plaza
1 Veterans Pl, Silver Spring, MD 20910

RSVP HERE

Four hours. Real work. Real results. That’s it.

The skills that actually protect you (spoiler: it’s not Figma)

AI is automating execution. What it can’t automate and won’t for years is the messy, human, strategic things.

Here’s what actually protects your career:

🛡️ 1. Problem framing & strategic thinking

What it is: Figuring out what problem to solve before anyone starts designing solutions.

Why it matters: AI can generate 100 solutions. It can’t tell you which problem is worth solving or why. That requires understanding business context, user needs, technical constraints, and organizational politics.

How to build it:

• Stop jumping to solutions. Spend more time in the problem space.

• Ask “why” five times before accepting a project brief.

• Study how experienced designers frame problems—notice the questions they ask.

• Practice writing problem statements that are specific, testable, and valuable.

The signal: When stakeholders come to you with “we need feature X” and you can reframe it as “actually, the underlying problem is Y, and here are three ways to solve it”, you’re doing strategic work AI can’t touch.

🛡️ 2. Research synthesis & insight generation

What it is: Turning raw research data into actionable insights that change product direction.

Why it matters: AI can transcribe interviews and identify themes. It cannot understand context, read between the lines, or connect insights to business strategy. Human judgment is still required.

How to build it:

• Do more research. Even small-scale. Interview 5 users. Watch 3 usability tests.

• Practice synthesis: take raw transcripts and find the non-obvious patterns.

• Study great research case studies, notice how insights are framed.

• Learn to write insights that are specific enough to drive decisions.

The signal: When you can say “Here’s what users said, here’s what they actually meant, and here’s what we should do about it” with confidence, you’re doing work AI assists with but doesn’t replace.

🛡️ 3. Stakeholder navigation & influence

What it is: Getting buy-in for your work. Navigating politics. Translating between design and business.

Why it matters: AI can’t attend meetings, read the room, build relationships, or convince skeptical executives. This is purely human work.

How to build it:

• Volunteer for cross-functional projects that require stakeholder management.

• Practice translating design decisions into business language.

• Learn to present work persuasively, this is a learnable skill.

• Build relationships with PMs, engineers, executives. Influence happens through relationships.

The signal: When stakeholders trust your judgment and advocate for your work even when you’re not in the room, you’ve built something AI never will.

🛡️ 4. Systems thinking & complexity management

What it is: Designing for ecosystems, not just screens. Understanding how decisions ripple across products, teams, and time.

Why it matters: AI optimizes locally. It can’t see the second-order effects of design decisions across a complex system. Humans (barely) can.

How to build it:

• Study design systems, not just as component libraries, but as organizational tools.

• Think in flows and journeys, not just screens.

• Consider edge cases, error states, and what happens when things break.

• Ask “what else does this affect?” for every design decision.

The signal: When you catch problems that would have caused issues three months post-launch, you’re thinking systemically.

🛡️ 5. Domain expertise & specialized knowledge

What it is: Deep understanding of a specific industry, user type, or problem space.

Why it matters: AI has general knowledge. It doesn’t have 5 years of understanding how healthcare billing works or what enterprise procurement buyers actually care about. Domain expertise is built through experience, not training data.

How to build it:

• Pick an industry or problem space and go deep.

• Learn the jargon, the regulations, the user behaviors, the business models.

• Become the person who understands this domain better than anyone else on your team.

• Build specialized pattern recognition AI doesn’t have.

The signal: When people come to you specifically because you understand their domain, you’re irreplaceable.

The pattern:

AI automates tasks. Humans handle context, judgment, relationships, and complexity.

If your job is primarily task execution (make this screen, run this test, generate these variations), you’re competing with AI.

If your job is primarily thinking, influencing, and navigating complexity, you’re using AI as a tool that makes you better.

What to actually do in the next 90 days

Enough theory. Here’s your practical roadmap for the next three months:

Month 1: Get functional with AI tools

Week 1-2: Build basic AI literacy

• Spend 30 min/day using ChatGPT or Claude for design work

• Use it to: draft research plans, generate copy variations, synthesize notes, brainstorm concepts

• Goal: Make AI assistance a daily habit, not a novelty

Week 3-4: Explore visual AI

• Experiment with Midjourney or DALL-E for concept exploration

• Use Figma AI features for production work

• Goal: Understand what visual AI can and can’t do well

Deliverable: Use AI in one real project this month. Document what worked and what didn’t.

Month 2: Build one AI-resistant skill deeply

Pick ONE from the list above (problem framing, research, stakeholder management, systems thinking, domain expertise).

Commit 10 hours/week for 4 weeks to developing it:

• If research: Conduct 12 user interviews, synthesize findings, present insights

• If stakeholder management: Lead a cross-functional project, practice presenting to non-designers

• If problem framing: Take 3 project briefs and reframe them strategically before designing

• If domain expertise: Deep-dive one industry, read case studies, learn terminology, understand users

Deliverable: Add one case study to your portfolio that demonstrates this skill at a higher level than before.

Month 3: Position yourself as AI-augmented

Week 1-2: Update all materials

• Resume: Add AI tools you use and how they improved output/speed

• Portfolio: Show projects where AI made you more effective

• LinkedIn: Update headline to signal AI literacy (e.g., “Product Designer | AI-Augmented Workflows”)

Week 3-4: Start applying with new positioning

• Target roles that value AI skills + strategic thinking

• In applications, mention how AI makes you more productive

• In interviews, discuss AI openly—how you use it, what it can’t do, why humans still matter

Deliverable: Apply to 20 positions with your new positioning. Track response rate.

Ongoing: Stay adaptable

• Spend 2 hours/month exploring new AI tools as they launch

• Join design communities discussing AI (Discord servers, Slack groups)

• Share what you learn, teaching solidifies understanding

• Keep your skills sharp in things AI can’t do (strategic thinking, research, influence)

The 90-day outcome:

You’re not an AI expert. You’re a designer who uses AI strategically, focuses on high-value human skills, and positions yourself as more valuable than someone who doesn’t.

That’s enough. That’s the bar for 2025.

📦 Resources That Actually Help

Figma AI Documentation
Learn what Figma’s AI features actually do and how to use them in production work.

ChatGPT for Designers (Free Course)
Practical applications of LLMs for design work. No coding required.

Midjourney Prompting Guide
Get past random outputs. Learn to direct visual AI intentionally.

AI for UX Research (Nielsen Norman Group)
Research-backed guidance on using AI in discovery and synthesis.

The UX of AI (Design at Meta)
Case studies from teams designing AI-powered products. Shows real implementation challenges.

💭 Final Thought

The designers panicking about AI are asking the wrong question.

It’s not “Will AI take my job?”

It’s “Am I developing skills that make me more valuable than AI, or am I staying in the zone where AI is cheaper and faster than me?”

If your value proposition is executing tasks quickly making screens, creating components, running standard processes, you’re in danger. Not because AI is perfect, but because AI is good enough and costs almost nothing.

If your value proposition is thinking strategically, understanding context, navigating complexity, and influencing decisions, you’re fine. Actually, you’re more valuable than ever, because AI makes you faster at the execution parts.

The gap between designers is widening fast. The ones who adapt are pulling ahead. The ones who resist are falling behind. There’s no standing still anymore.

You have six months to figure out which side of that gap you’re on.

Not six years. Six months.

Choose accordingly.

— The UXU Team

P.S. If you’re in the DC/Maryland area and done reading articles that don’t help: July 23rd workshop. Four hours. Real work. No more theory.

RSVP HERE!

But something feels off. You are tired in a way that a weekend does not fix. Projects that used to excite you feel like tasks to survive. You finish something and instead of satisfaction, you feel... nothing. Or worse, you wonder if it even mattered.

You are not alone. And it is not a you problem.

This issue is about what is actually happening to practitioners in this field right now, why it is hitting so many people at once, and what to do that is more useful than “practice self-care.”

In this issue:

• What’s different about burnout in UX right now

• The specific things draining the field in 2026

• What this looks like for designers vs. researchers

• The identity piece nobody talks about

• What actually helps

• Resource Corner

What’s different about burnout in UX right now

UX burnout is not new. What’s new is the source.

Old burnout came from overwork. Too many hours, too many projects, not enough rest. That is still real. But what’s hitting practitioners hardest in 2026 is something different and harder to name.

Earlier burnout came from long hours. Now it comes from never feeling settled. MockFlow

The ground keeps moving. The tools change. The job description expands. The market contracts. AI reshapes what counts as skilled work. Layoffs hit teams that felt secure. Roles that seemed stable quietly get compressed into other roles. And through all of it, the expectation is that you keep delivering at the same level while absorbing the uncertainty as though it is just background noise.

It is not background noise. It is the main event. And it is exhausting.

The specific things draining the field in 2026

🔴 One person, four jobs

As companies try to do more with less, they create impossible role expectations. The result is burnout, lower quality work, and practitioners stretched too thin to excel at anything. Lyssna

Designers are being asked to research, write, prototype, test, manage stakeholders, and now prompt AI tools on top of it all. Researchers are being asked to run studies, synthesize findings, coach non-researchers, maintain repositories, and prove ROI simultaneously. The job title stayed the same. The scope did not.

When you’re doing two or three jobs at once, you can’t excel at all of them, so you constantly feel like you’re behind or failing. That feeling is not imposter syndrome. It is an accurate read of an unsustainable situation. Akraya

🔴 Work that disappears

Few things drain practitioners faster than effort that goes nowhere.

Weeks of research that get nodded at and filed. Designs that come back from engineering looking nothing like the handoff. Strategy work that gets ignored when priorities shift. Spending weeks on something that never ships because priorities suddenly changed or someone higher up made a last-minute call is not just frustrating. It chips away at your sense of purpose, slowly and consistently. Akraya

When your work does not land, you start to question whether the work matters. When you question whether the work matters long enough, you stop bringing your full self to it. That is the quiet version of burning out. No dramatic collapse. Just a slow dimming.

🔴 Constantly defending the job

In low-maturity teams, practitioners are often treated as pixel polishers instead of problem solvers. Brought in late, expected to make it pretty, and left out of strategy discussions. More time is spent defending the role than doing the actual work. Akraya

Researchers know this particularly well. Explaining why research takes time. Justifying why you need to talk to more than five users. Making the case for why a survey is not the same as a discovery interview. This is not a once-in-a-while conversation. For many practitioners, it is weekly. Possibly daily. And it is exhausting to fight for permission to do your job on top of actually doing it.

🔴 The job market doing what it’s doing

One open design role today easily gets 1,000 or more applications. Most resumes never reach a person. Portfolios are skimmed for seconds. Hiring managers expect senior-level output at junior-level cost. And after all that, you still get ghosted. No rejection. No feedback. No closure. MockFlow

For practitioners who are between roles or quietly looking, this is a specific kind of sustained stress. You update the resume again. Rewrite the case studies again. Wonder what is wrong. Nothing is wrong. The system is just built this way right now, and carrying that uncertainty while also delivering at your current role is a significant weight that most people are carrying silently.

What this looks like for designers vs. researchers

Same field, different flavors.

Designers are often dealing with the identity blur. You’re designing, prompting, debugging, writing copy, thinking product, thinking business, thinking systems. Shipping more than ever, but less sure who you’re becoming. Identity uncertainty drains you faster than workload ever did. When the role expands in every direction at once, it becomes hard to know what you are actually supposed to be excellent at. MockFlow

Researchers are often dealing with the relevance grind. Running studies that feed into decisions that have already been made. Watching democratization mean that everyone does research now but nobody does it with the rigor that changes outcomes. Proving value in every conversation while the function quietly gets treated as optional when timelines get tight.

Both are exhausting. Neither is a personal failing.

The identity piece nobody talks about

This one sits underneath everything else and rarely gets named directly.

UX practitioners chose this field because they care. About the work. About the people the work is for. About making things better and more human. That motivation is not just professional. For most people in this field, it is personal.

When the work does not land, when the role keeps expanding, when the field feels unstable, the question that creeps in is not just “is my career okay.” It is “was I wrong about what this work was supposed to be?”

That question is heavier than it looks.

Your biggest risk in 2026 is not being replaced by AI. It is emotionally shutting down while trying to outrun it. MockFlow

And the answer to that question is not a framework or a productivity system. It is permission to acknowledge that the field changed significantly and fast, that it is reasonable to feel disoriented by that, and that disorientation is not the same as being in the wrong place.

What actually helps

Not “meditate more.” Actual things.

✓ Name what’s draining you specifically

Burnout is easier to address when it has a specific source. Is it the scope of the role? The work that disappears? The constant justification? The uncertainty of the market? Different problems have different responses. Vague exhaustion is harder to move than a specific identified pressure.

✓ Stop absorbing what is not yours to carry

Some of what practitioners are carrying is genuinely theirs: the craft, the decisions, the quality of the work. A lot of what practitioners are carrying is not theirs: organizational dysfunction, leadership decisions made above them, market conditions outside their control. Learning to tell the difference, consistently, is one of the most protective things you can do for yourself in this field right now.

✓ Find one project where the work actually lands

Sustained engagement requires feedback that the work matters. If your main role is not providing that right now, find a context that does. A side project. Volunteering. A mentorship relationship where your input visibly helps someone. Not as a solution to everything, but as a reminder of why you are in this at all.

✓ Talk to someone who gets it

Many practitioners felt disillusioned: experienced UXers were tired of being misunderstood; newer ones couldn’t break in. This is a field-wide experience and a lot of people are carrying it privately. Finding people who are in it too, without it becoming a competition about who has it worse, is genuinely stabilizing. The communities, the Slack groups, the conferences. The point is not networking. The point is not being alone in something that a lot of people are going through simultaneously. LogRocket

✓ Reanchor to the work that made you want this

Not the deliverables. Not the process. The actual thing. A session where someone says “oh, I never thought about it that way.” A design decision that made something easier for somebody. A research finding that genuinely changed what got built. That is why most people in this field are here. Keeping that in view, especially when the surrounding noise is loudest, matters more than any career strategy.

Quick interruption. Genuinely relevant.

🎯 If you’re trying to figure out your next move, this workshop is for you.

Not a lecture. Four hours of working on your actual stuff: your resume, your pitch, your positioning in a market that keeps moving. You leave with something finished and one clear next step.

📅 July 23, 2025 · 12:00 to 4:00 PM 📍 Silver Spring Civic Building, Silver Spring, MD

RSVP HERE!

📦 Resource Corner

Burnout: The Secret to Unlocking the Stress Cycle by Emily and Amelia Nagoski The most practically useful book on burnout available. Not about productivity. About completing the stress cycle so it does not accumulate. Read this before you read another career book.

The UX Collective: State of UX 2026 The annual read from Fabricio Teixeira and Caio Braga. Honest, field-wide, and validating in a way that most industry reports are not. Especially useful if you have been feeling like something shifted but could not articulate what.

Lyssna UX Design Trends Report 2026 Survey of 100 designers on what they are actually experiencing. The data on role expansion and impossible expectations is worth reading just to know you are not imagining it.

Interaction Design Foundation Community One of the more active communities for UX practitioners to talk honestly about the work and the field. Useful when the conversations in your immediate team are not enough.

💭 Final Thought

The field is not broken. You are not broken. But something genuinely shifted, and pretending it did not is making a lot of people quietly miserable.

A year ago, UX felt like it was on trial. Layoffs and hiring freezes made the field feel unstable, while leaders demanded clearer proof that design work impacted the bottom line. Many practitioners felt disillusioned. Some of that has stabilized. Some of it has not. And the practitioners who are doing okay are not the ones who found a way to feel nothing about all of it. They are the ones who stopped pretending the exhaustion was not there and started addressing it specifically, honestly, and without treating it as a personal failure. LogRocket

You got into this field because you wanted to make things better for people. That instinct is still worth protecting. But you cannot protect it while running on empty and calling it resilience.

Take the week seriously. Not the deliverables. You.

--- The UXU Team

That narrative got a lot quieter.

Not gone. But quieter. And if you have been in this field for more than two years, you have felt it. Fewer decision-making conversations you are included in. Research that gets nodded at and filed away. Designs that come back from engineering looking nothing like what was handed off, and nobody flagged it as a problem.

This issue is about what actually happened and, more importantly, what to do about it.

Speaking of Don Norman, Join Him at UXCON26

Don Norman is famous for doors that are confusing to open. They are called Norman Doors. If you have ever pushed a door that should be pulled, you have lived inside one of his ideas.

That is what Don Norman does. He makes you see the world differently.

Hearing Don Norman speak in 2026 is not a checkbox on a conference list. It is a genuine once-in-a-career opportunity.

Join Don Norman at UXCON26

In this issue:

• What shifted and when

• The ways UX lost influence without noticing

• What this looks like for designers vs. researchers

• What influence actually looks like now

• How to rebuild it, specifically

• Resource Corner

What shifted and when

The influence peak was real. Between roughly 2017 and 2022, UX had genuine organizational momentum. Design thinking was being taught in business schools. Chief Design Officer roles were being created. Teams grew. Budgets expanded.

Then a few things happened at once.

Budgets tightened and UX struggled to defend itself in the language leadership speaks. As interest rates rose and budgets tightened, leaders looked for roles easiest to justify financially, and UX often struggled to defend itself with simple, direct metrics. When cuts came, design and research teams were hit hard, partly because they had never built a clear language for their own value that leadership could hold in their hands. LinkedIn

AI gave companies a convenient cover story. AI hype created a misleading narrative that new tools could rapidly replace designers and researchers. That was not true, but the story was convenient in a cost-cutting environment. LinkedIn

But here is the harder part. Some of the influence loss was not done to us. It was allowed. Decisions got made without UX input not because no one cared, but because nobody noticed UX was absent until after the decision was locked. That pattern, repeated across enough sprints and roadmap sessions, becomes the new normal.

The ways UX lost influence without noticing

None of this happened overnight. It accumulated quietly.

🔴 Deliverables became the product

Journey maps. Research reports. Empathy maps. These are tools for thinking, not things to ship. Somewhere along the way, a lot of teams started treating the artifact as the outcome. Researchers spent weeks on a report that got presented, admired, and filed. Designers handed off Figma files and waited.

Available roles increasingly demand breadth and judgment, not just artifacts. The market is now saying explicitly that deliverable production is not the job. The judgment behind it is. LinkedIn

🔴 Craft got refined while influence quietly eroded

The field got very good at producing thorough, well-documented work. Figma files with perfect component organization. Research decks with elegant synthesis. The craft improved while organizational influence atrophied, because influence is not built through better deliverables. It is built through better decisions and being present when those decisions happen.

🔴 UX stopped speaking the language of the room it wanted to be in

Most UX practitioners speak design and research fluently and business haltingly. Work gets presented in terms of friction, user needs, and experience principles. Leadership hears that and translates it to: interesting, not urgent.

The practitioners who kept their seat learned to translate. Not by abandoning user advocacy, but by anchoring it to things leadership already tracks. Retention. Error rates. Support volume. Activation. These are the numbers that make UX work visible to people who control budgets. Invisible work eventually becomes defunded work.

🔴 Speed swallowed research

This one hits researchers specifically. The biggest challenge in 2026 is speed: teams are under pressure to validate problems and ship faster, often leading to research debt. Research that takes three weeks does not fit a two-week sprint. So teams started skipping it, substituting it, or running versions of it fast enough to be schedulable and shallow enough to be unreliable. Lovable

The result is a strange situation where research is more discussed than ever and less acted on than ever. The gap between what organizations say about research and what they actually do with it is one of the most consistent patterns in the field right now.

What this looks like for designers vs. researchers

Same problem, different texture

.

For designers: the risk is becoming an execution function. Getting brought in after the problem is defined, the constraints are set, and the decision is basically already made. Figma becomes a documentation tool for decisions that happened elsewhere.

For researchers: the risk is becoming a validation function. Getting brought in to confirm what the team already wants to do, rather than to discover what they should be doing. Research that only runs when there is time for it is research that has already lost its strategic position.

Both of these are influence problems, not skill problems. The work is good. The timing and positioning of the work is what is off.

What influence actually looks like now

The practitioners who thrive treat UX as strategic problem solving, rather than focusing on producing deliverables. LinkedIn

Influence in 2026 does not look like presenting polished work at a sprint review. It looks like being in the room when the problem is being defined. It looks like research findings being cited in the meeting where the roadmap gets decided, not the meeting after it.

Practically, the most influential UX practitioners right now share a few things:

→ They know what decisions are being made before anyone tells them

→ They take positions, not just present options

→ They connect their work to metrics leadership is already watching

→ They make findings available the moment they are relevant, not when the report is finished

→ They are the person a PM calls before the meeting, not during it

That last one is worth sitting with. If you are only being consulted inside formal design reviews or research share-outs, you are downstream of influence. The decisions that shape what you work on are being made in conversations you are not in yet.

How to rebuild it, specifically

✓ Find out what decisions are being made and get upstream of them

Every product team has a rhythm of decisions: what to build, what to cut, what to test, what to ship. Map that rhythm in your organization. Find where you are currently absent and get present there. Not to add process, but to change the output.

✓ Answer the impact question before anyone asks

Do not wait for leadership to ask what the impact of your work was. Answer it preemptively, every time. Even rough numbers are better than none. A drop in task failure rate. Fewer steps to completion. A reduction in a specific support ticket category. These are the things that make UX legible to people who did not go to design school.

✓ Shorten the distance between insight and action

The research report that takes four weeks to write and two hours to present is not the format that maintains influence in fast-moving teams. A Slack message with one finding and one implication. A five-minute share at the start of a sprint. Insight that arrives when it is needed lands differently than insight that arrives when it is finished.

✓ Take a position

The most influential practitioners in any organization are not the most neutral ones. They are the ones who look at the evidence and say: we should do this. Not “here are three options.” Not “here is what we found.” A recommendation. A stance. Something someone can agree with or push back on. Influence requires having a position to respond to.

✓ Make the user impossible to ignore

This is the irreplaceable part of the job. Share a two-minute clip from a session before the roadmap discussion. Put a quote from a user interview on the first slide of every presentation. Make the person on the other side of the screen feel present in rooms where they are usually abstract. That advocacy, done consistently, is what separates UX practitioners who lead from those who execute.

Quick interruption. This one is for you.

🎯 Not sure where you fit right now? This workshop was built for that moment.

If you have been laid off, watching your field shift, or applying and hearing nothing back, this is not a lecture about what you should have done differently. It is four hours of working on your actual stuff. Your resume, your pitch, your positioning in a market that keeps moving.

No theory. You leave with something finished and one clear next step.

📅 July 23, 2025 · 12:00 to 4:00 PM 📍 Silver Spring Civic Building, Silver Spring, MD

RSVP HERE!

📦 Resource Corner

State of UX 2026 (Nielsen Norman Group) The most grounded annual read on where the field actually is versus where it thinks it is. The section on influence and business impact is worth reading twice.

Articulating Design Decisions by Tom Greever The practical guide to communicating design work in language that lands with stakeholders who do not share your background. One of the most useful books in the field right now.

Continuous Discovery Habits by Teresa Torres The framework most product teams are moving toward. Essential reading for researchers and designers who want to stay upstream of decisions instead of downstream of them.

Measuring the User Experience by Tullis and Albert If you struggle to connect your work to numbers leadership cares about, this is where to start. Practical, not academic.

💭 Final Thought

The seat at the table was never guaranteed. It was earned, and then somewhere along the way, a lot of UX teams stopped earning it daily and started assuming it was permanent.

It was not. Neither is any organizational role.

What UX has going for it is something genuinely hard to replace: the ability to understand what people actually need, as opposed to what they say they want or what the data says they clicked. That skill, applied upstream in decisions rather than downstream in deliverables, is where the influence lives.

The field is not dying. The question of whether UX is still strategic or becoming redundant is one the industry is actively debating in 2026. But the practitioners who are answering that question in their favor are not waiting for organizations to rediscover the value of UX. They are making that value impossible to ignore, one decision at a time. Nielsen Norman Group

That is the work now. Not the Figma file. Not the research report. The decision that those things change.

— The UXU Team

This issue looks at what democratization actually means, where it helps, where it breaks down, and what both researchers and designers need to do about it.

In this issue:

• What research democratization actually is and why it happened

• Where it genuinely helps

• Where it quietly goes wrong

• What researchers need to do to stay relevant and protect quality

• What designers need to know when they become the researcher

• The right model for 2026

• Resource Corner

What research democratization actually is and why it happened

Research democratization means non-researchers doing research. Designers running their own usability tests. PMs sending out surveys. Customer success pulling themes from support tickets and calling it qualitative insight. It has been building for years but in 2026, designers are now conducting more research than dedicated UX researchers, and product managers are not far behind. LogRocket

Three things drove this.

1. The tools got too easy to ignore Platforms like Maze, Dovetail, UserZoom, and Hotjar turned research tasks that once required specialist knowledge into point-and-click workflows. Anyone with a prototype and a Maze account can have usability data in 48 hours. The barrier to running research collapsed.

2. Teams got leaner and timelines got shorter Teams are under pressure to validate problems and ship faster, often leading to research debt. LogRocket When there is one researcher supporting six product teams, waiting for dedicated research support on every question is not realistic. Teams started doing it themselves out of necessity, not ambition.

3. Continuous discovery became the expectation The old model of big research studies feeding into quarterly roadmaps does not match how product teams actually work in 2026. Leading teams are treating UX research as an ongoing signal system that informs every release, not just major launches. Akraya That requires more people feeding into the system, not fewer.

Where it genuinely helps

Not all democratization is bad. Some of it is actually good for the field, and saying otherwise is defensive rather than honest.

✓ Speed on low-stakes questions When a designer needs to know whether users understand a new navigation pattern, running a quick unmoderated test themselves is faster and often good enough. Waiting three weeks for researcher availability on that question is not a good use of anyone’s time.

✓ Keeping teams user-connected Designers and PMs who regularly talk to users, even informally, make better decisions day to day. The instinct to check assumptions against real people before building is healthy and worth encouraging across the whole team.

✓ Freeing researchers for harder work AI can complete 80% of the work, allowing researchers to add the crucial 20% with nuanced interpretation based on experience and expertise. UX Studio The same logic applies to democratization. If basic usability testing moves to designers, researchers can spend their time on generative research, complex synthesis, organizational influence, and strategic framing. That is a better use of a researcher’s depth.

✓ Scaling research operations AI is accelerating time-intensive workflows like transcription, synthesis, and study planning, helping teams scale research operations more efficiently. LogRocket Democratization plus AI tooling means research can touch more decisions than a small centralized team could ever cover alone.

Quick interruption. This one is for you personally.

Worth four hours of your time.

🎯 AI & The New Economy: Hands-On Workshop

The job market is not waiting for anyone to catch up. If you are feeling behind, unclear on your positioning, or just not getting responses, this workshop skips the theory and gets straight to work.

You bring your real stuff. Your resume, your pitch, your positioning. You leave with something finished and one clear next step.

RSVP HERE!

back to where we stopped….

Where it quietly goes wrong

This is the part the tools companies underplay in their marketing.

🔴 Confidence without rigor The biggest risk of democratization is not that people run bad research. It is that they run bad research and trust the results completely. A PM who sends a five-question survey to 30 existing customers and concludes “users want feature X” has done something. But the sample is biased toward power users, the question framing likely led the response, and the finding says nothing about non-users or churned users. The problem is they do not know what they do not know.

🔴 Usability testing replacing discovery Most democratized research is evaluative. Does this design work? Can people find this button? Those are useful questions. But they are not the same as asking why users behave the way they do, what problems are worth solving in the first place, or what the product is missing entirely. Researchers will increasingly need to test trust, explainability, failure modes, and escalation paths, not just task flows and layouts. Akraya That kind of generative, strategic research does not democratize easily, and when teams substitute usability tests for it, they optimize existing ideas rather than finding better ones.

🔴 Insight repositories nobody uses Research democratization produces more data. It does not automatically produce more decisions informed by that data. Most teams doing democratized research are not feeding findings into a shared repository. They are keeping them in a Notion doc, a Slack thread, or their own memory. Six months later, the same questions get researched again from scratch.

🔴 Researchers losing influence without losing workload Several researchers have expressed concerns about overreliance on AI, quality control, and the risk that AI will be overused and the gaps will be found and documented. Lyssna The same concern applies to democratization. When everyone is doing research, researchers can end up in a worse position: still responsible for quality and rigor, but no longer the clear owners of the function. They get consulted rather than leading.

What researchers need to do to stay relevant and protect quality

The answer is not to gatekeep research. That ship has sailed and fighting it wastes credibility. The answer is to reposition.

→ Become the standard-setter, not the executor The most effective researchers in 2026 are acting as coaches and quality stewards. They define the methods, build the templates, maintain the insight repository, review democratized research for quality issues, and step in personally for high-stakes or complex questions. Mature organizations are investing in research guidelines and templates that enable democratization without losing rigor, with central research teams acting as coaches. LogRocket

→ Go deeper on what cannot be democratized Generative research. Longitudinal studies. Synthesis across multiple data sources. Organizational storytelling that actually changes roadmap decisions. Measuring trust, not just task completion. These are the areas where researcher expertise creates irreplaceable value. Spend more time there and less time defending territory on studies that designers can reasonably run themselves.

→ Connect research to business outcomes explicitly UX research is now judged not only on insight quality but on how clearly it connects to outcomes like conversion, retention, and trust. Akraya Researchers who can speak that language directly get taken more seriously. Researchers who present findings without connecting them to decisions get their work admired and ignored.

→ Build the insight infrastructure If every team is doing research, someone needs to own the system that makes all of it findable and usable. Building and maintaining a research repository is unglamorous work that pays enormous dividends. It also positions researchers as the connective tissue of product knowledge across the organization, which is a much stronger position than running studies in isolation.

What designers need to know when they become the researcher

Designers doing their own research is not going away. Here is how to do it without fooling yourself.

✓ Know what kind of research you are running Evaluative research (does this work?) and generative research (what should we build?) require different methods, different questions, and different sample sizes. Most designer-led research is evaluative. That is fine, but be honest about what it can and cannot tell you.

✓ Recruit outside your comfort zone The most common mistake in democratized research is recruiting participants who are too similar to existing users or too easy to access. Colleagues, friends, and current customers all produce biased data in specific directions. Reach for people who are unfamiliar with your product, represent edge cases, or have recently churned.

✓ Separate observation from interpretation Write down what you saw before you write down what you think it means. The gap between “three users clicked the wrong button” and “users don’t understand the navigation” is where bias lives. Stay in observation longer than feels comfortable.

✓ Share your findings with a researcher before making decisions Even a 15-minute review with someone who does this professionally will catch problems you missed. It is not about asking permission. It is about quality control on a decision that might affect a lot of people.

The right model for 2026

The teams getting this right are not choosing between centralized research and full democratization. They are running both deliberately.

Designers and PMs handle evaluative, sprint-level research on their own using shared templates and tools. Researchers own generative work, complex synthesis, high-stakes studies, and the infrastructure that makes everything findable. Researchers also coach non-researchers regularly, not as a one-time training but as an ongoing relationship.

The winning approach is a mix of research democratization, AI-assisted workflows, and human review. LogRocket The key word is mix. Any team that tips too far in either direction, either locking all research behind a single team or letting everyone run studies without oversight, ends up worse off.

📦 Resource Corner

Lyssna UX Research Trends Report 2026 Survey of 100 UX researchers on what they expect to shape the field. The synthetic users data alone is worth reading carefully.

Dovetail The closest thing to a standard research repository right now. If your team is doing democratized research without a shared place to store findings, start here.

Maze The tool most designers reach for when running their own unmoderated tests. Worth understanding its strengths and limits before using it as a primary source of truth.

Research Skills for Designers (Nielsen Norman Group) The most credible structured training available for designers who are taking on research responsibilities without formal research training.

Just Enough Research by Erika Hall The best single book on research for non-researchers. Practical, opinionated, and short enough to actually read. Required for any designer who is running their own studies.

Continuous Discovery Habits by Teresa Torres The framework most product teams are moving toward for embedding research into weekly product work rather than treating it as a separate phase.

💭 Final Thought

Research democratization is not a threat to the UX research field. Bad democratization is.

The distinction matters. When everyone on a product team is curious about users, asks questions before building, and checks assumptions against real people, that is a healthy culture. When everyone runs five-question surveys, calls it research, and ships confidently based on a 30-person biased sample, that is a quality problem wearing the costume of a good habit.

Researchers who understand this are not trying to put the genie back in the bottle. They are building the infrastructure, standards, and coaching relationships that make broader participation in research actually trustworthy. That is a more interesting and more influential job than running studies alone.

And for designers doing their own research: do it. It will make you better. Just stay honest about what it can tell you and humble about what it cannot.

The goal was never research for its own sake. It was always better decisions for real users. Keep that as the measure and the rest follows.

-- The UXU Team

Job titles are blurring. AI is not a future consideration anymore. It is already inside the process, changing what gets built, who builds it, and what skills actually matter when the work gets hard. Research budgets are shrinking. Junior roles are disappearing. Senior practitioners are being asked to justify their seat at the table in ways they never had to before.

And underneath all of it, a lot of people in this community are sitting with a version of the same question: what does my career look like from here?

We are not pretending that question has an easy answer. But we are creating two spaces this year where the community can face it together, with the right people, the right conversations, and something useful to walk away with.

Upskill AI: Repositioning For The New Economy July 23 · 12 to 4PM · Silver Spring Civic Building, MD

This is not a talk about AI. It is four hours of actual work, your resume, your positioning, your pitch, built inside the tools that are reshaping how hiring works right now. No theory. No slides to forget by Thursday. Just a room full of people who are serious about their next move, doing the work together, led by people who do this for a living.

You leave with something finished. A clearer read on where your skills belong in this economy. And one specific next step you chose before you walked out.

For anyone in this community navigating a transition, a layoff, or just a quiet feeling that the map has changed and nobody handed you a new one.

RSVP HERE!

UXCON26 October 8 · One Day · Full Lineup

Don Norman coined the term user experience. He wrote the book that sits on nearly every designer’s shelf. He is 88 years old and he is still challenging the field to go further, think bigger, and design for what humanity actually needs, not just what the product brief asked for.

He is our headlining keynote this year. Alongside him: practitioners from Netflix, The New York Times, Target, UserTesting, Skylight, and more. People doing the real work, at scale, under real constraints, right now.

UXCON is not a content delivery event. It is the one day of the year where this community gets in the same room and has the conversations that actually move things forward. The kind you think about on the drive home. The kind that change how you show up to work on Monday.

RSVP HERE!

Two different rooms. One direction forward.

— The UXU Team

This issue breaks down what actually happened, what it means depending on where you are in your career, and how to respond without either panicking or sticking your head in the sand.

In this issue:

• How we got here and why it happened fast

• What “design engineer” actually means (it’s not one thing)

• The real case for learning to code

• The real case for not coding

• What technical fluency actually looks like in practice

• How to respond based on your career stage

• Resource Corner

How we got here and why it happened fast

Three things converged and none of them are going away.

1. AI made the gap closeable

The old argument against designers coding was that it took years to get useful. That argument is dead. AI coding tools now let designers generate working interfaces, real components, functional prototypes, without deep engineering backgrounds. Designers can now bridge a technical gap that previously took years of computer science knowledge and coding experience to cross. Smashing Magazine Executives saw the demos. Some drew overblown conclusions. Others drew conclusions that were directionally accurate even if overstated. Either way, the expectation shifted.

2. Teams got leaner and handoffs got expensive

Post-layoff design teams are smaller. When you have one designer and two engineers on a product, the idea that the designer stays entirely in Figma while engineers translate everything into code starts to look like a bottleneck. Companies are not wrong to want to reduce that friction. The question is whether their solution (hire one person to do two jobs) is actually the right one. Often it is not. But the underlying pressure is legitimate.

3. Vibe-coding blurred the line publicly

Tools like Cursor and similar AI-assisted environments made it possible, visibly and publicly, for non-engineers to produce working interfaces. This did not make designers into engineers. But it made the distinction harder for non-technical stakeholders to understand, which is a design problem in itself.

The combined result: UX roles are increasingly demanding AI-augmented development, technical orchestration, and production-ready prototyping Smashing Magazine, often without a clear understanding at the hiring level of what those things actually mean in practice.

Quick interruption. This one is for you personally.

🎯 Not sure where you fit right now? This is for you.

If you’ve been laid off, watching your field shift, or applying and hearing nothing back, this workshop was built for that exact moment.

Four hours. Your real stuff. Your resume, your pitch, your positioning in a market that keeps moving. You leave with something finished and a clearer sense of what’s next.

No jargon. No coding. No theory. Just practical, hands-on work led by people who do this for a living, in a room full of people who are serious about their next move.

July 23, 2025 · 12:00–4:00 PM Silver Spring Civic Building, 1 Veterans Pl, Silver Spring, MD 20910

RSVP HERE!

back to where we stopped….

What “design engineer” actually means (it’s not one thing)

This matters a lot before you apply for, accept, or stress about any role using this title.

→ Version 1: Design systems engineer Owns the component library at the code level. Works in Storybook and Tokens Studio. Ensures what ships matches what was designed. This is a real, specialized, well-compensated role that requires genuine engineering depth. It is not a designer who also dabbles in code.

→ Version 2: Prototyper in code A designer who can build functional prototypes precise enough that engineers use them as implementation references rather than interpreting static Figma files. This is about reducing translation loss, not writing production code. Much more achievable. Much more common.

→ Version 3: One person doing two jobs A company trying to replace a designer and an engineer with a single hire, usually without acknowledging that is what they are doing. Attempting to master two disparate, deep fields simultaneously will most likely lead to being averagely competent at both. Smashing Magazine This version is worth identifying in the job description and negotiating around, or walking away from.

Knowing which version you are looking at before you accept a role is not optional. Ask directly in the interview: what does the engineering relationship look like? Who owns production code? What does “production-ready prototyping” mean on this team?

The real case for learning to code

Learning to code at even a basic level makes you a meaningfully better designer. This is not hype. It changes how you think.

✓ You design more buildable systems because you understand how components work
✓ You stop creating flows that look great in Figma and collapse immediately in development
✓ You can prototype interactions that Figma cannot express, especially complex states, logic, and animations
✓ You reduce your dependency on engineers for information you should already have
✓ You have more credible conversations in design reviews when technical tradeoffs come up

Beyond craft, the market signal is real and it is not reversing. Designers with technical fluency are getting more interviews, more leverage in salary negotiations, and access to more interesting and senior problems. That is the honest picture.

The additional depth that coding gives you is not about becoming an engineer. It is about removing friction from every collaboration you have, every day, at every stage of a project. That compounds over a career.

The real case for not coding

Some designers have a legitimate argument here, and it is worth taking seriously rather than dismissing as defensiveness.

A principal UX researcher. A service designer working across organizational systems. A content strategist shaping information architecture at scale. These roles create enormous value in ways that have nothing to do with React fluency. Asking them to invest hundreds of hours learning to code is a poor allocation of expertise that took years to build.

The risk is not in saying “I do not code.” The risk is in how you say it.

“I don’t code and I never will” signals rigidity in a market that is visibly shifting. It closes doors even at roles that do not strictly require technical skills.

“My primary value is in research and strategy, and I have enough technical fluency to collaborate effectively with engineering” is a completely different statement. It is also more accurate for most experienced researchers and strategists.

The distinction is between refusing to engage and being clear about where your depth actually lives.

What technical fluency actually looks like in practice

The designers navigating this well are not trying to become engineers. They are building enough fluency to work without friction.

In practice, this looks like:

→ Reading and lightly editing code rather than writing it from scratch
→ Understanding component-based thinking well enough that your design systems translate cleanly into engineering
→ Using AI coding tools to prototype interactions and states that static design tools cannot express
→ Knowing enough to have an informed conversation with an engineer, not a helpless one
→ Understanding what is technically expensive before you design it, not after

The designers who thrive will be those who use AI to augment their design thinking, allowing them to test more ideas and iterate faster, without trying to replace the specialized engineering expertise that ensures designs technically work for everyone. Smashing Magazine

That is the line. Use the tools. Stay on your side of it. Do not pretend the tools make you an engineer, and do not pretend they are irrelevant.

How to respond based on your career stage

🔵 Early career (0 to 3 years) This is the highest leverage moment to build technical fluency because the learning cost is lowest and the compounding time is longest. Get comfortable with HTML and CSS at minimum. Understand how a component library like React is structured even if you are not writing it daily. Use AI coding tools to prototype rather than relying entirely on Figma for everything. You do not need to be good at it yet. You need to not be afraid of it, and you need to be actively learning.

The designers entering the market now who are comfortable moving between design tools and code environments are going to pull ahead of those who are not. The gap will widen.

🔵 Mid career (3 to 7 years) Pick your lane intentionally and build accordingly.

If you are moving toward product design or design systems, deeper technical fluency is a genuine career accelerant right now. The roles are better, the compensation is higher, and the work is more interesting.

If you are moving toward research or strategy, invest your learning time there instead. Build just enough technical literacy to collaborate without friction, then go deep in your actual direction. The market still has strong demand for genuine research expertise. Do not abandon what you are good at because of a noisy job market trend.

What you should not do is let the noise panic you into learning things that do not serve your actual direction. Scattered learning in every direction produces designers who are average at everything, which is exactly the problem the issue about specialization covered.

🔵 Senior and above The expectation shifts at this level. You are not expected to ship code. You are expected to never be surprised by a technical constraint you should have anticipated. The job is judgment: knowing what is feasible, knowing what the tradeoffs are, making design decisions that hold up through engineering. Deep technical fluency helps that. A willingness to engage with engineering as a partner rather than a recipient of your files helps more.

If you are senior and still treating Figma handoff as the end of your involvement in a feature, that is the pattern to change, regardless of whether you ever write a line of code.

📦 Resource Corner

The Design Engineer Handbook (Figma / Stripe Press) The clearest articulation yet of what design engineering actually is and what it is not. Read this before taking any role with that title.

Frontend Mentor Project-based HTML/CSS/JS practice built specifically for people learning by building real things rather than watching videos. Low friction, high retention.

Scrimba Interactive coding environment where you code inside the tutorial itself. Significantly more effective than passive video courses for actually retaining what you learn.

Every Layout (Heydon Pickering and Andy Bell) If you learn one coding concept as a designer, make it CSS layout. This resource teaches it better than anything else available, and the mental models transfer directly into how you think about design systems.

React for Designers (Design+Code) Specifically aimed at designers who want to understand component-based development without crossing fully into engineering territory. Practical and well-scoped.

Smashing Magazine Design Engineering Coverage Ongoing reporting on how this role is evolving across different company types and team structures. Worth following rather than reading one article and drawing broad conclusions.

💭 Final Thought

The debate was never really “should designers code.” It was always “how much technical fluency does this designer, in this role, at this company, actually need to do their best work.” The honest answer to that has always varied.

What has changed is the floor. The minimum viable technical literacy for a working designer in 2026 is higher than it was three years ago. That is just true and it is not reversing.

But the ceiling argument is also still valid. Nobody becomes exceptional by stretching themselves across every possible skill. The designers getting the best outcomes right now are not the ones who panic-learned React after seeing a scary job listing. They are the ones who got clear on where they are going, built the fluency that direction actually requires, and stopped apologizing for not being engineers.

Know your lane. Learn enough to drive in it without friction. That has always been the real answer.

— The UXU Team

But here’s the trap: specialize too early and you box yourself in. Stay too general and you’re competing with everyone.

This issue breaks down the specialization paradox, when to niche down, and how to pick a focus that actually helps instead of limits you.

In this issue:

• Why “jack of all trades” stops working after year two

• The specializations that actually pay more right now

• How to pick a niche when you don’t know enough yet

• T-shaped vs. I-shaped vs. broken comb (and which you should be)

• When generalist skills still matter

• 📦 Resource Corner

Why “jack of all trades” stops working after year two

Early in your career, being a generalist is fine. Actually, it’s expected. You’re learning the landscape. You’re figuring out what you’re good at and what you actually enjoy.

But somewhere around year 2-3, the market shifts on you.

Here’s what happens:

🔴 Entry-level roles want generalists, but there are fewer entry-level roles

Junior positions ask for someone who can do “a little bit of everything” because they can’t afford specialists. But companies are hiring fewer juniors overall. They want experienced people who can hit the ground running in a specific area.

🔴 Mid-level roles assume specialization

Once you hit 3-5 years of experience, job descriptions get specific:

• “Senior UX Researcher with expertise in generative research”

• “Product Designer specializing in complex B2B workflows”

• “Interaction Designer with strong motion design skills”

If your resume says “I do everything UX,” you’re competing against people who are demonstrably excellent at the specific thing this role needs.

🔴 Generalists get passed over for raises and promotions

When it’s time for promotions, the conversation is: “What is this person the best at on our team?” If the answer is “they’re okay at everything,” that’s not promotion material. Specialists who’ve become go-to experts in something get recognized and rewarded faster.

🔴 You can’t build a strong portfolio without focus

When you’re trying to show research AND UI design AND strategy AND prototyping, your portfolio is diluted. You have one okay research project, one okay visual design project, one okay strategy project. Someone specialized in research has three excellent research case studies that go deep. They look more hirable.

🔴 Salaries plateau faster for generalists

Market data shows specialists earn 15-25% more than generalists at the same experience level. (Source: Design salary surveys, Glassdoor) Companies pay premium rates for deep expertise in areas they need.

The shift:

→ Years 0-2: Generalist skills help you learn and stay flexible
→ Years 3-5: Specialization becomes necessary to advance
→ Years 5+: Deep expertise in 1-2 areas is expected, with general competence in others

If you stay purely generalist past year 3, your career trajectory flattens. You become the “utility player” who never quite makes it to senior roles.

💡 Reality check: “UX Designer” is not a specialization. It’s a category. What kind of UX designer are you?

The specializations that actually pay more right now

Not all specializations are created equal. Some open doors. Some close them. Here’s what’s actually valuable in the market right now:

💰 High-demand specializations (2025):

→ UX Research (especially generative research)

What it is: Leading discovery, understanding user needs, synthesis, insight generation
Why it pays: Few designers are truly good at research. Most can run a usability test, but deep qualitative research is rare.
Salary boost: 20-30% over general UX roles
Demand: High, especially in product companies

→ Design Systems & Component Design

What it is: Building scalable, flexible design systems that actually work
Why it pays: Every company wants one, few know how to build them well
Salary boost: 15-25% over general product design
Demand: Very high, particularly at companies with multiple products

→ Complex B2B/Enterprise UX

What it is: Designing for workflows with multiple user types, permissions, data-heavy interfaces
Why it pays: B2B is harder than consumer. Fewer designers have the skills. Companies pay for that expertise.
Salary boost: 15-20% over consumer product design
Demand: High and growing

→ AI/ML Product Design

What it is: Designing interfaces for AI features, chatbots, recommendation systems, predictive tools
Why it pays: Emerging space with high demand and low supply of experienced designers
Salary boost: 20-35% over traditional product design
Demand: Exploding, will stay high for years

→ Accessibility & Inclusive Design

What it is: WCAG compliance, designing for disabilities, inclusive research and testing
Why it pays: Legal requirements + ethical imperative + very few true experts
Salary boost: 10-20%, plus job security
Demand: Growing steadily

→ Service Design & Systems Thinking

What it is: Designing end-to-end experiences across channels, understanding ecosystems
Why it pays: Strategic level work, often consulting rates
Salary boost: 25-40% at senior levels
Demand: High in consulting and large enterprises

⚠️ Lower-demand or saturated specializations:

→ UI/Visual Design only
Market is saturated. AI tools are automating parts of this. Still valuable as a secondary skill, risky as only skill.

→ UX Writing (standalone)
Unless you’re at content-heavy products, this is often rolled into other roles. Hard to build a career on this alone.

→ Generic “product design”
Not specific enough. Everyone calls themselves this. Doesn’t differentiate you.

The pattern:

Specializations that pay well are either:

1. ✓ Rare skills with high demand

2. ✓ Complex domains that take years to master

3. ✓ Emerging areas where expertise is scarce

Pick something that fits at least one of these.

How to pick a niche when you don’t know enough yet

Okay, so you need to specialize. But you’re early in your career and you don’t know what you’re best at yet. How do you choose?

❌ Bad way to pick: What sounds coolest

“AI design sounds exciting, I’ll specialize in that.”

Why it fails: You haven’t actually done it. You might hate it. You might not be good at it. You’re choosing based on hype, not fit.

✅ Better way: Notice what you’re naturally drawn to

Look at your existing work and ask:

• What parts of projects energize you?

• What tasks do you volunteer for?

• What do teammates come to you for help with?

• What do you read about in your free time?

Why it works: Your interests reveal your aptitudes. You’ll get good at things you’re intrinsically motivated to do.

✅ Better way: Follow the money/demand

Look at job boards and notice:

• What specific skills are companies desperately hiring for?

• What roles have the fewest qualified candidates?

• What specializations appear in high-paying job posts?

Why it works: Market demand is real data. Specializing in something rare and needed guarantees work and leverage.

✅ Better way: Build on adjacent experience

If you came to UX from:

• Development → Specialize in design systems or complex technical products

• Psychology/research → Specialize in UX research or behavioral design

• Marketing → Specialize in growth design or conversion optimization

• Writing → Specialize in UX writing or content design

Why it works: You have a head start. Your prior skills compound with UX skills to create unique combinations.

✅ Better way: Try multiple things, then commit

Years 1-2: Do generalist work. Try research, UI, strategy, testing. Notice what clicks.
Year 2-3: Start focusing 60-70% of your effort on one area while keeping other skills active.
Year 3+: Commit to a primary specialization with clear secondary skills.

Why it works: You make an informed decision based on real experience, not guesses.

The questions to ask yourself:

→ What UX work do I do where time disappears?
→ What do people compliment me on or ask me to help with?
→ What’s hard for me but satisfying when I get it right?
→ What domain knowledge or skills do I already have that transfer?
→ What specializations have strong job markets?

If 2-3 of these point in the same direction, that’s probably your answer.

🎯 Take-home: Don’t pick randomly. Don’t pick based on hype. Pick based on aptitude + interest + market demand.

Quick interruption. This matters for your trajectory.

🎯 UXCON26: Meet The Specialists Who Actually Made It Work

You know what’s valuable about talking to senior designers who’ve built careers on specialization? They’ll tell you what actually happened, not the curated LinkedIn version.

The research lead who spent two years doing “everything UX” before finally committing to research and doubling their salary in 18 months. The design systems expert who started in visual design, hated it, and pivoted. The AI product designer who saw the wave early and rode it up.

These are the conversations that help you figure out your own path. Not because you’ll copy theirs, but because you’ll hear the decision points, the doubts, the pivots, the moments they knew they made the right call.

UXCON26 has an entire career development track focused on specialization, positioning, and building expertise that actually pays off. Not theory. Real people who’ve done it.

Don't wait... Secure your spot

The people who show up are the ones who get to ask “how did you actually decide?” in person instead of guessing from blog posts.

Let’s talk about shape.

T-shaped vs. I-shaped vs. broken comb (and which you should be)

There are different models for how to think about skill distribution. Here’s what they mean and when each makes sense:

🔷 I-shaped: Deep specialist, narrow focus

What it looks like:

• Expert in one specific area (e.g., UX research)

• Surface-level knowledge of adjacent skills

• Deep vertical expertise, minimal horizontal breadth

Pros: ✓ Can command premium rates as an expert ✓ Clear positioning and personal brand ✓ Hired for very specific, high-value problems

Cons: ✗ Limited flexibility if the market shifts ✗ Can struggle in small teams that need generalists ✗ Risk of becoming irrelevant if specialization becomes obsolete

When it works: Consulting, agencies, large companies with role clarity, established careers (7+ years)

🔷 T-shaped: Deep in one area, broad in others

What it looks like:

• Primary expertise in one domain (the vertical bar)

• General competence across multiple UX skills (the horizontal bar)

• Can go deep when needed, collaborate broadly

Pros: ✓ Balance of expertise and flexibility ✓ Can work independently or in teams ✓ Valued in product companies and startups ✓ Easier to pivot if needed

Cons: ✗ Not as expert as pure specialists in your main area ✗ Not as flexible as true generalists ✗ Requires continuous learning across multiple domains

When it works: Product companies, startups, mid-level roles (3-7 years), most modern UX careers

🔷 Broken Comb: Deep in 2-3 areas, competent in others

What it looks like:

• Two or three “spikes” of deep expertise

• Competence in foundational skills

• Example: Deep in research + design systems, competent in UI and strategy

Pros: ✓ Rare skill combinations make you unique ✓ Can handle complex problems requiring multiple expertises ✓ Higher market value than single specialists ✓ More resilient to market changes

Cons: ✗ Takes longer to develop multiple deep skills ✗ Can feel scattered if spikes aren’t related ✗ Hard to position yourself clearly

When it works: Senior roles (7+ years), strategic positions, niche markets where combined skills are valuable

🔷 Generalist: Broad but shallow

What it looks like:

• Basic competence across many UX skills

• No deep expertise in anything specific

• “Can do a bit of everything”

Pros: ✓ Maximum flexibility ✓ Good for early career exploration ✓ Useful in very small teams

Cons: ✗ Hard to stand out in competitive markets ✗ Lower salary ceiling ✗ Limited career growth past mid-level ✗ Easily replaceable

When it works: Years 0-2, solopreneurship, very small startups, career exploration phase

The recommended path:

→ Years 0-2: Generalist (learn everything)
→ Years 2-5: T-shaped (pick one deep area)
→ Years 5+: Broken comb or deep I (add complementary expertise or go very deep)

Don’t stay generalist forever. By year 3, you should be forming a clear T or starting to specialize.

When generalist skills still matter

Specialization doesn’t mean abandoning everything else. Here’s what you still need to be competent at, regardless of specialization:

✓ Core skills every UX specialist needs:

→ Communication & presentation
You could be the world’s best researcher, but if you can’t present findings clearly, you’re ineffective. Every specialist needs to communicate well.

→ Collaboration & stakeholder management
Design doesn’t happen in a vacuum. You’ll work with PMs, engineers, executives. You need to navigate those relationships regardless of your specialty.

→ Basic design craft
Even if you’re a researcher, you should understand visual hierarchy, interaction patterns, and basic usability principles. You don’t need to be expert-level, but fluency matters.

→ Strategic thinking
Understanding business goals, user needs, and how your work ladders up to impact. Specialists who only do tactical work don’t advance.

→ Prototyping & communication design
Even researchers and strategists need to communicate ideas visually sometimes. Basic Figma/prototyping competence is table stakes.

The rule:

Specialize in 1-2 areas deeply. Stay competent in 4-5 areas broadly.

You’re not trying to be mediocre at everything. You’re trying to be excellent at something specific while remaining a functional team member across the board.

⚠️ Warning: Don’t over-specialize too early

Specializing at year 1 is premature. You haven’t tried enough things to know what you’re actually good at or enjoy. Give yourself 18-24 months of exploration before committing.

Also, specializations shift. AI design wasn’t a category five years ago. Design systems as a discipline is only about a decade old. If you specialize too narrowly in something emerging, you might ride a trend up—or get stranded when it changes.

Pick specializations with staying power. Human-centered research isn’t going anywhere. Complex problem-solving isn’t going anywhere. Being “the Clubhouse designer” was a bad bet.

📦 Resource Corner

T-Shaped Designer Article (IDEO)
Classic article explaining the T-shaped model and why it matters for modern designers.

Designer’s Career Map (Dan Mall)
Visual framework for understanding different career paths and specializations in design.

Salary Tools (Levels.fyi)
Real salary data showing pay differences between specialized and generalist roles across companies.

Career Ladders for Designers
Examples of how different specializations grow and what skills are expected at each level.

The Shape of Design (Frank Chimero)
Not specifically about specialization, but excellent on finding your unique design perspective.

Positioning for Designers (Philip Morgan)
Focused on consultants but applicable to anyone thinking about how to position specialized expertise.

💭 Final Thought

Your career compounds faster when you go deep. You become the go-to person for something specific. You get better opportunities, more interesting problems, higher pay. Specialists build leverage. Generalists stay interchangeable.

Pick your depth. Then build it relentlessly.

--The UXU Team

Maybe you’ve been laid off. Maybe you’re watching your field shift and the job market isn’t responding the way it used to. Maybe you’re applying and hearing nothing back. Or maybe you just feel like you’re running out of time to figure this out.

This workshop was built for exactly that moment.

In four hours, you won’t just learn about AI and the new economy, you’ll use it. You’ll work on your real stuff: your resume, your pitch, your positioning. You’ll leave with something finished and a clearer sense of what to do next.

No jargon. No coding. No theory. Just practical, hands-on work in a room full of people who are serious about their next move, led by people who do this for a living.

RSVP HERE!

July 23, 2025 · 12:00–4:00 PM Silver Spring Civic Building at Veterans Plaza 1 Veterans Pl, Silver Spring, MD 20910

RSVP HERE!

What you’ll walk away with:

✅ A finished output you built during the session

✅ Clarity on where your skills fit right now

✅ Language that lands in interviews and networking

✅ One specific next step, chosen before you leave

This is not a lecture. This is a turning point.

RSVP HERE!

Here’s why listening to users doesn’t mean doing what they say, how to identify the actual problem underneath feature requests, and what to ask before you waste months solving the wrong thing.

In this issue we’ll cover:

• Why feature requests are symptoms, not solutions

• The questions users answer vs. the questions you should ask

• How to dig past surface requests to real needs

• Red flags that you’re solving the wrong problem

• What to do when stakeholders and users want different things

• 📦 Resource Corner

• 💭 Final Thought

Why feature requests are symptoms, not solutions

Someone submits a feature request: “We need dark mode.”

You could just build dark mode. Or you could ask: why do they want dark mode?

Possible real reasons:

• Eye strain from bright screens during long sessions

• Working late at night and the bright UI is disruptive

• Accessibility needs for light sensitivity

• They’ve seen it in other apps and expect it

• They think it looks more professional

Each of these suggests a different solution. Maybe the real fix is reducing overall brightness, not adding dark mode. Maybe it’s better contrast ratios. Maybe it’s scheduled themes. Maybe it’s nothing to do with color at all.

The pattern:

Users experience a problem → They imagine a solution → They request that solution as a feature

But their imagined solution might not be the best one. Or even a good one.

Example 1: “We need bulk edit”

What users say: “I want to edit multiple items at once.”

What they might actually need:

• Faster editing of individual items (better shortcuts, autofill)

• Fewer errors to fix (better validation upfront)

• Templates for common patterns (so they don’t need to edit)

• Smart defaults that reduce manual work

Building bulk edit solves the stated request but might miss the real inefficiency in their workflow.

Example 2: “We need more filter options”

What users say: “Add filters for date range, status, category, and tags.”

What they might actually need:

• Better search that finds things without complex filtering

• Saved views for common filter combinations

• AI-powered suggestions that surface relevant items automatically

• Less data clutter so filtering isn’t necessary

Adding more filters makes the interface more complex. The real problem might be information overload, not lack of filtering capability.

Example 3: “We need better notifications”

What users say: “Send me notifications for every update.”

What they might actually need:

• Fewer updates worth notifying about (reduce noise)

• Better in-app indicators they can check when ready (pull vs. push)

• Digest summaries instead of individual pings

• Confidence that they won’t miss critical updates (trust issue)

Building more notifications creates notification fatigue. The real need might be the opposite: less interruption, more control.

The lesson:

Feature requests tell you where users are experiencing friction. They don’t tell you the best way to remove that friction.

Your job isn’t to build what users request. Your job is to solve the problem they’re experiencing.

💡 Reality check: If you just build requested features, you’re a feature factory, not a problem solver.

The questions users answer vs. the questions you should ask

Users are bad at articulating their needs. Not because they’re dumb, but because they’re not designers. They describe symptoms and suggest solutions based on patterns they’ve seen elsewhere.

Your job is to ask better questions that reveal the actual problem.

❌ Bad question: “What features do you want?”

Why it fails: You get a wish list of features, not insights into problems. Users suggest things they’ve seen elsewhere without knowing if those things would actually help them.

✅ Better question: “What’s frustrating about how you currently do this?”

Why it works: You learn about pain points, not preconceived solutions. You can design solutions they haven’t imagined.

❌ Bad question: “Would you use this feature if we built it?”

Why it fails: Users always say yes to hypotheticals. They imagine the best-case version and overlook downsides. Then you build it and they don’t use it.

✅ Better question: “Show me how you do this task right now.”

Why it works: Observation beats speculation. You see the actual workflow, workarounds, and context. You spot problems they’ve normalized and don’t even mention.

❌ Bad question: “How often do you need to do X?”

Why it fails: Memory is unreliable. Users overestimate frequency of things they think they should do and underestimate habitual actions. The data is wrong.

✅ Better question: “Walk me through the last time you did X.”

Why it works: Specific recent examples are more accurate than general patterns. You get real details about context, sequence, and obstacles.

❌ Bad question: “Why don’t you use feature Y?”

Why it fails: Users rationalize after the fact. They give you logical-sounding reasons that might not be the real cause of their behavior.

✅ Better question: “Can you try using feature Y while I watch?”

Why it works: You see the actual barriers. Discoverability issues. Confusing UX. Mismatched mental models. Things users couldn’t articulate in abstract conversation.

❌ Bad question: “What would make this better?”

Why it fails: Too broad. You get vague answers like “make it faster” or “make it easier” without actionable specifics.

✅ Better question: “What almost stopped you from completing this task?”

Why it works: Focuses on specific friction points. You learn what nearly caused failure, which reveals high-priority problems.

The pattern:

Stop asking users to design solutions. Start asking them to describe their experience, show their workflow, and explain their struggles.

The insights come from observation and specific examples, not hypotheticals and generalizations.

How to dig past surface requests to real needs

Someone says “we need feature X.” Here’s your playbook for finding the real problem:

Step 1: Ask “what are you trying to accomplish?”

Get them out of solution mode and into goal mode.

User: “We need an export to Excel button.”
You: “What are you trying to do with the data once it’s in Excel?”
User: “I need to add a column with some calculations, then share it with my manager.”

Real need: Might not be export. Might be adding custom calculations in-app, or better sharing options, or a report template that does the calculations automatically.

Step 2: Ask “what happens if you don’t have this?”

Understand the consequences. Is this a critical blocker or a nice-to-have?

User: “We need dark mode.”
You: “What happens if we don’t add dark mode?”
User: “I get eye strain working late and have to lower my screen brightness, which makes it hard to see details.”

Real need: Reducing eye strain. Dark mode is one solution. Better contrast, adjustable UI brightness, or night-shift color temperature might also work.

Step 3: Ask “how do you solve this problem today?”

Their current workaround reveals what they actually need and how much friction they’re willing to tolerate.

User: “We need bulk actions.”
You: “How do you handle this now when you need to update multiple items?”
User: “I export to a spreadsheet, make changes there, then manually re-enter the data.”

Real need: The workaround is incredibly painful, so bulk actions are genuinely valuable. But you also learned they’re comfortable with spreadsheet workflows, which might inform the design.

Step 4: Ask “can you show me an example?”

Abstract requests become concrete when grounded in real scenarios.

User: “We need better search.”
You: “Can you show me a recent search that didn’t work well?”
User: “I searched for ‘Johnson project proposal’ and it didn’t find the document even though I know it exists.”

Real need: The search can’t handle multi-word queries or doesn’t index document content. That’s a specific, solvable problem different from generic “better search.”

Step 5: Ask “what would success look like?”

Help them articulate the desired outcome rather than the requested feature.

User: “We need more customization options.”
You: “If you could customize exactly what you needed, what would that let you do?”
User: “I’d set up my dashboard to show only the projects I’m actively working on, not everything.”

Real need: Filtering, not customization. A “my active projects” view solves this without adding complex customization UI.

The goal:

By the end of this questioning, you should understand:

• ✓ The actual problem they’re experiencing

• ✓ Why it’s a problem (context and consequences)

• ✓ How they currently cope with it

• ✓ What success would look like

Only then do you start designing solutions.

🎯 Take-home: Spend more time understanding the problem than building the solution. Get the problem right, and the solution becomes obvious.

Quick pause for something important….

🎯 UXCON26: Learn Problem-Framing From People Who’ve Solved Real Ones

That skill, knowing what problem to solve, is worth more than any tool or technique. And you can’t learn it from articles. You learn it from people who’ve done it, made mistakes, and figured it out.

At UXCON26, you’ll meet UXers who know exactly how to do that. The ones who’ve learnt to say “I don’t think we’re solving the right problem” in rooms full of executives. The ones who’ve killed projects that would’ve wasted months. The ones who know how to dig until they find the real need.

Don't wait... Secure your spot

The conversations between sessions? The workshops on discovery and problem framing? That’s where this stuff actually sinks in.

Back to identifying the real problem.

Red flags that you’re solving the wrong problem

Sometimes you don’t catch it during discovery. You’re already designing or building. Here are the warning signs that you’re on the wrong track:

🚩 Red flag 1: Nobody can clearly articulate the user problem

You ask “what problem does this solve?” and get vague answers like:

• “It makes things easier”

• “Users have been asking for it”

• “Competitors have it”

• “It’s a nice-to-have”

What it means: You’re building a feature, not solving a problem. Stop and do actual problem discovery.

🚩 Red flag 2: The solution came before the research

The stakeholder already decided what to build before talking to users. Research is being done to validate the predetermined solution, not explore the problem.

What it means: You’re doing confirmation bias research. The feature might work, but you’re not optimizing for the real need.

🚩 Red flag 3: Every user describes the problem differently

You interview five users and get five different explanations of what’s wrong. There’s no common thread or pattern.

What it means: Either you’re talking to the wrong users, asking the wrong questions, or there isn’t actually a coherent problem to solve.

🚩 Red flag 4: The proposed solution is very complex

The design requires 17 steps, multiple new screens, and extensive user education. It feels overbuilt.

What it means: You might be solving the wrong problem. Good solutions to real problems are usually simpler than this.

🚩 Red flag 5: Users don’t seem excited when you show them

You demo the solution and get lukewarm reactions. “That’s nice” instead of “oh wow, this solves my problem.”

What it means: It’s not addressing the pain point they actually care about. Go back to problem definition.

🚩 Red flag 6: The success metrics are activity-based, not outcome-based

You’re measuring “number of times feature is used” instead of “how much time/money users saved” or “reduction in error rate.”

What it means: You don’t actually know if this solves a meaningful problem. Activity metrics can be gamed or meaningless.

When you spot these flags:

Stop. Don’t build more. Go back to problem discovery.

It’s painful to hit pause. But shipping the wrong thing wastes more time than pausing to get it right.

What to do when stakeholders and users want different things

This is the classic dilemma: users want X, but stakeholders want Y. How do you navigate this?

Scenario 1: Business goal conflicts with user need

Example: Users want a simpler checkout with fewer steps. Business wants to collect more customer data during checkout.

How to handle it:

• Find the underlying needs on both sides

• Business needs data for marketing. Why? To send relevant offers.

• Users need speed. Why? They’re buying impulsively and abandon if it takes too long.

• Solution space: Collect data post-purchase. Fast checkout now, profile building later. Both needs met.

The principle: Don’t compromise. Find solutions that serve both needs. They usually exist if you reframe the problem.

Scenario 2: Stakeholder wants a feature users haven’t requested

Example: Executive wants AI-powered recommendations. Users never mentioned needing this.

How to handle it:

• Ask the stakeholder: “What problem does this solve for users or the business?”

• If there’s a valid problem (increasing engagement, reducing choice paralysis), research if users actually experience it.

• If users don’t have this problem, show data and propose alternatives that address the real user needs.

• If the stakeholder insists anyway, document the decision and proceed (you won’t win every battle).

The principle: Seek to understand the stakeholder’s goal, not just reject their idea. Sometimes they see a problem you missed. Sometimes they’re wrong.

Scenario 3: Users request something that would hurt the business

Example: Users want to remove all ads. That’s the revenue model.

How to handle it:

• Understand what users actually dislike (intrusive ads? Too many? Irrelevant?)

• Find ways to reduce the pain without killing the business model

• Solution space: Fewer ads, better targeted, less intrusive formats. Better, not gone.

The principle: Users don’t care about your business model, but you do. Find ways to reduce friction while maintaining viability.

The balance:

You serve both users and the business. Great design finds solutions that create value for both. Compromise is a last resort, not the first option.

📦 Resource Corner

The Mom Test by Rob Fitzpatrick
Essential reading on asking questions that reveal real problems instead of validating your assumptions.

Jobs to Be Done Framework
Methodology for understanding what users are actually trying to accomplish, not what features they request.

Just Enough Research by Erika Hall
Practical guide on doing research that uncovers real problems rather than confirming biases.

Competing Against Luck (Clayton Christensen)
Deep dive into understanding customer needs through the jobs-to-be-done lens.

Good Strategy/Bad Strategy (Richard Rumelt)
Not UX-specific, but excellent on problem diagnosis and why most strategies fail by solving the wrong problem.

Continuous Discovery Habits (Teresa Torres)
Modern approach to ongoing problem discovery rather than one-time research projects.

💭 Final Thought

The hardest part of design isn’t making things look good. It’s figuring out what to make in the first place.

Teams waste months building features nobody uses because they never questioned whether they were solving the right problem. They heard requests, added them to the roadmap, and shipped solutions to problems that didn’t actually exist.

Real design work happens before Figma opens. It’s in the questions you ask, the observations you make, the patterns you notice, and the assumptions you challenge. It’s saying “I don’t think we understand the problem yet” when everyone else wants to start building.

That’s uncomfortable. Stakeholders want solutions, not more questions. Users think they know what they need. Timelines are tight. The pressure to just build something is intense.

But solving the wrong problem perfectly is still failure. It just takes longer to realize it.

--The UXU Team

You sent your portfolio link. The hiring manager opened it. Three minutes later, they moved on to the next candidate. Not because your designs are bad, they might be great. But because they couldn’t figure out what they were looking at. Unlabeled artboards. Random layer names. No clear explanation of what problem you solved or why. Your Figma file is a chaotic mess, and it’s screaming “I don’t have my shit together.”

Here’s why file organization matters more than you think, and how to fix it before your next application.

In this issue:

• Why portfolio presentation kills more applications than bad design

• What hiring managers actually look for in the first 60 seconds

• The organization signals that separate juniors from seniors

• How to structure case studies people actually want to read

• The naming conventions that make you look professional

• 📦 Resource Corner

Why portfolio presentation kills more applications than bad design

Let’s be direct: most portfolios get rejected for presentation issues, not design issues.

Hiring managers look at 30-50 portfolios per role. They spend 2-3 minutes max on each one during initial screening. If they can’t quickly understand your work, they move on. It doesn’t matter how good the design is if they never get to it.

Here’s what kills portfolios instantly:

🚫 No clear entry point or structure
They open your Figma file and see 47 unnamed pages scattered randomly. No table of contents. No clear starting point. They have no idea where to begin or what order to view things.

🚫 Walls of text with no visual hierarchy
Paragraphs of explanation crammed into tiny text boxes. No headlines. No sections. No breathing room. Their eyes glaze over before they read a single word.

🚫 Designs with zero context
Beautiful screens with no explanation of what problem you were solving, who you designed for, or what happened after you shipped it. Just pretty pixels floating in space.

🚫 Layers and pages named “Frame 234” and “Rectangle 47”
This signals sloppiness. If you can’t be bothered to name things clearly in your portfolio (the thing you’re using to get hired), how will you work on a real team?

🚫 Inconsistent formatting across case studies
One project has detailed research. Another jumps straight to final designs. Another has process but no outcomes. The inconsistency makes you look unprofessional or inexperienced.

The brutal truth:

Presentation quality is a proxy for work quality. Hiring managers assume:

• Organized files = organized thinking

• Clear explanations = clear communication

• Thoughtful structure = thoughtful process

• Messy presentation = messy designer

Fair or not, that’s the reality. Your file organization is being judged as hard as your design work.

What hiring managers actually look for in the first 60 seconds

You have one minute to hook someone. Here’s exactly what they’re scanning for:

0-10 seconds: Visual first impression

✓ Does this look professional and polished?
✓ Is there clear visual hierarchy?
✓ Can I immediately tell what I’m looking at?

They’re not reading yet. They’re just scanning to see if this is worth their time.

10-30 seconds: Project context

✓ What problem did this solve?
✓ What was your role?
✓ Is this real work or practice?

They need to understand what they’re evaluating quickly. If they have to hunt for this information, they won’t.

30-60 seconds: Deciding whether to invest more time

✓ Does this person think like a designer?
✓ Is there evidence of process and reasoning?
✓ Can they communicate clearly?

By one minute, they’ve decided: keep reading or move on. Most files get discarded here.

What this means for you:

Your first page, your first project, your first impression needs to work in 60 seconds. Everything else is extra. If you don’t hook them immediately, they never see your best work.

Quick break. This matters.

AI won’t replace designers. But it will expose them.

Because when AI can generate anything, wireframes, copy, flows, prototypes, the only thing left that's truly yours is your judgment.

And most designers haven't trained for that.

That's exactly what Edward Cupps is here to challenge at UXCON26.

Edward is a senior UX strategist who has spent years helping teams move beyond deliverables and into decision-making. At UXCON26, he'll break down what it actually means to lead with judgment in an AI-powered world, how to stay relevant, stay valuable, and show up as the designer who shapes outcomes, not just executes them.

This is the conversation the industry has been avoiding. Edward's bringing it to the stage.

Dont wait: Secure your spot

Back to organizing your files.

The organization signals that separate juniors from seniors

File organization reveals experience level faster than almost anything else. Here’s what separates different levels:

🟥 Junior/student signals:

→ Projects dumped on pages with no structure or order
→ Everything labeled “Untitled” or auto-generated names
→ Artboards scattered randomly with no alignment
→ Process work mixed with final work with no clear separation
→ Inconsistent presentation style across projects
→ No clear narrative or explanation of thinking

What it says: “I haven’t worked professionally yet. I don’t know how to present work for review.”

🟨 Mid-level signals:

→ Clear project sections with consistent formatting
→ Labeled pages and frames that make sense
→ Process shown but organized (research → wireframes → final)
→ Context provided for each project
→ Clean visual presentation
→ Some attention to detail in file organization

What it says: “I’ve worked on teams. I know how to present work. I understand professional standards.”

🟩 Senior signals:

→ Table of contents or clear navigation structure
→ Each project tells a story with clear beginning/middle/end
→ Strategic framing (why this mattered, what changed)
→ Evidence of thinking at systems level, not just screens
→ Thoughtful use of annotations and explanations
→ File feels like it was designed, not just assembled

What it says: “I think strategically. I communicate effectively. I understand what stakeholders need to see.”

The difference isn’t talent. It’s intentionality.

Juniors throw work in a file. Seniors design their portfolio presentation as carefully as they design products. That distinction is visible in the first 30 seconds.

💡 Reality check: Your Figma file IS a design project. Treat it like one.

How to structure case studies people actually want to read

Case studies fail when designers write what they want to say instead of what readers need to know. Here’s a structure that actually works:

📍 Page 1: Project Overview (the hook)

Answer these questions immediately:

→ Project name + one-sentence description
“Redesigning checkout flow for an e-commerce platform”

→ Your role (be specific)
“Lead designer. I conducted research, designed solutions, and collaborated with 1 PM and 2 developers.”

→ Timeline
“6 weeks, March-April 2024”

→ The core problem
“Users were abandoning cart at 68% rate due to confusing multi-step checkout.”

→ The outcome
“Reduced abandonment to 34% and increased completed purchases by $47K/month.”

Why this works: Everything a hiring manager needs to evaluate the project is visible immediately. They can decide if they want to read more.

📍 Pages 2-3: The Problem & Research

→ Show you understand the user and business context
→ Include key research insights (2-3 max, not everything)
→ Use quotes, data, or observations to make it concrete
→ Keep it visual: photos from research, graphs, user journey maps

Avoid: Walls of text explaining your entire research process. Nobody cares about every interview question. Show the insights that drove design decisions.

📍 Pages 4-6: Process & Exploration

→ Show sketches, wireframes, or early concepts
→ Explain what you tried and why
→ Show iteration based on feedback or testing
→ Make it clear you didn’t just design one thing and call it done

Avoid: Showing 47 variations of the same screen. Curate. Show 2-3 meaningful explorations with clear rationale for each.

📍 Pages 7-9: Solution

→ High-fidelity designs with context
→ Annotations explaining key decisions
→ Interactions or flows if relevant
→ Before/after comparisons if applicable

Avoid: Just dumping screens with no explanation. Every design choice should have visible reasoning.

📍 Page 10: Impact & Reflection

→ What happened after you shipped?
→ Metrics if you have them (be honest if you don’t)
→ What you learned
→ What you’d do differently next time

Avoid: Making up numbers or pretending everything went perfectly. Honesty about limitations builds more credibility than fake perfection.

The pattern:

Problem → Research → Process → Solution → Impact

This narrative arc works because it mirrors how design actually happens. Don’t deviate from it unless you have a very good reason.

The naming conventions that make you look professional

This sounds boring. It is boring. It also separates people who get interviews from people who don’t.

✅ Page naming that makes sense:

→ “00 - Table of Contents”
→ “01 - Project: Checkout Redesign”
→ “02 - Project: Mobile App Onboarding”
→ “03 - About Me”

Why it works: Clear order. Scannable at a glance. Easy to navigate.

✅ Frame naming that shows thinking:

→ “Research Findings - Key Insights”
→ “Wireframes - V2 (after user testing)”
→ “Final Designs - Mobile”
→ “Annotated Flow - Happy Path”

Why it works: The name tells you what you’re looking at and what version/context it represents.

✅ Layer naming that’s actually useful:

→ “CTA Button - Primary”
→ “Navigation - Desktop”
→ “Form Field - Error State”

Why it works: Anyone (including developers) can understand your file structure. Signals you think about handoff and collaboration.

❌ What not to do:

→ “Frame 4738”
→ “Rectangle 234 copy 3”
→ “asdfasdf”
→ “NEW NEW FINAL final FINAL v2”
→ “Untitled” (the default for everything)

Why it fails: Looks sloppy. Signals you don’t care about craft or details.

The rule:

If someone who’s never seen your file before can’t understand what they’re looking at within 10 seconds, your naming is broken. Fix it.

🎯 Take-home: Naming isn’t about being anal-retentive. It’s about respecting other people’s time and showing you think systematically.

📦 Resource Corner

Bestfolios
Curated collection of strong portfolios. Study how the best ones are organized and presented.

Case Study Club
Real case studies with good structure. Notice the narrative flow and information hierarchy.

Cofolios
More portfolio examples with filtering. Look specifically at organization and presentation, not just design quality.

Figma Best Practices
Official Figma guidance on file organization, naming, and structure. Basic but solid.

How to Present Design Work (NN/g)
Research-backed article on communicating design effectively. Applies directly to portfolio presentation.

UX Portfolio Formula
Specific templates and structures for case studies. Good starting point if you’re totally lost.

💭 Final Thought

Messy files don’t just look bad. They reveal how you think, how you work, and how much you care about craft. And hiring managers see that immediately.

Clean it up. Name things properly. Structure your stories clearly. Make it easy for people to see how good you actually are.

Your work might be great. Make sure people can actually see it.

--The UXU Team

“What defines your work isn’t just what you build - it’s the perspective you bring to every decision behind it.”

That one landed differently.

Because if you’re honest with yourself, the gap between the designer you are and the designer you want to be isn’t a skills gap. It’s not a tools gap. It’s not even an experience gap.

It’s a clarity gap.

Clarity about what you actually stand for. Clarity about why you make the calls you make. Clarity that holds up under pressure - when the deadline moves, when the stakeholder pushes back, when the team is exhausted and someone has to be the person who says this isn’t right for the user.

Amanda calls it aligning your principles with your practice. And she’s right that most of us were never taught how to do that. We were taught Figma. We were taught research methods. We were taught how to present to a room.

Nobody taught us how to stay human when everything around us is asking us not to be.

That’s what Amanda is bringing to UXCON26. And she’s one of nine speakers doing exactly that.

Join Amanda Gelb at UXCON26

October 8th. Silver Spring Civic Center, MD. One day.

Here is who else is in the room with you:

Don Norman the man who literally invented the term “user experience” - is delivering the keynote and taking live questions from the room. Alongside him, designers and leaders from Netflix, The New York Times, Target, and more. People doing serious work at the organizations whose products you use every single day.

Here’s the thing nobody says out loud about conferences.

The talk you remember isn’t always the keynote. Sometimes it’s the conversation at the coffee station where someone says exactly the thing you needed to hear. Sometimes it’s realising the person next to you has been wrestling with the same problem for six months.

That only happens when the right people are in the room.

Fun Fact: 80% of roles are filled before they are ever posted. Not through job boards. Through conversations exactly like the ones that happen at UXCON - between practitioners, leaders, and decision-makers from organizations like Harvard, IBM, Adobe, Johns Hopkins, Lockheed Martin, The Met, NIH, and Vanguard.

One day in that room compounds for years.

Be in the "ROOM"

Amanda said it better than we ever could.

Your work is defined by the perspective you bring to every decision behind it.

October 8th is a decision.

Need more info?

Find out here!

Questions? info@uxconference.org

And without trust, even perfect AI is useless. This issue breaks down why users reject AI features, what trust actually requires, and how to design AI experiences that people choose to use.

In this issue:

• Why users avoid your AI features (even when they work)

• The trust gap AI creates that traditional features don’t

• What makes people trust (or distrust) automated decisions

• Design patterns that build AI trust vs. destroy it

• How to handle AI failures without losing users forever

• 📦 Resource Corner

Why users avoid your AI features (even when they work)

You shipped an AI feature. It’s technically impressive. The accuracy is high. It saves time. And almost nobody uses it.

Here’s what’s probably happening:

Users don’t trust it because they can’t see how it works.

Traditional features are transparent. Click a button, something happens, you understand the cause and effect. AI features are black boxes. Something happens automatically, and users have no idea why or how. That opacity breeds distrust.

Here are the specific trust barriers AI creates:

🚫 Lack of control When AI makes decisions for you, you feel powerless. If it gets something wrong and you don’t know how to correct it, the feature feels dangerous instead of helpful. Users would rather do things manually where they have control than trust automation they can’t steer.

🚫 Unpredictability Traditional features are consistent. The same input produces the same output. AI features are probabilistic. They might work great today and fail tomorrow on similar inputs. That unpredictability makes users anxious.

🚫 No explanation for decisions AI suggests something or auto-fills something, and users ask “why did it choose this?” If there’s no answer, they assume it’s random or wrong. They need to understand the reasoning to trust the output.

🚫 High stakes mistakes When AI gets something wrong in a high-stakes context (financial, medical, legal, anything with consequences), that single failure destroys trust permanently. Users remember the one time it failed more than the 99 times it worked.

🚫 Creepiness factor When AI is too accurate or knows too much, it crosses from helpful to creepy. “How did it know that?” is not always a positive reaction. Users start wondering what data you’re collecting and how you’re using it.

🚫 Lack of agency People want to feel like they’re making decisions, not that decisions are being made for them. Even when AI suggestions are correct, users resent feeling like the AI is taking over their role or judgment.

The research backs this up: Studies show that people prefer worse outcomes they chose themselves over better outcomes chosen by AI they don’t understand. Control and understanding matter more than optimization. (Source: “Algorithm Aversion” research, Berkeley Dietvorst et al.)

The trust gap AI creates that traditional features don’t

Traditional software has a simple trust model: you tell it what to do, it does exactly that, you verify the result. The loop is clear and controllable.

AI breaks this model. It acts autonomously. It makes inferences. It surprises you (sometimes positively, sometimes not). That creates a fundamentally different trust problem.

Here’s what changes with AI:

Traditional feature: “I clicked save. The file saved. I see confirmation. I trust this worked.”

AI feature: “The AI organized my files. I don’t know how it decided which files go where. I can’t verify it’s correct without manually checking everything. Do I trust this?”

The difference: With traditional features, verification is easy. With AI, verification is often harder than just doing the task yourself. So users don’t adopt it.

Another example:

Traditional feature: “I set up a filter to sort emails by sender. I know exactly what it’s doing. I can modify the rules if it’s wrong.”

AI feature: “The AI sorted my emails into categories. I don’t know what rules it’s using. I can’t adjust them. Some emails ended up in the wrong category and I don’t know why.”

The difference: Understanding and control. Users trust what they understand and can control. AI removes both.

This creates specific design challenges:

🔹 Explainability: Can users understand why the AI made a decision? 🔹 Correctability: Can users fix it when the AI is wrong? 🔹 Predictability: Can users anticipate what the AI will do? 🔹 Transparency: Can users see what data the AI is using? 🔹 Opt-out: Can users turn it off and go back to manual control?

Most AI features fail at multiple of these. That’s why users don’t trust them, even when the underlying technology is good.

What makes people trust (or distrust) automated decisions

Trust isn’t binary. It’s built through specific signals and destroyed by specific failures. Let’s get concrete about what creates and breaks trust in AI features.

What builds trust in AI:

✅ Showing your work When the AI explains its reasoning, users can evaluate whether that reasoning makes sense. “I suggested this article because you read similar topics last week” is trustable. “Here’s a suggested article” with no explanation is not.

✅ Starting small and earning trust over time AI features that begin with low-stakes suggestions and gradually take on more responsibility build trust. Jumping straight to high-stakes automation breaks it. (Source: Progressive Trust research, MIT)

✅ Letting users verify before committing “Here’s what I’ll do, confirm to proceed” beats “I already did this” by a massive margin. Preview and confirm gives users control. Auto-execution without confirmation feels reckless.

✅ Being transparent about confidence levels “I’m 95% confident this is correct” vs “I’m 60% confident, you should double-check” sets appropriate expectations. Users can decide how much to trust based on stated confidence.

✅ Providing easy undo If users know they can reverse AI decisions easily, they’re more willing to try them. “Undo” is a trust-building feature, not just a correction mechanism.

✅ Explaining limitations upfront “This works well for X but struggles with Y” builds more trust than pretending the AI is perfect and having users discover the limitations through failure.

What destroys trust in AI:

❌ One bad outcome in a high-stakes context AI that gets financial calculations wrong once, medical suggestions wrong once, or legal advice wrong once loses trust permanently. High-stakes failures have disproportionate impact.

❌ Inconsistency If the AI gives different answers to the same question at different times without clear reason, users conclude it’s unreliable and stop using it.

❌ No explanation when users ask “why?” If users can’t understand why the AI made a decision and the system doesn’t explain, they assume it’s arbitrary or broken.

❌ False confidence When AI presents wrong answers with the same confidence as right answers, users can’t calibrate their trust. They either trust nothing or trust everything and get burned.

❌ Taking away control without permission Auto-applying AI suggestions without user confirmation feels invasive. Users want to be in the loop, not replaced by the loop.

❌ Opaque data usage When users don’t know what data the AI is using or how it’s being stored, privacy concerns override any functional benefits. “What does this have access to?” becomes the dominant question.

💡 Reality check: Users don’t need perfect AI. They need AI they can understand, verify, and control. Accuracy matters less than explainability.

Real quick. This matters for your career.

🎯 UXCON26: Where AI Meets Real Design Problems

You know what’s funny about the AI conversation in UX right now? Everyone’s talking about it. Almost nobody’s doing it well. The gap between AI hype and AI that users actually trust is massive.

That gap is where opportunities are. The designers who figure out how to make AI features trustable, explainable, and actually useful? They’re going to be in demand for the next decade.

UXCon26 has an entire track on designing for AI and emerging tech. Not the hype. Not the speculation. The actual design patterns that work. The research on trust. The case studies from teams who shipped AI features users love instead of avoid.

You could wait for all this to become blog posts and online courses six months from now. Or you could learn it directly from the people solving these problems right now.

The designers who understand AI trust design before everyone else figures it out? They’re not going to struggle for work.

Secure your spot here!

Alright, back to building trust.

Design patterns that build AI trust vs. destroy it

Let’s get specific about interface patterns. Some design choices build trust in AI features. Some destroy it. Here’s what works and what doesn’t.

Pattern 1: Suggestion vs. Auto-execution

❌ Trust-destroying: AI automatically completes your sentence, fills in form fields, or takes action without asking.

✅ Trust-building: AI suggests completions, shows preview of what it would fill in, and waits for confirmation before acting.

Why it works: Users stay in control. They evaluate the AI’s suggestion and decide whether to accept it. This builds confidence in the AI’s judgment over time.

Example: Gmail’s Smart Compose suggests text but doesn’t auto-send. Grammarly suggests edits but doesn’t auto-apply them. You choose what to accept.

Pattern 2: Explanation on demand

❌ Trust-destroying: AI makes a decision with no explanation available anywhere.

✅ Trust-building: AI provides a clear, simple explanation that users can access when they want it. “Why this recommendation?” link or tooltip.

Why it works: Users who want to understand can understand. Users who just want results can skip the explanation. Both groups are served.

Example: Spotify’s “Why this song?” feature shows why songs appear in your recommendations. Netflix used to have this. Users trusted recommendations more when explanations were available. (Source: Netflix recommendation research)

Pattern 3: Confidence indicators

❌ Trust-destroying: AI presents all outputs with equal confidence, whether it’s sure or guessing.

✅ Trust-building: AI clearly communicates confidence: “High confidence,” “Medium confidence,” “This is a guess, please verify.”

Why it works: Users can calibrate their trust appropriately. They know when to rely on AI and when to double-check manually.

Example: Google Maps shows “Uncertain traffic conditions” when it doesn’t have good data. Weather apps show confidence ranges. This sets appropriate expectations.

Pattern 4: Human-in-the-loop for high-stakes decisions

❌ Trust-destroying: AI makes high-stakes decisions (financial, medical, legal) autonomously.

✅ Trust-building: AI provides analysis and suggestions, but always requires human confirmation for consequential actions.

Why it works: Accountability stays with humans. Users don’t feel like they’re handing over critical decisions to a black box.

Example: Medical diagnosis AI assists doctors, doesn’t replace them. Financial planning AI suggests strategies, doesn’t auto-execute trades.

Pattern 5: Progressive disclosure of AI involvement

❌ Trust-destroying: Hiding that AI is involved, then users discover it later and feel deceived.

✅ Trust-building: Being upfront about AI involvement but not making it the focus. “AI-assisted” or “Smart suggestions powered by AI.”

Why it works: Transparency builds trust. Users appreciate knowing when they’re interacting with AI vs. deterministic logic.

Example: GitHub Copilot is clearly labeled as AI. Notion AI is clearly indicated with special formatting. No surprises.

Pattern 6: Easy correction and feedback

❌ Trust-destroying: When AI is wrong, users can’t easily fix it or teach it to do better.

✅ Trust-building: One-click correction: “Not what I wanted” or thumbs down. Bonus points if users can see the AI improve based on their feedback.

Why it works: Users feel heard and in control. They’re training the AI to work better for them specifically, which increases investment and trust.

Example: Spotify’s “Don’t play this artist” immediately updates recommendations. Users see their feedback matter.

Pattern 7: Graceful degradation and fallback

❌ Trust-destroying: When AI fails, the entire feature breaks or gives an unhelpful error.

✅ Trust-building: When AI fails, system gracefully falls back to manual mode or provides a clear alternative path.

Why it works: Users don’t get stuck. AI becomes an enhancement, not a dependency. Trust remains even when AI fails because the product still works.

Example: Voice assistants that fall back to manual controls. Search that falls back to traditional keyword search when AI interpretation fails.

How to handle AI failures without losing users forever

AI will fail. That’s not a question of if, but when. How you handle those failures determines whether users keep trusting you or abandon the feature entirely.

Strategy 1: Acknowledge failures immediately and specifically

Don’t hide errors. Don’t blame users. Don’t give generic “something went wrong” messages.

❌ “An error occurred. Please try again.” ✅ “I couldn’t understand that request. Try rephrasing it, or use the manual option below.”

The second version tells users what went wrong and gives them a path forward.

Strategy 2: Make it easy to report problems

Add a visible “This isn’t right” or “Report issue” button directly on AI-generated content. Make it one click to flag problems.

Then actually review those reports and improve the AI based on them. If users see their feedback leading to improvements, they’ll stick with you through failures.

Strategy 3: Set expectations about AI limitations upfront

Don’t oversell your AI’s capabilities. Be honest about what it can and can’t do.

✅ “This feature works best with English text and may struggle with technical jargon.” ✅ “AI suggestions are based on common patterns and might not fit your specific needs.”

When users know the limitations, failures feel expected rather than shocking.

Strategy 4: Provide manual alternatives alongside AI

Never make AI the only way to accomplish something. Always offer a manual path.

If the AI search fails, traditional keyword search should still work. If AI writing assistant gets stuck, manual writing should still be possible. Users need escape hatches.

Strategy 5: Learn from failures publicly (when appropriate)

If your AI feature has a public failure, acknowledge it and explain what you’re doing to fix it. Transparency builds trust even in failure.

Example: When GitHub Copilot suggested copyrighted code, they acknowledged the problem and explained their mitigation efforts. Users appreciated the honesty.

Strategy 6: Don’t let one domain failure contaminate everything

If your AI writing assistant fails at technical documentation but works well for marketing copy, make sure users know that. Segment trust by use case.

“This feature works well for X but we’re still improving it for Y” lets users trust selectively rather than rejecting the whole feature.

🎯 Take-home: Users will forgive AI failures if you’re honest about them, provide alternatives, and show you’re improving. What they won’t forgive is hiding failures or blaming them for the AI’s mistakes.

📦 Resource Corner

People + AI Guidebook (Google) Comprehensive resource from Google on designing AI experiences users can trust. Covers explainability, feedback, errors, and more with real examples.

Human-Centered AI (Stanford HAI) Research and guidelines on making AI systems that work with humans rather than replacing them. Strong on trust and transparency.

IBM Design for AI IBM’s design principles and patterns for AI products. Good practical examples of trust-building interfaces.

Algorithm Aversion Research (Wharton) Academic research on why people distrust algorithms even when they’re more accurate than humans. Essential reading for understanding AI trust.

Designing for Trust (IDEO) Case studies and frameworks for building trust in digital products, including AI-powered ones.

AI Incident Database Real-world examples of AI failures and their consequences. Study these to understand what can go wrong and how to prevent it.

The UX of AI (Josh Clark) Book focused specifically on interface design patterns for AI and machine learning features. Practical and example-heavy.

💭 Final Thought

The AI race is creating a weird paradox: companies are frantically building AI features to stay competitive, but users are increasingly skeptical and resistant to using them.

You can have the most technically sophisticated AI in the world. Perfect accuracy. Lightning-fast responses. Cutting-edge capabilities. And if users don’t trust it, they won’t use it. You’ve built expensive technology that sits unused.

The winners in AI won’t be the companies with the best models. They’ll be the companies that figure out how to make AI trustworthy. How to keep humans in control while still providing automation benefits. How to explain decisions in ways users can understand. How to fail gracefully and learn from mistakes.

This is fundamentally a design problem, not just a technical one. The technology is getting better every month. But the trust gap isn’t closing on its own. That requires intentional design decisions about transparency, control, explainability, and respect for user agency.

If you’re working on AI features right now, your job isn’t to make the AI smarter. Your job is to make it trustable. Those are different goals, and the second one matters more for adoption.

Build AI that explains itself. Build AI that lets users stay in control. Build AI that degrades gracefully and fails honestly. Build AI that earns trust instead of demanding it.

That’s how you make AI features people actually use.

--The UXU Team

What if we built a conference that actually felt like the UX community - not a corporate stage with talking heads, but a room full of real practitioners who care deeply about this work, talking honestly about what it takes to do it well?

UXCON24 was that experiment. It sold out.

UXCON25 was the proof. It sold out too.

And the thing people kept saying afterward wasn’t “great content” or “good networking.” It was something quieter and more specific. It was I needed that. I didn’t know how much I needed that until I was in the room.

That’s what we’re building again on October 8th. And this year, we went further than we’ve ever gone.

Learn More

We called Don Norman.

If you work in UX, you know that name the way architects know Frank Lloyd Wright.

He coined the term “user experience.” He wrote The Design of Everyday Things - the book on virtually every designer’s shelf, the one you’ve probably bought twice because you gave your first copy away. He co-founded Nielsen Norman Group. He was VP of Advanced Technology at Apple. He has published 21 books, holds three honorary degrees, and is a member of the National Academy of Engineering.

One of his postdoctoral fellows once told him he was wrong about something. That fellow was Geoff Hinton - who went on to help invent the modern neural network and win the Nobel Prize. Don likes it when people tell him he is wrong.

At 88, he is still going. Still writing. Still pushing. Still asking whether the design industry is solving the right problems for the right people.

On October 8th, he will be in Silver Spring, Maryland, delivering a live keynote and sitting down for a Q&A where you - yes, you - can ask him anything.

Not a livestream. Not a pre-recorded message played on a big screen. The same room. The same air. A once-in-a-career moment, and we do not use that phrase lightly.

Join Don Norman at UXCON26

He is not coming alone.

Joining Don Norman on the UXCON26 stage:

Niyati Gupta — Product Design Lead at Netflix, formerly Google and WhatsApp. A decade spent building products used by hundreds of millions of people. Her talk is about the invisible work of UX - the influence, the framing, the organizational moves that separate designers who are good from designers who are irreplaceable.

Raven Adaramola — Senior Product Designer at The New York Times, working on the Games experience that millions of people open before their first coffee. Wordle. Connections. The Crossword. She helps design the daily rituals of an entire culture.

Calvin Robertson — Design leader with two decades at the Federal Reserve Bank, Lowe’s, Best Buy, and now Corning. His session is about what leadership looks like when design is the thing holding an organization together, not just a deliverable but a direction.

Twisha Shah Brandenburg — Design Leader at Target, working at the intersection where UX, product strategy, and engineering constraints meet. The place where experience quality gets decided long before anything ships.

Basel Fakhoury — Co-founder of User Interviews, now SVP at UserTesting. If you’ve ever recruited participants for a study, you’ve used something he built. He’s coming to talk about where research infrastructure is heading, and what that means for how all of us work.

Amanda Gelb — Founder of Aha Studio. Professional Question Asker. She designs workshops and learning experiences that move people from stuck to clear. The kind of session you’re still quoting in meetings four months later.

Zach Thomas — Design Lead at Skylight, doing human-centered design for the DHS, the US Air Force, and the CDC. Work where the stakes are real and getting it wrong has real consequences. Also a NASA JPL Solar System Ambassador - which tells you everything about the kind of person who shows up to UXCON.

Leo Hoar, PhD — Founder of UXR Institute. He looked at the UX research industry, saw that advanced career-focused education didn’t exist, and built it himself. He’s bringing the kind of depth that most conferences never get near.

More speakers coming….

Reserve your seat at UXCON26

Now the part we want you to sit with for a moment.

Research consistently shows that 80% of roles are filled before they are ever posted publicly.

They go to the person already in the conversation. The designer a hiring manager met at an event and remembered six weeks later. The researcher someone introduced to their team over lunch. The PM who asked a smart question after a talk, handed over a card, and followed up.

The people who attended UXCON in previous years came from Harvard, IBM, Adobe, Johns Hopkins, Lockheed Martin, The Met, NIH, Vanguard, T. Rowe Price, and dozens more organizations doing serious, consequential work.

These are not recruiters skimming CVs. These are the people who make the call.

One day in that room is worth more than six months of applying online. We genuinely believe that. And the people who came last year said the same thing after.

Here is what they actually said:

Reserve your seat at UXCON26

October 8th, 2026. Silver Spring Civic Center at Veterans Plaza, MD. Doors open 8am. Programme runs 9am – 5pm. Metro Red Line, short walk from Silver Spring station. Reagan National Airport, 30 minutes away.

We have built this event twice now. We have watched people walk in as strangers and leave as collaborators, mentors, and friends. We have watched careers shift in a single conversation over coffee. We have watched someone ask a question from the audience that changed the direction of a talk.

We are building it a third time on October 8th, and it is the best version yet.

Reserve your seat at UXCON26