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

Remember when you became a designer because you wanted to create things? Now you spend most of your day choosing between three approved button variants and arguing about 4px vs 8px spacing. Your design system was supposed to make you faster. Instead, it’s made you a glorified component assembler. Every screen feels the same. Every decision is already made. And you’re starting to forget what it feels like to actually design something.

Here’s how design systems went from helpful tool to creative straitjacket, and what you can do about it.

In this issue:

• When “consistency” became code for “boring”

• The components you’re not allowed to break (and why that’s a problem)

• What gets lost when everything is systematized

• How to stay creative inside rigid constraints

• When to follow the system vs. when to fight it

• 📦 Resource Corner

When “consistency” became code for “boring”

Design systems started with good intentions: ✅ Stop reinventing the wheel for every button ✅ Make products learnable through repeated patterns
✅ Speed up design and development ✅ Create cohesive experiences across products

But somewhere along the way, something broke.

Here’s what actually happened:

🔴 Consistency became the goal instead of the tool

Design systems were supposed to make consistency easy so you could focus on solving hard problems. But now consistency is the only thing that matters. “Does this match the system?” replaced “Does this solve the user’s problem?”

🔴 Every component became locked and untouchable

Early design systems had foundations (color, typography, spacing) and suggested patterns. Now they have rigid components with strict usage rules. You can’t adjust padding. You can’t change hierarchy. You can’t combine things in new ways. The system says no.

🔴 Design reviews became compliance checks

“Why didn’t you use the standard card component?” “This button treatment isn’t approved.” “We already have a pattern for this, use that.”

Design critique turned into design enforcement. You’re not evaluated on problem-solving anymore. You’re evaluated on rule-following.

🔴 Speed became more valuable than quality

“Just use existing components” is faster than designing something custom. So teams optimize for speed. But fast and good aren’t the same thing. You end up with products that work fine but feel generic and forgettable.

🔴 Junior designers never learn to design

If your entire job is “choose components from the library and arrange them in approved layouts,” you never develop design judgment. You never learn how to solve problems from first principles. You become a component operator, not a designer.

The result?

Every SaaS product looks identical. Same cards. Same buttons. Same layouts. Same typography. Same everything. Users can’t tell companies apart anymore. Brands have no visual personality. And designers feel creatively dead inside.

The components you’re not allowed to break (and why that’s a problem)

Let’s talk about what “locked components” actually means in practice.

Scenario 1: The button that doesn’t work for your use case

Your design system has a button component:

• Primary: 40px tall, 16px padding, bold text

• Secondary: 40px tall, 16px padding, regular text

• Tertiary: text link style

But you’re designing a dashboard with tight vertical space constraints. The 40px buttons feel massive and clunky. A 32px button would work better.

❌ System says: “Use the approved button sizes. No exceptions.”

✅ What you need: Flexibility to adjust size when context demands it.

Why it matters: Rigid adherence to components makes your design worse for users just to satisfy internal consistency rules.

Scenario 2: The card that forces bad hierarchy

Your card component has fixed structure:

• Icon top-left

• Title below

• Description below that

• Action buttons bottom

But for your specific use case, you need the action button prominent and the description de-emphasized. The standard card forces the wrong visual hierarchy.

❌ System says: “That’s not how cards work. Use the standard pattern.”

✅ What you need: Compositional flexibility to arrange elements based on user needs, not template rules.

Why it matters: Good information hierarchy depends on context. One-size-fits-all components can’t adapt to different content priorities.

Scenario 3: The navigation that assumes desktop patterns

Your navigation component is designed for desktop:

• Horizontal nav bar

• Dropdowns on hover

• Always visible

But on mobile, this pattern fails. You need something completely different. The system doesn’t have a mobile-specific navigation solution.

❌ System says: “Make the desktop nav responsive. Don’t create custom navigation.”

✅ What you need: Different patterns for fundamentally different contexts.

Why it matters: Responsive scaling isn’t the same as context-appropriate design. Mobile users need mobile patterns, not shrunk-down desktop patterns.

The pattern across all these:

Design systems optimize for reuse and consistency. But design quality often requires context-specific solutions. When the system blocks those solutions, you’re forced to choose between good design and approved design.

Most designers choose approved design because fighting the system is exhausting and career-limiting. So the product gets worse.

What gets lost when everything is systematized

Okay, so design systems create consistency and efficiency. Great. But what’s the cost? What do you lose when every decision is pre-made?

💔 Loss 1: Problem-solving skills

When every screen is assembled from pre-built components, you stop solving problems. You stop asking “what does the user need here?” and start asking “which components can I use?”

Junior designers today build portfolios by arranging system components in Figma. They never learn how to:

• Analyze a complex problem and break it down

• Explore multiple solution directions

• Iterate based on user feedback

• Make and defend design decisions from first principles

They learn component selection, not design thinking.

💔 Loss 2: Visual personality and brand differentiation

When every company uses the same design system components (Material, Bootstrap, Ant Design, Chakra), every product looks the same.

Blue buttons ✓
Sans-serif type ✓
Card-based layouts ✓
8px grid ✓
Pastel colors ✓

There’s no visual point of view. No personality. No memorable design. Just competent sameness.

Brand becomes logo and color scheme, not holistic design language.

💔 Loss 3: Context-specific solutions

Some problems need custom solutions. A data visualization dashboard needs different components than a social media feed. A medical records interface needs different patterns than a project management tool.

But design systems encourage generic solutions that work “most places.” The 80% solution becomes the 100% requirement. Edge cases get forced into standard components even when it creates a worse experience.

💔 Loss 4: Experimentation and learning

Design systems encode past learnings. They capture what worked before. But they also prevent new learning.

When you can’t try new things because “we already have a pattern for that,” you stop discovering better solutions. The system becomes stagnant. Innovation happens outside your product, and you’re stuck with legacy patterns.

💔 Loss 5: Designer agency and satisfaction

Let’s be honest: arranging pre-made components isn’t creatively fulfilling.

Designers got into this field to solve problems and create things. Being told “just use the existing component” for every screen is soul-crushing. You feel like an assembler, not a designer.

This leads to burnout, disengagement, and good designers leaving for roles where they can actually design.

The tradeoff:

→ You gain: Speed, consistency, scalability, ease of handoff
→ You lose: Creativity, context sensitivity, learning, differentiation, fulfillment

For many companies, that tradeoff is worth it. But nobody admits what’s being lost. And designers are the ones paying the price.

💡 Reality check: If you can be replaced by someone who just knows how to use your component library, you’re not doing design work anymore.

Quick pause. This one’s important.

🎯 UXCon26: Where Design Thinking Still Matters

You know what’s not at UXCON26? A bunch of talks about how to use Figma components faster.

You know what is there? Designers solving actual problems. Designers breaking rules intentionally. Designers who still remember that the job is about users, not systems.

The talks on creativity, on when to break your own guidelines, on balancing consistency with innovation… those aren’t abstract theory. They’re survival skills for designers who want to still be designing five years from now instead of just component-shopping.

Plus, honestly? The best conversations happen after sessions. With designers who get it. Who feel the same creative frustration you do. Who’ve figured out how to stay creative inside constraints.

Dont wait: Secure your spot

The people who show up are the ones who still care about craft. Just saying.

Let’s talk solutions.

How to stay creative inside rigid constraints

Okay, you’re stuck with a design system. You can’t burn it down and start over. How do you actually stay creative and do good work within those limits?

Strategy 1: Master the fundamentals the system is built on

→ Understand the why behind system decisions
→ Learn color theory, typography, spacing principles deeply
→ Study the psychology behind interaction patterns

Why this helps: When you understand principles, you can make better decisions even with limited options. You become strategic about which components to use and how to combine them. You’re not just following rules; you’re applying knowledge.

Strategy 2: Find the flexibility hiding in the system

Most design systems have more flexibility than designers realize:

✓ Design tokens you can customize per-screen
✓ Composition patterns that let you build new layouts from primitives
✓ Theming options that change the feel without breaking patterns
✓ Spacing and sizing scales that allow variation within constraints

Why this helps: You work with the system instead of against it. You find creative solutions that still feel cohesive but aren’t cookie-cutter identical to everything else.

Strategy 3: Document your “breaking the rules” decisions

When you need to go off-system:

1️⃣ Document why the standard component doesn’t work
2️⃣ Show what user need you’re solving
3️⃣ Propose your solution with clear rationale
4️⃣ Make it a conversation, not a rebellion

Why this helps: You’re not just violating rules. You’re making a case for evolution. You’re treating the system as a living thing that should grow based on real needs.

Strategy 4: Build a “playground” space for experimentation

→ Personal projects outside work constraints
→ Design sprints where rules are temporarily suspended
→ Speculative redesigns that explore “what if”
→ Side projects that let you try wild ideas

Why this helps: You keep your creative muscles active even if your day job is constrained. You prevent complete creative atrophy. And sometimes playground ideas eventually influence the main product.

Strategy 5: Focus on the problems components can’t solve

Design systems handle the how of interface design. Focus on the what and why:

→ User research and insight generation
→ Information architecture and flow design
→ Problem definition and scope
→ Service design and ecosystem thinking

Why this helps: These are the high-value design problems. Components are implementation details. If you solve the hard strategic problems well, component assembly becomes trivial.

Strategy 6: Become the person who evolves the system

Instead of fighting the system from the outside:

✓ Join the design system team (if possible)
✓ Contribute new components based on real needs
✓ Run research on existing patterns and push for improvements
✓ Be the voice for flexibility and context-sensitivity

Why this helps: You influence the constraints rather than just enduring them. You make the system better for everyone, including yourself.

🎯 Take-home: Constraints don’t have to kill creativity. They just redirect it. The question is: do you stay creative within limits, or do you give up and become a component operator?

When to follow the system vs. when to fight it

Not every screen deserves custom design. Not every pattern should match the system. How do you know when to comply and when to push back?

✅ Follow the system when:

→ You’re designing standard CRUD screens (lists, forms, settings)
→ The existing pattern genuinely solves the user problem well
→ Consistency is more important than optimization for this flow
→ You’re on a tight timeline and the system solution is good enough
→ Breaking the pattern would confuse users who’ve learned it elsewhere in the product

🔥 Fight the system when:

→ The standard component creates a genuinely worse user experience
→ You’re designing a high-stakes flow where context-specific optimization matters
→ Your use case is fundamentally different from what the system was designed for
→ The system pattern is outdated and doesn’t reflect current best practices
→ You’re working on a new feature that should eventually expand the system

The test: Ask yourself:

“Am I following the system because it’s genuinely the best solution, or because it’s easier/safer?”

If the answer is “easier/safer,” question it. If the answer is “best solution,” follow it confidently.

⚖️ How to fight the system effectively (without getting fired):

1. Show, don’t just tell

Build the alternative. Show it working. Compare it side-by-side with the system approach. Visual proof is more persuasive than arguments.

2. Frame it as evolution, not rebellion

“I think we’ve discovered a new pattern that could benefit the system” beats “the system is wrong and I’m breaking it.”

3. Test both approaches with users

User research gives you objective data. “Users struggled with the standard component but succeeded with this alternative” is hard to argue against.

4. Propose it as an addition, not a replacement

“Can we add this as a variant for [specific use case]?” is more likely to succeed than “let’s replace the existing component.”

5. Pick your battles

Don’t fight every constraint. Save your credibility for the decisions that genuinely matter to user experience.

📦 Resource Corner

Design Systems Handbook (DesignBetter)
Free resource on building flexible design systems. Good on when to systematize and when to leave room for creativity.

Atomic Design by Brad Frost
The methodology that started component-based thinking. Still valuable for understanding how to build composable rather than rigid systems.

Every Layout
CSS layout primitives that let you build flexible systems. Shows how to create rules without rigidity.

Material Design Customization
Even rigid systems like Material Design have customization options. Study how to use them.

Modulz/Radix Primitives
Component library built on composability. Example of a system that gives you building blocks instead of finished components.

Design System Office Hours (various communities)
Many design system teams run office hours where you can ask questions and get guidance on when to bend rules.

💭 Final Thought

Design systems aren’t evil. They solve real problems. They make teams faster and products more cohesive. The problem is when the system becomes more important than the work it was supposed to enable.

When “use the component” becomes the answer to every design question, you’ve stopped designing. When consistency is valued over user needs, you’ve lost the plot. When designers feel like assembly-line workers instead of problem solvers, something fundamental is broken.

The best design systems are guidelines, not laws. They make common things easy and custom things possible. They evolve based on real product needs instead of enforcing past decisions forever. They trust designers to think, not just comply.

If your design system is killing your creativity, you have three choices:

1️⃣ Leave and find a place that values design thinking
2️⃣ Become the person who evolves the system from within
3️⃣ Find creative space outside work and treat your job as execution-only

None of these are perfect. But all are better than slowly dying creatively while pretending everything is fine.

You became a designer to create things, solve problems, make experiences better. Don’t let a tool built to help you do that become the thing that stops you from doing it.

Fight for the space to design. The components will still be there when you need them.

--The UXU Team

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

The job market for UX designers is deeply broken right now, but not in the way you think. This issue breaks down what’s really happening, why job posts lie, and the actual path into UX work in 2025.

In this issue:

• Why “junior” job posts ask for senior experience

• What companies actually mean vs. what they post

• The experience paradox (and how to break it)

• Alternative paths that actually work right now

• How to position yourself when you “don’t qualify”

• 📦 Resource Corner

Why “junior” job posts ask for senior experience

Let’s start by acknowledging the absurdity: “Junior UX Designer: 3-5 years experience required.” It’s everywhere. And it makes no sense. If someone has 3-5 years of experience, they’re not junior. They’re mid-level at minimum.

So what’s actually happening?

The job post isn’t describing who they want. It’s describing who they wish existed.

Here’s the breakdown of what’s really going on:

🔹 Companies don’t know how to hire for UX Many companies, especially smaller ones or those new to having design teams, don’t actually understand UX career levels. They copy requirements from other job posts. They ask HR to write the posting without designer input. They list everything they think sounds important without understanding what’s realistic.

🔹 They’re scared of training someone Hiring managers have been burned before. They hired someone “junior” who couldn’t do the work. So now they’re hedging. They call it junior to justify the salary, but they want someone experienced enough to hit the ground running. They want junior pricing with mid-level output.

🔹 The job post is a wish list, not requirements That list of “must-haves”? Most of it is “nice-to-haves.” Companies throw everything against the wall hoping to filter for the best candidates. But they’ll absolutely interview people who only meet 60% of the requirements if the portfolio is strong.

🔹 They’re protecting themselves from bad hires By asking for experience, they’re trying to avoid complete beginners who can’t deliver. It’s not that they actually need 3 years. They need someone who can do basic UX work competently. But they don’t know how to screen for that, so they use years as a proxy.

🔹 Budget constraints dressed up as experience requirements Sometimes they can only afford a junior salary but need mid-level work. So they post a “junior” role with inflated requirements, hoping someone desperate or early in their career will take the low pay despite having the skills.

The result: Job posts that don’t match reality. Requirements that discourage qualified people from applying. And a ton of confusion about what “junior” even means.

What companies actually mean vs. what they post

Let’s decode some common job posting language, because what they write and what they actually need are often completely different.

What they post: “3-5 years of UX design experience required”

What they actually mean: “We need someone who can do basic UX work without constant hand-holding. If you’ve done real projects, even practice ones, and can demonstrate competence, we’ll talk to you.”

What to do: Apply anyway if your portfolio shows the skills. Years matter less than demonstrated ability.

What they post: “Experience with user research, wireframing, prototyping, usability testing, visual design, and front-end development”

What they actually mean: “We’re a small team and need someone versatile. You don’t need to be an expert at all of these, but you should be comfortable wearing multiple hats.”

What to do: Show range in your portfolio. Demonstrate you’ve done research AND design AND testing, even if none of it is advanced-level work.

What they post: “Must have shipped products at scale with measurable impact”

What they actually mean: “We want someone who understands the full product lifecycle, not just making pretty screens.”

What to do: If you have ANY shipped work, even a small feature or client project, talk about it. If you don’t, frame practice projects around the full process: research, design, testing, iteration.

What they post: “Portfolio must demonstrate strong visual design skills”

What they actually mean: “We need someone who can make things look professional, not just functional. We don’t want to hire a visual designer separately.”

What to do: If your visual skills are weak, invest in learning design fundamentals. Take existing wireframes and add polish. Study designs you admire and reverse-engineer them.

What they post: “Startup experience preferred”

What they actually mean: “We’re chaotic, under-resourced, and need someone comfortable with ambiguity and fast iteration.”

What to do: Emphasize any experience working independently, wearing multiple hats, or working without clear direction. Show you’re scrappy.

What they post: “Must work well in a fast-paced environment”

What they actually mean: “We’re disorganized and things change constantly. Can you handle that?”

What to do: Be honest with yourself about whether you want this. If yes, show examples of adapting to changing requirements or pivoting quickly.

The pattern: Job posts are often written defensively, listing everything they could possibly want. The actual bar is lower than it looks. Apply if you can do 60-70% of what they’re asking.

The experience paradox (and how to break it)

Here’s the trap every junior designer knows: you need experience to get a job, but you need a job to get experience.

Companies want to see that you’ve done real UX work. But how do you get real UX work if no one will hire you to do real UX work?

This is the experience paradox. And it’s real. But it’s not insurmountable.

Here’s how people are actually breaking in right now:

Path 1: Freelance and contract work (even small projects)

You don’t need a full-time job to get experience. You need projects. Small businesses, nonprofits, solo founders, they all need design help and often can’t afford agencies.

Where to find them:

• Upwork, Fiverr (yes, really, for building initial portfolio pieces)

• Local business communities, chambers of commerce

• Nonprofit boards (many need digital help)

• Your personal network (someone knows someone who needs a website or app redesigned)

Start small. Charge low or even do a few for free initially just to get real client work in your portfolio. Once you have 2-3 real projects, you can start charging properly and using those as leverage for better opportunities.

Path 2: Internal transition at your current company

If you’re already employed somewhere, even in a non-design role, this is your easiest path in. Companies hire from within because there’s less risk.

How to do it:

• Volunteer to help with UX-adjacent projects in your current role

• Offer to redesign internal tools or processes

• Build relationships with the design or product team

• Ask to shadow designers or help with research

• When a junior role opens, you’re already a known quantity

This is how a lot of designers broke in: they were in customer support, project management, marketing, or development, and gradually shifted into design.

Path 3: Spec work and redesigns (done strategically)

Practice projects get a bad reputation, but they work if you do them right. The key is treating them like real work, not like school assignments.

How to do it right:

• Pick a real product with real problems (not another Spotify redesign)

• Do actual user research (interview real users of that product)

• Solve a specific, scoped problem (not “redesign the whole app”)

• Document your process thoroughly

• Present it like client work, not a portfolio exercise

One exceptionally good spec project that shows deep thinking beats five mediocre bootcamp projects every time.

Path 4: Bootcamps and programs with job placement support

Some bootcamps actually have strong hiring networks and job placement support. These work when:

• The bootcamp has relationships with companies actively hiring

• They offer portfolio reviews and interview prep

• They connect you with alumni who can refer you

• They teach current, relevant skills

The bootcamp itself isn’t the value. The network and placement support is. Research thoroughly before investing.

Path 5: Start as an apprentice or design intern

Some companies offer apprenticeships or internships specifically designed to bring in people without experience and train them. These are rare but valuable.

Where to look:

• Larger tech companies with formal training programs

• Design agencies with apprenticeship models

• Government digital services (18F, USDS, GDS in UK)

The pay is often low, but the training and resume credibility are real.

The common thread: All of these paths involve doing real work before you have a “real job.” The experience paradox isn’t actually a paradox. You can get experience without employment. It’s just harder and requires more initiative.

Quick pause. This part matters.

🎯 UXCON26: Your Fast-Track Past the Paradox

Here’s what nobody warns you about when you’re trying to break into UX: the actual doors that open don’t come from job boards. They come from someone saying “I know a person.”

Every designer at UXCON26 who’s hiring, mentoring, or just well-connected? They’re the “person” in that sentence. The hiring manager who posts on LinkedIn before the job goes public. The senior who refers people straight to final-round interviews. The founder who needs a contractor next month.

They’re all going to be there. And you’re trying to break in by cold-applying on Indeed.

Fast-track your UX Career

The difference between struggling for months and landing something next week is often just one conversation with the right person. That’s what you’re paying for.

Back to positioning yourself.

How to position yourself when you “don’t qualify”

You’re going to apply for jobs where you don’t meet all the requirements. That’s normal and expected. But how you position yourself determines whether you get a shot.

Strategy 1: Lead with your strongest work

Your portfolio is your actual resume. If it’s strong, the experience gap matters less. Make sure your best work is first, presented clearly, with obvious process and thinking visible.

When a hiring manager sees exceptional work, they start finding reasons to interview you despite the experience gap. When they see mediocre work, they use the experience gap as an easy rejection reason.

Strategy 2: Address the gap directly in your cover letter

Don’t ignore it. Don’t apologize. Acknowledge it and redirect to your strengths.

✅ “I know you’re looking for 3+ years of experience. I have 1 year of professional work plus extensive self-directed projects. Here’s why I’m confident I can deliver what you need...”

Then talk about specific skills, relevant projects, and what you bring that makes up for less time.

Strategy 3: Show learning ability and growth

If you can’t show years of experience, show rapid learning. Talk about what you’ve learned in the last 6 months. Show iteration and improvement across projects in your portfolio. Demonstrate that you get better quickly.

Companies hiring junior people are really hiring for potential and learning speed, not existing expertise.

Strategy 4: Emphasize transferable skills

If you’re coming from another field, lean into what transfers:

• Customer service → User empathy and communication

• Project management → Organization and stakeholder management

• Development → Technical understanding and feasibility thinking

• Marketing → User psychology and persuasion

Don’t just list these. Show how they’ve helped you do better design work.

Strategy 5: Be specific about what you want to learn

In interviews, when they ask about weaknesses or gaps, be honest and specific:

✅ “I haven’t worked on a product at scale yet, so I’m eager to learn how design decisions change when you’re serving millions of users instead of thousands.”

This shows self-awareness and genuine interest in growth. It’s way better than pretending you know things you don’t.

Strategy 6: Network your way in (referrals skip the resume screen)

This is the most effective strategy. A referral from someone internal gets you past the automated filters and experience requirements. Your resume gets seen by a human who’s already biased toward giving you a chance.

Where to build these connections:

• LinkedIn (engage with people at companies you want to work for)

• Design communities and Slack groups

• Local meetups and design events e.g UXCON26

• Design Twitter (yes, still useful for this)

• Cold outreach to designers for informational interviews

One warm introduction is worth 50 cold applications.

🎯 Take-home: The job requirements are the ceiling of what they hope for, not the floor of what they’ll accept. Apply anyway. Make them say no.

📦 Resource Corner

Cofolios Portfolio examples from designers who successfully got hired. Study what worked for people at your level.

Designer Hangout Slack Large design community with a jobs channel and people willing to give referrals. Active and supportive.

UX Coffee Hours Free mentorship platform connecting junior designers with experienced ones for advice. Good for getting resume/portfolio reviews.

Hexagon UX Another UX community with job postings and a supportive network. Smaller than Designer Hangout but high-quality.

UXCEL Job Search Guide Free course on navigating the UX job search, including how to read job posts and position yourself effectively.

Indeed Career Guide for UX Practical advice on applications, interviews, and breaking into UX. Surprisingly useful resource.

Levels.fyi Salary data and company reviews. Use this to know what’s realistic for your level and location.

💭 Final Thought

The UX job market right now feels impossible if you’re trying to break in. Every job wants experience you don’t have. Every application disappears into a void. Every rejection makes you question if you’re even good enough.

But here’s the reality: companies are still hiring. Designers are still getting jobs. The paths just don’t look like they used to.

The traditional route of applying online, getting interviewed, getting hired, that works for maybe 20% of people now. The other 80%? They’re getting in through referrals, freelance-to-full-time conversions, internal transitions, contract work that becomes permanent, or just showing up in the right communities and meeting the right people.

The job posts are broken. The requirements are inflated. The process is frustrating. But the opportunities are still there if you’re willing to take non-traditional paths and be persistent.

Don’t wait for the perfect job post where you meet 100% of requirements. That doesn’t exist. Apply to things you’re 60% qualified for. Build real work even without real jobs. Network aggressively.

The designers who break in aren’t the most talented ones. They’re the most persistent ones who figure out how to get in the door when the front entrance is locked.

Find the side door. It’s open.

--The UXU Team

In this issue:

• The selection bias in your user research

• Who you’re systematically excluding (and why)

• Why “power users” are the worst people to design for

• How to find non-users and get them to talk to you

• What to do with conflicting feedback from different user groups

• 📦 Resource Corner

The selection bias in your user research

Let’s start with an uncomfortable truth: your current users are not representative of your potential users.

When you recruit for user research, who actually shows up?

• People who already use your product regularly

• People who like your product enough to spend time helping improve it

• People who understand your category and your jargon

• People who are tech-savvy enough to join a video call or navigate a prototype

• People who have strong opinions about features

These people are valuable. But they’re also a biased sample. They represent one specific slice of your possible audience: the people who already figured out how to use what you built.

Here’s who you’re probably not talking to:

🚫 People who tried your product once and left They’re the majority. For most products, 60-80% of people who sign up never come back. But they’re invisible in your research because they’re not around to recruit. (Source: Product analytics benchmarks)

🚫 People who use competitor products instead of yours They chose something else for a reason. But you’re not talking to them because they’re not in your user base. You only hear from people who picked you.

🚫 People who need what you do but don’t know it yet They have the problem your product solves, but they’re solving it some other way. They’re not searching for your category terms. They’re not in your market yet. And you’re definitely not researching them.

🚫 People who got confused during onboarding and gave up They wanted to try your product but couldn’t figure out how to get value from it. They bounced before becoming “users.” You never hear from them.

🚫 People who can’t afford your product If you have a paywall, you’re only talking to people who can pay. You’re missing everyone for whom price is a barrier, which might be your biggest potential market.

The result: Your research tells you how to make your product better for people who already get it. It doesn’t tell you how to make it accessible to people who don’t.

This is called survivorship bias: you’re only studying the survivors, not the casualties. And the casualties often outnumber the survivors by 10x or more. (Source: Survivorship Bias research)

Who you’re systematically excluding (and why)

Let’s be more specific about the gaps in typical user research, because recognizing them is the first step to fixing them.

Gap 1: Non-adopters who have the problem you solve

These people need what you do, but they’re solving the problem differently:

• Using spreadsheets instead of your SaaS tool

• Using pen and paper instead of your app

• Just living with the problem unsolved

• Using a completely different category of solution

Why you’re missing them: They’re not in your product, so they’re not in your recruitment pool. And they’re not searching for your solution, so they don’t find you.

Why it matters: Understanding why they chose alternatives reveals barriers to adoption you can’t see from inside your user base.

Gap 2: Failed onboarding users

People who signed up, tried to use your product, got confused or frustrated, and left within the first session.

Why you’re missing them: They left before you could build a relationship. You might have their email, but they’re not engaged enough to respond to research requests.

Why it matters: They represent the majority of people who try your product. If you can’t convert them, you can’t grow.

Gap 3: Users of competing products

People actively using a competitor instead of you.

Why you’re missing them: You don’t have access to them. They’re in someone else’s product, not yours. And they’re probably happy there or they’d have switched already.

Why it matters: They chose a competitor for reasons that reveal your weaknesses or your competitor’s strengths. That’s strategic information you’re missing.

Gap 4: People from different demographics or contexts

Your current users might skew young, tech-savvy, English-speaking, or from specific countries. But your potential market might be older, less technical, multilingual, or global.

Why you’re missing them: Your marketing attracts people like your current users. Your product is optimized for people like your current users. So you get more of the same.

Why it matters: If you want to expand beyond your current niche, you need to understand users outside it. But you can’t design for them if you never talk to them.

Gap 5: Extreme users (both power users and struggling users)

Power users: People who use every feature, push your product to its limits, and want more advanced capabilities.

Struggling users: People who barely get value, use only one or two features, and might churn soon.

Why you’re missing them: Most research focuses on “typical” users in the middle. The extremes get filtered out as edge cases.

Why it matters: Power users show you the growth trajectory. Struggling users show you where you’re failing. Both edges are more informative than the middle.

Why “power users” are the worst people to design for

This one is controversial, but it’s true: your most engaged users are often the worst people to base design decisions on.

Power users are not representative. They’re outliers. And designing for outliers makes your product worse for everyone else.

Here’s what happens when you over-index on power users:

❌ Feature creep Power users always want more features, more customization, more power. If you build everything they ask for, your product becomes bloated and complex. New users get overwhelmed.

❌ You optimize for efficiency over learnability Power users value speed and shortcuts. They want keyboard commands, bulk actions, advanced filters. But new users need clarity and simple paths to value. These goals conflict.

❌ You assume knowledge that new users don’t have Power users understand your jargon, your mental model, your edge cases. They give you feedback that assumes expertise. But most users don’t have that expertise yet.

❌ You mistake loud voices for majority needs Power users are vocal. They’re in your Slack community, they write feature requests, they participate in research. But they’re 5-10% of your users. The other 90-95% are silent. If you design for the loud 5%, you’re ignoring the silent 95%.

The paradox: Power users are the easiest to recruit and the most eager to give feedback. So they’re overrepresented in research. But they’re the least representative of your actual market.

This doesn’t mean ignore power users. It means balance their feedback against the needs of average and struggling users. Weight your sample appropriately. (Source: “The Mom Test” by Rob Fitzpatrick)

Okay, quick break. This one’s time-sensitive.

🎉 UXCON26 Easter Weekend Flash Sale

Here’s what nobody tells you about conferences: the talks are great, sure. But the real value? It’s the hallway conversations. The person you meet at lunch who mentions their team is hiring. The senior designer who looks at your work and tells you exactly what’s holding you back. The founder who needs a contractor and you just happen to be standing there.

UXCON26 isn’t about sitting in sessions. It’s about being in rooms where opportunities happen. Where hiring managers actually are. Where the people one email away from changing your career trajectory are just... there. Accessible. Human.

We’re running a 72-hour Easter special that ends Sunday at midnight. We want you in that room. We want you meeting these people. We want you having those conversations that turn into referrals, collaborations, job offers.

This weekend only.

CLAIM YOUR EASTER SPECIAL

Right, back to research……

How to find non-users and get them to talk to you

Okay, so you need to talk to people outside your current user base. How do you actually find them?

Strategy 1: Mine your failed signups

Look at people who created accounts but never completed onboarding or made it past the first session.

How to recruit them:

• Email them: “You tried [product] a few weeks ago. Can I ask what stopped you? I’ll send you a $50 gift card for 20 minutes.”

• Frame it as helping improve the product, not defending it

• Acknowledge they left for a reason and you want to understand

What to ask:

• What were you trying to accomplish?

• What confused you or got in your way?

• What did you try instead?

• What would have made you stay?

Strategy 2: Talk to competitor users

Find people actively using alternatives to your product.

How to recruit them:

• Post in relevant subreddits, Facebook groups, or communities: “I’m researching how people use [competitor product]. Looking to interview users for a research study. $75 for 30 minutes.”

• Use UserInterviews, Respondent, or similar platforms with specific screening criteria

• Ask your network: “Do you know anyone who uses [competitor]?”

What to ask:

• Why did you choose that tool?

• What other options did you consider?

• What would make you switch?

• What’s your tool missing that you wish it had?

Strategy 3: Find people who have the problem but haven’t adopted any solution

This is the hardest group to find because they’re not in any product or community yet.

How to recruit them:

• Post in adjacent communities: If you make a project management tool, post in subreddits for freelancers, small business owners, or specific industries

• Use social media: “How do you currently manage [task]? Looking to interview people about their workflow.”

• Ask current users for referrals: “Do you know anyone who struggles with [problem] but doesn’t use a tool for it?”

What to ask:

• How do you currently handle this problem?

• What have you tried?

• Why haven’t you adopted a solution?

• What would need to be true for you to pay for a tool?

Strategy 4: Seek out demographic diversity intentionally

If your current users skew heavily in one direction (age, location, technical skill, industry), actively recruit from underrepresented groups.

How to recruit them:

• Use recruitment platforms with demographic filters

• Post in communities where different demographics gather

• Partner with organizations that serve specific groups

• Offer higher incentives if needed to overcome barriers to participation

What to ask:

• Same questions as usual, but listen for how their context differs from your typical user

• Pay attention to assumptions you made that don’t hold for them

Strategy 5: Interview customer support contacts

People who contact support are struggling. They’re not happy users. They’re confused, frustrated, or blocked users. That’s valuable perspective.

How to recruit them:

• Ask your support team to offer research participation to people who reach out

• “Thanks for contacting us. Would you be willing to do a quick call to help us understand this issue better? We’ll compensate you for your time.”

What to ask:

• What were you trying to do when this happened?

• What did you expect to happen?

• How did this make you feel about the product?

• What would have prevented this issue?

🎯 Take-home: The people hardest to recruit are often the most valuable to talk to. If it’s easy to find them, you’re probably talking to the same types of people you always talk to.

What to do with conflicting feedback from different user groups

When you start talking to a more diverse set of users, you’ll get conflicting feedback. Power users want X. New users want Y. Non-users say Z is why they didn’t adopt. What do you do?

Don’t try to make everyone happy. That leads to a bloated, confused product that serves no one well.

Instead, segment and prioritize:

1. Identify your primary user segment

Who is your product primarily for? Not “everyone.” Pick the segment that:

• Represents the biggest business opportunity

• Has the most urgent problem

• Is most likely to pay or grow

• Aligns with your company strategy

Design primarily for them. (Source: “Crossing the Chasm” by Geoffrey Moore)

2. Listen to other segments for blindspots

Even if you’re not designing primarily for power users, their feedback reveals:

• Where your product could scale

• What advanced users eventually need

• Technical limitations you might hit

Even if you’re not designing primarily for non-adopters, their feedback reveals:

• Onboarding barriers

• Marketing message mismatches

• Category misunderstandings

3. Look for patterns across segments

Sometimes different groups complain about different symptoms of the same underlying problem. When you see patterns across diverse feedback, that’s a strong signal.

Example: Power users say “I can’t bulk edit.” New users say “I have to do everything one at a time.” Non-users say “It looks like a lot of manual work.” These are all pointing to the same problem: lack of bulk actions.

4. Test solutions with multiple segments

When you design something new, test it with:

• Your primary segment (does it work for them?)

• A struggling user (does it help them succeed?)

• A non-user (does it make adoption clearer?)

You can’t please everyone, but you can avoid breaking things for people outside your primary focus.

5. Accept that some feedback will be ignored

You can’t build everything everyone wants. Some feedback, even good feedback, won’t align with your strategy. That’s okay. Thank people for their input, explain your priorities when appropriate, and move on.

📦 Resource Corner

The Mom Test by Rob Fitzpatrick Essential reading on asking good research questions and avoiding bias in user interviews. Especially good on talking to non-users.

UserInterviews.com Platform for recruiting research participants with specific demographics, behaviors, or tool usage. Good for finding competitor users or non-users.

Respondent.io Another recruitment platform, especially strong for B2B participants and niche professional audiences.

Just Enough Research by Erika Hall Practical guide to doing research that matters. Good chapter on sampling and who to talk to.

Crossing the Chasm by Geoffrey Moore While focused on marketing, the framework for understanding different user segments and how they adopt products is essential for research planning.

Mixed Methods (Research Community) Community and resources for UX researchers. Good articles on recruitment strategies and research bias.

Nielsen Norman Group: Recruiting Participants Research-backed guidance on participant recruitment, including how to find hard-to-reach groups.

💭 Final Thought

Your current users are your present. But if you only design for them, they’re also your future. And that’s a problem if you want to grow.

The people not using your product, the people who tried and left, the people using competitors, they hold the insights that could transform your trajectory. But they’re harder to find. They’re less eager to help. They require more effort to recruit and more care to interview.

Most teams skip this work. They talk to who’s easy to talk to: happy, engaged current users. And then they wonder why their product feels stuck, why growth plateaus, why they can’t break into new markets.

The uncomfortable truth is that the users who love your product the most are often the least helpful for growth. They already love you. They already figured you out. They’re not representative of the people you need to reach next.

If you want to grow, talk to people who don’t get it yet. Talk to people who chose something else. Talk to people who left. They’ll tell you things your biggest fans never will.

And those things might just change everything.

— The UXU Team

He wrote The Design of Everyday Things - the book sitting on your shelf right now. He co-founded Nielsen Norman Group. He was VP of Advanced Technology at Apple. He has published 21 books translated into 20 languages and is a member of the National Academy of Engineering.

At 88, he is still pushing this field forward.

On October 8th, he will be on stage at UXCON26 in Silver Spring, MD - live keynote, live Q&A, same room as you. Not a livestream. Not a panel via Zoom. You can raise your hand and ask him anything.

Secure your spot

But it’s not all you’re getting.

The people sharing a stage with him:

Niyati Gupta spent the last decade at Google, WhatsApp, and now Netflix figuring out why some designers become indispensable and others don’t. Her talk will tell you exactly what the difference is.

Raven Adaramola designs the NYT Games experience, the one millions of people open before they’ve had their first coffee. She’s built her career across media, edtech, and streaming, and she sees design problems most people in one industry never encounter.

Calvin Robertson has led design at the Federal Reserve Bank, Lowe’s, Best Buy, and Corning. He’s going to talk about what leadership actually looks like when design is the thing holding an organization together.

Twisha Shah Brandenburg is a design leader at Target whose work lives where UX, product strategy, and engineering constraints collide - the place where experience quality gets decided before anything ships.

Basel Fakhoury co-founded User Interviews - the recruitment platform most of you have used to run research — which was acquired by UserTesting, where he’s now SVP. He’s coming to talk about where research infrastructure is heading, and what that means for how you work.

Amanda Gelb runs Aha Studio and her official title is Professional Question Asker. That’s not a joke. She designs workshops that move people from stuck to clear. Her session is the kind you keep quoting in meetings four months later and can’t remember exactly why it hit so hard.

Leo Hoar, PhD saw that advanced UX research education didn’t exist, so he built it. He founded UXR Institute after starting his research career at Samsung. He’s bringing the kind of practical depth that most conferences never get close to.

Zach Thomas leads human-centered design at Skylight for the DHS, US Air Force, and CDC. Work where getting it wrong has real consequences. He’s also a NASA JPL Solar System Ambassador, which has nothing to do with UX and everything to do with the kind of person who shows up to UXCON.

More speakers still to come.

Come Experience UXCON26

What it felt like to be there last year

Now the part nobody talks about openly.

80% of roles are filled before they are ever posted.

They go to the person already in the conversation. The designer a hiring manager met at an event and remembered. The researcher someone introduced them to over lunch. The one who asked a sharp question after a panel, handed over a card, and followed up.

UXCON26 is full of those hiring managers. Past attendees have come from Harvard, IBM, Adobe, Johns Hopkins, Lockheed Martin, The Met, NIH, Vanguard, and T. Rowe Price. Not recruiters reading CVs. Decision-makers who hire people they’ve met.

Your ticket gets you into those conversations.

Secure your spot

UXCON26 is more than a conference - it’s a room full of people who chose to show up. For their craft. For their community. For growth. And somewhere in that room is your next collaborator, mentor, or best idea.

— The UXU Team

This issue breaks down why wireframe perfection is killing your process, what wireframes are actually for, and how to get comfortable with ugly, fast, throwaway sketches that actually move projects forward.

In this issue:

• Why “low-fidelity” stopped being low-fidelity

• What you lose when wireframes look too finished

• The speed vs. fidelity tradeoff nobody talks about

• How to actually wireframe fast (and stay fast)

• When to add fidelity (and when to stay scrappy)

• 📦 Resource Corner

But first…..

JOIN OUR TEAM

We are looking for a Community Engagement and Service Design Lead to support a community-funded initiative focused on strengthening relationships with local businesses and improving participation across a commercial corridor in Maryland.

If you are a strong communicator, a relationship builder, and available for some in-person work in the Maryland area, this one is for you.

Click Here To Apply

Why “low-fidelity” stopped being low-fidelity

Somewhere along the way, wireframes stopped being quick sketches and became mini design comps. Open most designers’ Figma files and their “low-fidelity wireframes” have:

• Carefully chosen gray scales (#F5F5F5 for backgrounds, #666666 for text)

• Proper 8px spacing grid applied

• Icons from a wireframe icon set

• Thoughtful typography hierarchy

• Subtle borders and shadows

• Component instances from their design system

This isn’t low-fidelity. This is medium-fidelity pretending to be low-fidelity. And it defeats the entire purpose of wireframing.

Here’s what happened:

🔹 Figma made it too easy to make things pretty Auto-layout, components, shared libraries. These tools are incredible for final design. But they made it frictionless to add polish to wireframes. So designers do, even when they shouldn’t.

🔹 Portfolios created pressure for “presentable” wireframes Case studies show polished wireframes because they look better in screenshots. Students and juniors copy this, thinking wireframes are supposed to look designed. They’re not.

🔹 Teams started reviewing wireframes like designs Stakeholders see clean wireframes and start giving feedback on visual details: “Can we try a different shade of gray?” “These buttons feel too rounded.” That’s not the conversation you should be having yet.

🔹 Design systems made components the default If your button component already exists, why not use it in wireframes? Because now you’re thinking about component states, variants, and styling instead of flow and structure.

The result: Designers spend hours creating wireframes that should take minutes. And worse, they start defending those wireframes like they’re finished designs because they invested so much time in them. (Source: “Sketching User Experiences” by Bill Buxton)

What you lose when wireframes look too finished

Pretty wireframes aren’t just slower. They actually damage your process in specific, measurable ways.

Here’s what breaks when wireframes are too polished:

❌ You get attached to ideas too early When you spend 3 hours making a wireframe pixel-perfect, you don’t want to throw it away. So when testing or feedback suggests a different approach, you resist. You try to make the current design work instead of exploring alternatives.

This is called the sunk cost fallacy: you’ve invested time, so you keep investing more even when you should cut your losses. (Source: Behavioral Economics research)

❌ Stakeholders critique the wrong things Show someone a rough sketch and they’ll say “I’m not sure this flow makes sense.” Show them a polished wireframe and they’ll say “Can we make this button blue?” or “I don’t like that font.”

Polish invites polish-focused feedback. Roughness invites structure-focused feedback. You need the second kind early in the process.

❌ You explore fewer options If each wireframe takes 2-3 hours, you’ll make 2-3 options max. If each wireframe takes 15 minutes, you’ll make 6-8 options. More options means better chance of finding the right solution.

Speed enables exploration. Polish kills it.

❌ You skip iteration When wireframes feel “done,” you move to high-fidelity instead of testing and iterating. But wireframes aren’t supposed to be done. They’re supposed to be tested, broken, rebuilt, and tested again.

❌ You conflate two different problems Wireframing should answer: Does this structure work? Does this flow make sense? Is this the right information hierarchy?

Visual design should answer: Does this feel like our brand? Is this accessible? Does this create the right emotional response?

When wireframes look designed, you’re trying to answer both sets of questions simultaneously. That’s slower and less effective than solving them sequentially.

💡 Reality check: If your wireframe could be mistaken for a grayscale final design, you’ve already added too much fidelity.

The speed vs. fidelity tradeoff nobody talks about

There’s a direct relationship between how good a wireframe looks and how much it costs to make. That cost isn’t just time. It’s flexibility, iteration, and exploration.

Here’s the actual tradeoff:

Paper sketch: 2-5 minutes

• Fastest to create, easiest to throw away

• Forces focus on structure, not details

• Can’t get attached because it’s obviously temporary

• Perfect for initial ideation and very early exploration

• Limitation: Hard to share remotely, can’t click through

Digital low-fi (actual low-fi): 10-20 minutes

• Boxes, lines, placeholder text

• No real typography, no careful spacing, no icons

• Fast enough to make 5-10 variations

• Easy to test structure and flow

• Can be shared and clicked through

• This is what wireframes should be most of the time

Digital medium-fi (what most people call “low-fi”): 1-3 hours

• Proper spacing, thoughtful grays, icon sets

• Starts to look presentable

• Slow enough that you’ll only make 2-3 options

• Stakeholders start critiquing visual details

• This should only happen after you’ve validated the structure

High-fidelity: 3-8 hours

• Real typography, brand colors, final spacing

• Component instances, proper states

• Looks like the final product

• Way too slow for exploration

• Only do this after everything else is validated

Most designers skip levels 1 and 2 and start at level 3. They call it “low-fidelity” but it’s not. And that skipping costs them speed, flexibility, and better solutions.

Before we continue, let’s talk about something important.

📍 Join us at DCTECH

Did you know that 70% of professionals landed their job at a company where they already knew someone?

Or that 54% of U.S. workers in 2025 were hired through a personal connection, not a job board, not a cold application?

Yet most of us still spend more time perfecting our LinkedIn profiles than actually being in the room where it happens.

Here’s your room.

───────────────────

🍹 DC Tech Happy Hour

Thursday, April 2 | 6:30 – 9:00 PM

Mission Dupont Circle, Washington DC

───────────────────

Refresh DC, Friends of Figma, UXDX & User Experience University are bringing together DC’s UX designers, product managers, researchers, and engineers for a night built around real connection.

And because showing up should come with perks:

🎟️ Win a FREE ticket to UXCON26

🎓 Every attendee gets 25% off UXCON26 just for coming

The tech workforce is projected to grow twice as fast as the overall U.S. workforce over the next decade. The people in that room on April 2nd? They’re part of that growth story, and so are you.

Don’t just read about the DC tech scene. Be in it.

Secure your spot 👇

Back to wireframes.

How to actually wireframe fast (and stay fast)

If you’re used to making pretty wireframes, forcing yourself to work faster and rougher feels uncomfortable. Here’s how to do it:

1. Start with paper (yes, actually)

Before touching Figma, spend 10 minutes with a pen and paper. Draw boxes. Scribble labels. Try 3-4 different layouts. This forces speed and prevents attachment.

You can’t make paper look polished, so you focus on what matters: does this structure make sense?

2. Use placeholder rectangles, not real content

Don’t write actual copy. Don’t find real images. Use gray boxes labeled “Headline” and “Product image.”

Why? Because real content tempts you to make it look good. Placeholders keep you focused on structure.

3. Don’t use your design system components yet

Make a simple rectangle and label it “Button.” Don’t instantiate your actual button component. That component has states, variants, and styling you don’t need to think about yet.

4. Resist auto-layout until later

Auto-layout is incredible for final designs. But in wireframes, it tempts you to perfect the spacing. Just stack boxes roughly. Alignment can be ugly. That’s fine.

5. Set a timer

Give yourself 15 minutes for a wireframe. When the timer goes off, you’re done whether it’s perfect or not. This forces you to focus on the essential structure and skip the polish.

This feels uncomfortable at first. You’ll want to adjust spacing, fix alignment, choose better grays. Don’t. The timer is your constraint. (Source: Timeboxing methodology)

6. Make 5 versions before picking one

Force yourself to explore. “What if the nav was here instead?” “What if this was one screen instead of two?” “What if we showed less information?”

You can only do this if each version is fast. If each one takes 2 hours, you’ll only make one and defend it to death.

7. Show your rough work to stakeholders

Yes, it feels vulnerable to show sketchy wireframes. Do it anyway. Say: “These are rough explorations to validate the structure before I add any design. Which direction feels right?”

Stakeholders appreciate being involved early. And rough wireframes keep the conversation focused on what matters.

When to add fidelity (and when to stay scrappy)

This doesn’t mean wireframes should always be ugly. There are specific moments when adding fidelity is the right move.

When to add fidelity:

✅ After you’ve tested the rough structure You made 5 rough wireframes, tested them with users or stakeholders, and now you know which direction works. Now you can add fidelity to that one direction.

✅ When you need to communicate specific interactions If the design depends on a particular micro-interaction or animation, rough boxes won’t communicate it. You need enough fidelity to show the interaction.

✅ When you’re handing off to developers Developers need more detail than stakeholders. Once the structure is validated, add fidelity so they understand spacing, component usage, and behavior.

✅ For your portfolio Yeah, polished wireframes look better in case studies. That’s fine. Just don’t create that polish during the actual design process. Clean them up afterwards for presentation.

When to stay rough:

✅ Any time you’re still exploring If you haven’t validated the approach yet, stay rough. You need speed and flexibility more than polish.

✅ When you’re testing with users Users don’t need pretty wireframes. They need something they can react to and critique. Rough works fine for usability testing.

✅ Early stakeholder reviews Show rough work early. Get directional feedback before investing in polish. This saves you from polishing the wrong thing.

✅ When you’re working on flow, not screens If you’re mapping a user journey or designing a multi-step process, stay rough. You’re solving for sequence and logic, not visual design.

The pattern: Add fidelity as certainty increases. Early in the process when everything is uncertain, stay rough. Later when you’ve validated the direction, add polish.

🎯 Take-home: Fidelity is a tool. Use it strategically, not by default.

📦 Resource Corner

Sketching User Experiences by Bill Buxton The foundational text on why sketching and rough exploration matter. Strong on the relationship between speed and creativity.

Wireframing for Everyone (NN/g) Research-backed guidance on when and how to wireframe. Good on the spectrum from rough to polished.

Balsamiq Wireframing tool that’s intentionally ugly. Forces you to stay rough by making polish difficult. Good training wheels for learning to wireframe fast.

Crazy 8s Exercise (Design Sprint) Rapid sketching exercise that forces you to generate 8 ideas in 8 minutes. Builds the muscle of quick, rough ideation.

Excalidraw Free sketching tool with a hand-drawn aesthetic. Makes it easy to stay rough and prevents over-polishing.

💭 Final Thought

The best wireframes are the ones you’re willing to throw away. And you’re only willing to throw something away if it didn’t cost much to make.

When you spend hours perfecting a wireframe, you’ve created emotional attachment. You’ll defend it even when evidence suggests it’s wrong. You’ll resist feedback. You’ll skip exploration because exploring means discarding your invested time.

But when a wireframe takes 15 minutes? Throw it away. Make another one. Try five different approaches. Test them. Break them. Start over. That’s how you find great solutions, not by making your first idea pretty.

Pretty wireframes aren’t a sign of craft. They’re a sign of premature optimization. You’re solving the wrong problem at the wrong time.

Stay rough longer. Explore more. Polish less. Your work will get better, not worse.

— The UXU Team

In this issue:

• The lies hiring managers spot immediately

• Why fabricating results is worse than having no results

• How to present real work (even when it’s messy)

• What to do when you genuinely don’t have metrics

• The honesty that actually impresses interviewers

• 📦 Resource Corner

The lies hiring managers spot immediately

Let’s be direct about what’s happening. Designers, especially junior ones, feel pressure to have impressive portfolios. So they embellish. They exaggerate. Sometimes they straight-up invent things. And hiring managers can tell.

Here are the red flags that scream “this didn’t really happen”:

🚩 Every project has perfect, round metrics “Increased conversion by 25%.” “Reduced bounce rate by 30%.” “Improved user satisfaction by 40%.” These numbers are suspiciously clean. Real metrics are messy: 23.7%, 18%, 34.2%. When every project ends in a multiple of 5 or 10, it looks made up.

🚩 The process is too perfect Real design is messy. You interview the wrong people. Stakeholders change their minds. Developers push back on your design. Timeline gets cut. But portfolio case studies show this perfect linear process: research → insights → wireframes → testing → shipping → success. That’s fiction.

🚩 No mention of constraints, tradeoffs, or failures Every real project has constraints. Budget. Timeline. Technical limitations. Stakeholder opinions. But portfolio projects never mention them. Every decision was optimal. Nothing was compromised. That’s not how work happens.

🚩 “I did everything” (on a team project) “I conducted the research, designed the solution, and shipped the feature.” If this was a real company with a real team, where was the PM? The researchers? The other designers? Taking sole credit for collaborative work is an instant credibility killer.

🚩 The timeline doesn’t make sense “I conducted 15 user interviews, analyzed the data, created wireframes, built high-fidelity mockups, ran usability tests, and launched in 2 weeks.” No, you didn’t. That’s 6-8 weeks minimum. Compressed timelines reveal that the story is fabricated.

🚩 Vague or missing company/client details “A fintech startup” instead of naming the company. “An e-commerce client” without specifics. If it was real work, you’d name them (or explain the NDA). Vagueness suggests it’s a practice project you’re pretending was real.

🚩 The problems are generic, the solutions are trendy “Users found the checkout confusing, so I simplified it” describes every checkout redesign ever. Real projects have specific, messy problems. Generic problems suggest you’re retrofitting a solution you saw elsewhere.

Why this matters: Hiring managers aren’t trying to catch you lying. But when they spot inconsistencies, they start questioning everything in your portfolio. One fabricated detail ruins your credibility on legitimate work.

Join Don Norman at UXCON26

Co-Founder, Nielsen Norman Group · Former VP of Advanced Technology, Apple · Founder, Design Lab at UC San Diego Headlining Keynote

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.

He coined the term “user experience.” He wrote The Design of Everyday Things, the book on virtually every designer’s shelf, now in its revised edition and still as essential as the day it was published. He helped found the world’s first Department of Cognitive Science at UC San Diego. He became Vice President of Advanced Technology at Apple. He co-founded the Nielsen Norman Group, the firm that shaped how the entire industry thinks about human-centered design. He has published 21 books translated into over 20 languages. He holds three honorary degrees and is a member of the National Academy of Engineering.

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

Why fabricating results is worse than having no results

The instinct makes sense: every article about portfolios says “show impact” and “include metrics.” So if you don’t have metrics, you feel like you need to invent them. But that’s backwards.

Here’s what actually happens when you fake results:

❌ You can’t defend them in interviews “Tell me more about that 30% conversion increase. What were you measuring? How did you isolate your changes from other variables?” If you made it up, you’ll fumble the answer. And now you’ve lost the job and your credibility.

❌ You set expectations you can’t meet If your portfolio shows you consistently deliver 20-40% improvements, that’s what the company will expect when they hire you. When you can’t deliver (because those numbers were fiction), you’ve set yourself up to fail.

❌ You miss the chance to show real thinking Honesty about what you don’t know is more impressive than fake confidence. “We didn’t have analytics set up, so I can’t give you hard numbers, but here’s the qualitative feedback we got” shows self-awareness and intellectual honesty.

❌ It reveals you don’t understand how metrics work Saying “I increased revenue by 50%” without explaining baseline, sample size, timeframe, or confounding variables shows you don’t actually understand measurement. That’s worse than admitting you don’t have data.

The truth that hiring managers won’t tell you: They don’t actually expect junior designers to have perfect metrics on every project. They know you’re early in your career. They know practice projects exist. What they’re looking for is honest thinking and real problem-solving ability.

A case study that says “I don’t have quantitative data, but here’s what I learned from user feedback” is infinitely more valuable than one with fabricated numbers.

How to present real work (even when it’s messy)

Real projects are messy. Constraints are real. You don’t get to do everything perfectly. That’s fine. Actually, that’s better for your portfolio because it shows you understand how design actually works.

Here’s how to present honest, messy work in a way that still gets you hired:

1. Be specific about your role (and the team)

Don’t say “I designed this feature.” Say exactly what you did:

✅ “I was one of two designers on this project. I focused on the mobile experience while Sarah handled desktop. I conducted 6 of the 12 user interviews, and we both participated in synthesis.”

This is honest. It shows collaboration. It shows you understand team dynamics. Hiring managers respect this infinitely more than inflated solo credit.

2. Show the constraints, not just the solution

Every project has limits. Talking about them makes your work more credible:

✅ “We had 3 weeks and a developer handoff deadline, so I prioritized wireframes and basic interactivity testing over high-fidelity mockups. Given more time, I would have tested more variations.”

This shows you make strategic tradeoffs. That’s a professional skill. Pretending constraints didn’t exist makes you look inexperienced.

3. Admit what you don’t know or didn’t measure

Honesty about gaps is professional:

✅ “We didn’t have analytics instrumentation for this feature, so I can’t provide conversion metrics. What I do have is usability test feedback from 5 users and support ticket volume before and after launch.”

This shows you understand the difference between quantitative and qualitative data. It shows you work with what you have. That’s real-world design.

4. Talk about what didn’t work

Failed experiments are learning opportunities. Show them:

✅ “My first concept tested poorly. Users found the navigation confusing. I went back, simplified the structure, and the second round of testing showed significant improvement in task completion.”

Iteration based on feedback is what design actually is. Showing only successes makes you look either inexperienced or dishonest.

5. Be honest about practice projects

If it’s a bootcamp project or self-initiated work, just say so. Then make it rigorous:

✅ “This is a self-initiated project. I identified a real problem with my local library’s website by interviewing 5 regular users. While this didn’t ship, the research and design process are real.”

Nobody expects you to only have shipped work if you’re junior. They expect you to demonstrate thinking. Practice projects are fine if you treat them seriously. (Source: Nielsen Norman Group on Portfolios)

6. Use qualitative data when you don’t have quantitative

User quotes, feedback themes, observation notes, support ticket reduction, stakeholder reactions. These are all valid forms of impact:

✅ “While we didn’t track conversion metrics, we saw support tickets related to checkout drop from ~30/week to ~5/week in the month after launch.”

This is real impact, honestly presented.

What to do when you genuinely don’t have metrics

Most junior designers don’t have access to metrics. Many companies don’t track things properly. Some projects ship and nobody measures the impact. This is normal. Here’s how to handle it honestly:

Option 1: Explain why metrics don’t exist

✅ “This was a client project and I didn’t have access to their analytics after handoff.” ✅ “The company didn’t have measurement infrastructure in place for this feature.” ✅ “This was exploratory work that informed strategy but didn’t result in a shipped product.”

These are all legitimate. Just state them matter-of-factly.

Option 2: Use proxy metrics or observations

If you don’t have hard numbers, look for other signals:

✅ “The redesigned form reduced the average support call length from 8 minutes to 3 minutes based on call center reports.” ✅ “User testing showed task completion time dropped from an average of 4 minutes to 90 seconds.” ✅ “In our usability tests, 4 out of 5 users completed the task successfully compared to 1 out of 5 with the old design.”

These aren’t conversion rates or revenue numbers, but they’re real measurements.

Option 3: Focus on the problem-solving process

If you have no outcome data at all, double down on showing your thinking:

✅ “I can’t measure the impact because the project was paused before launch, but I can walk you through how I identified the core user problem and my rationale for the design decisions.”

Your thinking process is actually what hiring managers care about most. The metrics are just evidence that the thinking worked. If you have strong thinking, that’s 80% of what matters.

Option 4: Be upfront that it’s a learning project

If it’s bootcamp work or practice:

✅ “This is a practice project I completed during my UX bootcamp. It’s based on research I conducted with real users, but it’s not a shipped product.”

Then show rigorous process. Show real research. Show thoughtful decisions. The fact that it didn’t ship is fine if the work is solid.

🎯 Take-home: Hiring managers would rather see honest thinking about a small project than fabricated metrics on a fake one.

The honesty that actually impresses interviewers

Here’s the paradox: the things designers think make them look weak are often what actually build credibility.

What you think makes you look bad but actually impresses:

✅ “I made a mistake in my initial approach” This shows self-awareness and learning. Everyone makes mistakes. Acknowledging yours shows maturity.

✅ “I don’t have access to the final metrics” This is honest about real-world constraints. Way better than making numbers up.

✅ “This was my first time doing [research method] and here’s what I learned” Growth mindset. Willingness to try new things. Reflective practice. All good signals.

✅ “The stakeholder pushed back on my recommendation and we had to compromise” This shows you work with real constraints and collaborate with non-designers. That’s a critical skill.

✅ “I would do this differently now” This shows you’re growing and learning from experience. Static skills are less valuable than learning ability.

✅ “I don’t know, but here’s how I’d figure it out” In interviews, admitting you don’t know something and explaining your problem-solving approach is stronger than bullshitting an answer.

What actually makes you look bad:

❌ Taking credit for team work as solo work ❌ Fabricating metrics you can’t defend ❌ Claiming you did research you clearly didn’t do ❌ Presenting polished work with no mention of process or iteration ❌ Being unable to explain your design decisions ❌ Pretending you have no weaknesses or learning areas

The pattern: Honesty about your actual experience and limitations, combined with clear thinking and genuine learning, beats fabricated perfection every time.

Hiring managers aren’t looking for designers who never make mistakes. They’re looking for designers who think clearly, learn from experience, and are honest about what they do and don’t know. That’s what builds trust. And trust is what gets you hired.

📦 Resource Corner

Honest UX Portfolio Examples (Bestfolios) Browse portfolios that show real work with honest context. Look for ones that mention constraints, team roles, and learning.

How to Show Process in Your Portfolio (NN/g) Research-backed guidance on what to include in case studies. Strong on showing thinking over just outcomes.

The Mom Test by Rob Fitzpatrick While focused on customer interviews, the core lesson applies to portfolios: honesty and specificity build more credibility than trying to impress.

Case Study Club Collection of case studies with varying levels of polish and honesty. Good for seeing different approaches to presenting real work.

Lenny’s Podcast: Portfolio Reviews Occasional episodes where industry leaders review portfolios. Listen for what they call out as credible vs questionable.

Portfolios for UX Researchers (Mixed Methods) While focused on research, the advice on presenting rigorous process and being honest about limitations applies to design portfolios too.

Redesigning Your Portfolio (A List Apart) Articles on presenting work honestly and effectively. Good on the narrative structure of case studies.

Final Thought

Portfolio dishonesty happens because designers are scared. Scared they’re not good enough. Scared they don’t have the “right” kind of experience. Scared everyone else’s work is better. So they embellish, exaggerate, or invent to compete.

But here’s what actually happens: the fabrication gets caught, credibility is destroyed, and the job goes to someone else. Or worse, you get hired based on fake credentials and can’t deliver what you claimed.

The alternative is simpler and more effective: be honest about what you did, what you learned, and what you still don’t know. Show real thinking, even on imperfect projects. Admit constraints. Talk about tradeoffs. Present yourself as someone who’s learning and growing, not someone who’s already perfect.

Hiring managers don’t want perfect designers. Those don’t exist. They want honest ones who can think clearly, learn quickly, and work with real-world constraints.

Your real work, honestly presented, is already good enough. Stop lying about it.

--The UXU Team

Instead of a chronological dump of dates, we’ve mapped some of the best UX conferences of 2026 by region. Whether you’re in DC, Copenhagen, Tokyo, or São Paulo, there’s a room somewhere in the world waiting for you. Here’s where to find it.

Region 01

🇺🇸 United States ———————————————

Featured In-Person Washington DC AreaOctober

UXCON26

📅 October 8, 2026📍 Silver Spring Civic Building, Silver Spring, MD💰

“The biggest UX conference on the East Coast - right in the heart of DC.”

After two years of bringing the UX community together for conversations that actually matter, we’re back with our biggest, most inspiring lineup yet. If you were at UXCON24 or UXCON25, you already know what this day feels like. If this is your first time hearing about us: welcome. You picked a good year to show up.

This is the event where practitioners, researchers, leaders like Don Norman, and builders come to think harder, connect deeper, and leave genuinely changed by the conversations they had.

Secure your spot

In-PersonSeattleApril

ConveyUX 2026

📅 April 13, 2026📍 Grand Hyatt Seattle, WA

Now in its 14th edition, ConveyUX returns as a leadership-focused summit for senior UX professionals. One intimate day of deep sessions centered on user research, interaction design, and content strategy. In 2026, the focus sharpens on AI transformation, design ROI, and executive leadership. Zero filler.

Get Tickets

In-PersonPhiladelphia April

Information Architecture Conference 2026 (IAC26)

📅 April 14–18, 2026📍 Arch Street Meeting House, Philadelphia, PA

The 27th annual gathering for IA academics and practitioners, themed “Navigating Complexity.” IAC26 explores how information architecture bridges user-centered design and the growing influence of AI — with lightning talks, in-depth sessions, and the legendary warmth of the IA community.

Secure your spot

In-Person + OnlineNew YorkMay

UXDX USA 2026

📅 May 11–13, 2026📍 New York, NY

One of the rare conferences that brings product, UX, design, and engineering under one roof. Built for cross-functional teams tired of working in silos, expect high-caliber speakers, real case studies, and sessions that challenge how teams ship together. They’ve sold out the last few years, so move fast.

Get Tickets

In-PersonLas Vegas June

UXPA International 2026

📅 June 22–25, 2026📍 Caesars Palace, Las Vegas, NV

The 35th edition of the world’s flagship UX professional conference. Four days at Caesars Palace - pre-conference workshops on Monday, then three days of keynotes, panels, and sessions. UXPA is the annual homecoming for UX practitioners worldwide who want to learn, connect, and shape the future of human-centered design.

Secure your spot

before we continue……

JOIN OUR TEAM

We are looking for a Community Engagement and Service Design Lead to support a community-funded initiative focused on strengthening relationships with local businesses and improving participation across a commercial corridor in Maryland.

If you are a strong communicator, a relationship builder, and available for some in-person work in the Maryland area, this one is for you.

Click Here To Apply

Region 02

🇪🇺 Europe —————————————————

ACM CHI 2026

📅 April 13–17, 2026📍 Barcelona Convention Center, Spain

The premier academic conference on Human-Computer Interaction, held at the International Barcelona Convention Center. This year introduces a streamlined 5-day format with paper presentations in the mornings and five interactive afternoon session categories. The global gold standard for HCI research — where the discipline’s most important ideas are published and debated.

Secure your spot

In-PersonAarhus, DenmarkApril

UX Nordic 2026

📅 April 15–16, 2026📍 Vue Bruuns Theater, Aarhus, Denmark

The fourth edition of the Nordic region’s premier UX event returns after a one-year hiatus. Day one: sponsor-free, carefully curated talks from respected industry experts, zero sales pitches. Day two: a full-day immersive workshop. Built for people who care deeply about their craft and want honest, peer-driven conversation.

Get Tickets

In-PersonRotterdamApril15% Off Code

UX Rotterdam 2026

📅 April 16–17, 2026📍 Zuidplein Theater, Rotterdam, Netherlands

Brand new on the European scene — the inaugural UX Rotterdam brings 650 professionals to one of Europe’s most forward-thinking design cities. 30+ keynotes and workshops across design, branding, research, strategy, and AI innovation — plus an evening program included in every ticket. Use code eventcon15 for 15% off registration.

Secure your spot

Leiden, Netherlands April

UXinsight Festival 2026

📅 April 20–22, 2026📍 Stadsgehoorzaal, Leiden, Netherlands

The 10th edition: a milestone anniversary, of the Netherlands’ premier UX research conference. The Stadsgehoorzaal transforms into a collaborative lab where researchers experiment, share real-world stories, and leave with practical ideas you can immediately apply to your own challenges.

A decade of advancing UX research, celebrated right.

Get Tickets

In-Person + Online Berlin May

UXDX EMEA 2026

📅 May 27–29, 2026📍 Berlin, Germany

The European counterpart to UXDX USA, three days of cross-functional learning for product, UX, design, and engineering teams. Same proven formula: real-world talks, collaborative formats, and sessions that challenge how teams actually work. Berlin adds its own creative grit to the mix.

Secure your spot

In-Person + OnlineVienna, Austria September

uxcon vienna 2026

📅 September 16–17, 2026📍 University of Vienna, Austria

Europe’s friendliest conference for UX research and design — now held at the historic University of Vienna. Known for its unusually thoughtful atmosphere: no sponsor noise, just practitioners sharing real experience. Topics span AI-era UX, accessibility, behavioral science, responsible design, and the evolving relationship between humans and machines.

Get Tickets

Region 03

🌏 Asia ————————————————————

In-PersonTokyo, JapanFebruary

DDX Tokyo 2026

📅 February 4, 2026📍 Tokyo, Japan

The Japan edition of the global DDX Conference Series, dedicated to UX, product design, digital innovation, and human–technology interaction. DDX Tokyo blends international perspectives with Japan’s unique design culture of craft, precision, and future-thinking. Conducted in English with Japanese translation. Intimate format; under 300 attendees. One of the most forward-looking conferences in Asia.

Get Tickets

In-PersonSingapore June

ACM DIS 2026 – Designing Interactive Systems

📅 June 13–17, 2026📍 National University of Singapore

Held at the National University of Singapore, ACM DIS 2026 explores how interactive systems connect with broader sociocultural, political, economic, and ethical dimensions,, from climate change to accelerating AI. A deeply research-oriented gathering for practitioners and academics shaping the next wave of responsible, human-centered design.

Tickets: TBA

Learn more

Region 04

🌐 Global & Online ————————————

No travel budget? No problem. These events bring world-class UX thinking wherever you are.

In-Person + VirtualSan Francisco + OnlineApril

Config 2026 by Figma

📅 April 6–9, 2026📍 San Francisco, CA + Virtual

Figma’s annual global design conference - 75+ speakers, 50+ sessions, and an inside look at where design and product development are heading next. Config is where the Figma team shares what they’re building, why it matters, and where real product teams get practical takeaways they can apply immediately. Virtual attendance makes it accessible to the entire global community.

Secure your spot

In-Person Multiple Cities Year-Round

DDX Global Conference Series

📅 Multiple dates in 2026📍 Tokyo · Dubai · Munich · London · New York · San Diego

Under 300 people, zero sales pitches, every detail designed for actual connection. The DDX series is built for people who want substance over spectacle and real conversations over conference chaos. 2026 brings six events across three continents. If you travel for work and want a room full of serious practitioners, this is your series.

Explore Cities

A note on

🌎 Latin America & Africa

The UX conference scene in Latin America and Africa is growing fast, but dedicated UX-specific events with confirmed 2026 dates are still limited in our research. Web Summit Rio brings thousands of tech professionals to Brazil, and community-led UX events are emerging across Nigeria, Kenya, Colombia, and Argentina. We’re committed to highlighting these as they’re confirmed. Know of one? Reply to this newsletter and we’ll add it to our running list. This guide belongs to all of us.

Start With Your Backyard.

If you’re in the DC area, the next step is right here.

Refresh DC, Friends of Figma, UXDX & User Experience University are bringing together DC’s UX designers, product managers, researchers, and engineers for a night built around real connection.

And because showing up should come with perks:

🎟️ Win a FREE ticket to UXCON26

🎓 Every attendee gets 25% off UXCON26 just for coming

Come meet the community at DC Tech Happy Hour on April 2nd and walk away with a 25% discount to UXCON26 just for showing up.

Grab Your Dc Happy Hour Tickets

Every event on this list is more than a conference - it’s a room full of people who chose to show up. For their craft. For their community. For growth. Wherever you are in the world, we hope you find your room in 2026. And when you do, look around - your next collaborator, mentor, or best idea might be standing right next to you.

— The UXU Team

This issue breaks down why most interface copy fails, what actually gets read, and how to write copy that works with human behavior instead of against it.

In this issue:

• Why users don’t read (even when they should)

• The 3-second rule for interface copy

• What users actually look at instead of reading

• How to write copy that gets used, not skipped

• When more words make things worse

• 📦 Resource Corner

Why users don’t read (even when they should)

Let’s start with the uncomfortable reality: users don’t read interfaces. They scan them.

This isn’t laziness. It’s not stupidity. It’s how humans efficiently process information when they’re trying to accomplish a task. Your users aren’t visiting your app to read. They’re visiting to do something. Reading is friction between them and their goal.

Steve Krug documented this decades ago in “Don’t Make Me Think”: users satisfice. They don’t look for the best option, they look for the first option that seems good enough. (Source: “Don’t Make Me Think” by Steve Krug)

Here’s what actually happens when someone opens your interface:

🔹 They scan for their goal Their eyes jump around looking for something that matches what they’re trying to do. A button. A link. A familiar pattern. They’re not starting at the top and reading down. They’re hunting.

🔹 They click first, read second (maybe) If something looks clickable and seems related to their goal, they click it. They don’t read the description first. They don’t hover for the tooltip. They just click and see what happens.

🔹 They only read when they’re stuck Error messages get read because something went wrong. Help text gets read when users have already tried and failed. Onboarding copy gets skipped unless the user is completely lost.

🔹 They assume, based on past experience That blue underlined text is probably a link. That X in the corner probably closes the modal. That form probably wants their email and password. They’re pattern-matching based on every other interface they’ve used, not reading your specific instructions.

The data backs this up: Eye-tracking studies consistently show that users fixate on interactive elements, images, and short labels. They skip paragraphs, ignore help text, and don’t read instructions until they’ve already made a mistake. (Source: Nielsen Norman Group Eye-Tracking Research)

This doesn’t mean copy doesn’t matter. It means copy needs to work with scanning behavior, not against it.

before we continue..

Did you know that 70% of professionals landed their job at a company where they already knew someone?

Or that 54% of U.S. workers in 2025 were hired through a personal connection, not a job board, not a cold application?

Yet most of us still spend more time perfecting our LinkedIn profiles than actually being in the room where it happens.

Here’s your room.

───────────────────

🍹 DC Tech Happy Hour

Thursday, April 2 | 6:30 – 9:00 PM

Mission Dupont Circle, Washington DC

───────────────────

Refresh DC, Friends of Figma, UXDX & User Experience University are bringing together DC’s UX designers, product managers, researchers, and engineers for a night built around real connection.

And because showing up should come with perks:

🎟️ Win a FREE ticket to UXCON26

🎓 Every attendee gets 25% off UXCON26 just for coming

The tech workforce is projected to grow twice as fast as the overall U.S. workforce over the next decade. The people in that room on April 2nd? They’re part of that growth story, and so are you.

Don’t just read about the DC tech scene. Be in it.

Secure your spot 👇

back to where we stopped….

The 3-second rule for interface copy

Here’s a useful heuristic: if users can’t understand what to do in 3 seconds, your copy failed.

Not 3 seconds of reading. 3 seconds of looking at the screen. That’s how long you have to communicate:

• Where am I?

• What can I do here?

• What should I do next?

If it takes longer than that, users start guessing. And guesses lead to mistakes, confusion, and abandoned tasks.

What this means in practice:

❌ This error message takes too long to parse: “We were unable to process your payment at this time due to insufficient funds in the account you provided. Please verify your account balance and try again, or use an alternative payment method.”

✅ This one works instantly: “Payment failed: Insufficient funds. Try a different card?”

The second version gives you the critical information (what failed, why, what to do) in one glance. The first version makes you read a paragraph to get the same information.

❌ This empty state is verbose: “You haven’t created any projects yet. Projects help you organize your work into manageable collections. To get started, click the ‘New Project’ button above and you’ll be guided through the setup process.”

✅ This one gets to the point: “No projects yet. Create your first one to get started.”

The button already says “New Project.” The empty state doesn’t need to re-explain it.

The pattern: Cut everything that doesn’t directly help the user take the next action. Every extra word is friction.

What users actually look at instead of reading

If users aren’t reading your carefully crafted copy, what are they looking at?

Here’s what gets attention in interfaces:

✅ Button labels These get read because they’re attached to actions. Users scan for buttons that match their intent. Make button labels verb-based and specific: “Send message” not “Submit.” “Delete account” not “Confirm.”

✅ Form field labels and placeholders People read these because they need to know what to type. Keep them short and clear. “Email address” is better than “Please enter your email address below.”

✅ Error messages (when something goes wrong) These get read because users are stuck. Make them specific about what failed and what to do next. “Email is required” is clearer than “Please fill in all required fields.”

✅ Headlines and section titles Users scan these to understand what’s on the page. Use clear, descriptive titles. “Billing settings” not “Manage your account.” “Team members” not “Collaboration.”

✅ Numbers and statistics Anything with digits stands out visually. “3 items” gets noticed. “A few items” gets ignored. “Save $20” gets noticed. “Save money” gets ignored.

✅ Contrasting or bold text (sparingly) If you bold one thing, it gets attention. If you bold everything, nothing gets attention. Use emphasis rarely, only for the most important word or phrase.

What gets ignored:

❌ Long paragraphs of explanation ❌ Helper text unless the user is already confused ❌ Tooltips unless the user hovers (and they won’t) ❌ Onboarding that appears before the user has context ❌ Terms and conditions (obviously) ❌ Microcopy that tries to be clever instead of clear

💡 Think like a billboard: You have 3 seconds while someone drives past at 60mph. What’s the minimum you need to communicate?

How to write copy that gets used, not skipped

Knowing that users scan instead of read changes how you should write. Here are the principles that make interface copy actually work:

1. Front-load the important information

Don’t bury the action or the consequence at the end of a sentence. Put it first.

❌ “In order to proceed with deleting your account, please confirm by clicking the button below.” ✅ “Delete your account? This can’t be undone.”

The second version tells you what’s happening and the stakes immediately. The first makes you parse a sentence structure to get the same info.

2. Use the simplest words possible

This isn’t about dumbing things down. It’s about reducing cognitive load. Users shouldn’t need to decode your vocabulary to use your interface.

❌ “Utilize the search functionality to locate specific items.” ✅ “Search for items.”

Fancy words slow people down. Simple words get processed instantly. (Source: Plain Language Guidelines)

3. Be specific, not generic

Generic copy forces users to interpret. Specific copy tells them exactly what will happen.

❌ “Are you sure?” (Sure about what?) ✅ “Delete this project?”

❌ “Something went wrong.” (What? Why? What do I do?) ✅ “Couldn’t save changes. Check your internet connection.”

4. Write for scanning, not reading

Structure your copy so key information jumps out:

• Use short sentences (10-15 words max)

• One idea per sentence

• Break up text with line breaks

• Put the action word first in buttons

❌ “You can create a new workspace by clicking on the button located in the top right corner of the dashboard.” ✅ “Create a workspace →” (And put that button where users expect it)

5. Match the user’s mental model

Use words users already use, not internal jargon or technically correct terms.

If your users call them “recipes,” don’t call them “formulas” in your interface. If they think of it as “sharing,” don’t label it “collaboration settings.”

This requires actually listening to how users describe things in research sessions. (Source: Mental Models by Indi Young)

6. Show, don’t tell (when possible)

Sometimes you can eliminate copy entirely by making the interface self-evident.

Instead of: “Click the star icon to favorite this item” Just show: ⭐ (and make it obviously clickable)

Instead of: “Drag items to reorder them” Just make items look draggable and respond to drag attempts

Visual affordances often communicate faster than words.

When more words make things worse

There’s a persistent belief in UX that more explanation = better experience. It’s not true. Often, adding more copy makes things harder to use.

Here’s when to cut, not add:

❌ When you’re explaining the interface instead of improving it

If you need a paragraph of help text to explain how a feature works, the feature is probably too complicated. Simplify the interface instead of documenting the complexity.

Example: Don’t write “Click the three dots to open a menu with additional options.” Just use a recognizable menu icon and put the most common actions directly visible.

❌ When you’re repeating information that’s already visible

Don’t tell users to “click the Save button below” if there’s clearly a Save button below. They can see it. The extra instruction is clutter.

❌ When you’re explaining what will happen before users have context

Onboarding tooltips that pop up before users have tried anything are useless. They don’t have the context to understand why they’d need that feature. Show help when it’s relevant, not preemptively.

❌ When you’re adding qualifiers and hedging

“You might want to consider adding a description” is weaker and longer than “Add a description.” Be direct. (Source: Voice and Tone Guidelines)

❌ When you’re being clever instead of clear

“Oops! Looks like gremlins ate your file” might seem fun, but “Upload failed. File too large.” is more useful. Clever is fine for marketing. Clarity is essential for interface copy.

The test: If you remove a sentence and users can still complete the task, that sentence was unnecessary. Cut it.

🎯 Take-home: The best interface copy is invisible. Users accomplish their goal without consciously reading anything.

📦 Resource Corner

Microcopy: The Complete Guide (UX Writing Hub) Comprehensive resource on writing effective interface copy. Full of before/after examples and specific patterns.

Voice and Tone by MailChimp One of the best public content style guides. Shows how to adapt tone for different situations while staying clear.

Strategic Writing for UX (Torrey Podmajersky) Practical book on writing interface copy that drives action. Strong on button labels, error messages, and microcopy patterns.

Don’t Make Me Think by Steve Krug Classic usability book that explains why users scan instead of read. The foundational text for understanding user behavior.

How Users Read on the Web (Nielsen Norman Group) Research-backed article with eye-tracking data showing exactly how people scan interfaces and what they skip.

Readability Guidelines Practical advice on making content readable and scannable. Good on sentence structure, word choice, and formatting.

Plain Language Guidelines (US Government) Government resource, but genuinely useful for writing clear, direct copy. Good checklist for editing down verbose text.

💭 Final Thought

The hardest thing for writers to accept is that most of their words will be ignored. You can craft the perfect error message, write clear onboarding, add helpful tooltips everywhere, and users will still skip most of it.

But that’s not a failure. That’s just how people use interfaces. They’re not there to read. They’re there to do something. Your job is to make that doing as effortless as possible.

Good interface copy doesn’t get read. It gets absorbed in a glance. It communicates instantly. It disappears into the background while users accomplish their goals.

The best compliment your copy can get is silence. No confusion. No support tickets. No users stopping to figure out what you meant. Just smooth, friction-free task completion.

That’s the goal. Not beautiful prose. Not clever wordplay. Just clarity that works so well it’s invisible.

Write less. Say more. Get out of the way.

--The UXU Team

In this issue:

• Why users can’t tell you what they want (even when they think they can)

• The questions that kill good research

• What great user interviews actually sound like

• How to dig deeper without leading the witness

• Turning messy conversations into clear design direction

• 📦 Resource Corner

Why users can’t tell you what they want (even when they think they can)

There’s a famous Henry Ford quote that gets thrown around a lot: “If I had asked people what they wanted, they would have said faster horses.” Whether he actually said it or not, the principle is real.

Users are experts in their problems. They are not experts in solutions.

When you ask someone “what feature would you like to see?” their brain does something predictable: it reaches for the closest thing they’ve already seen. They suggest features from competitor products. They ask for minor tweaks to what already exists. They give you incremental ideas, not transformative ones.

This isn’t a failure of imagination. It’s how human cognition works. We’re pattern-matching machines. When asked to envision something new, we remix the familiar. (Source: Kahneman, “Thinking, Fast and Slow”)

But here’s the deeper issue: users often don’t know what their real problem is.

They’ll tell you they want a faster checkout process. What they actually need is more trust signals because they’re worried about payment security. They’ll tell you they want more features. What they actually need is the existing features to work more reliably. They’ll tell you the interface is confusing. What they actually mean is the workflow doesn’t match how they think about the task.

Your job as a designer isn’t to collect feature requests. Your job is to understand the gap between what users say and what they actually need.

UXCON26 is partnering with the Interaction Design Foundation, and if you care about where UX is headed, you need to know what that means.

The IxDF isn’t a newcomer riding a wave. They’re the organization that has quietly built the world’s most trusted UX education platform, over 170,000 members across 180+ countries, industry-recognized certifications, and a curriculum shaped by decades of real design practice. When they put their name on something, the community pays attention.

And they’ve put their name on UXCON26.

What that means for you: a conference that doesn’t just talk about design education, it delivers it, live, with the people who wrote the curriculum. October 8th at the Silver Spring Civic Center is going to be unlike any design event you’ve attended.

We currently have a special offer running, but it closes tonight. If you’ve been sitting on it, this is your nudge.

Special Offer: Experience This Live

The questions that kill good research

Let’s start with what not to do, because these questions show up in user interviews constantly, and they all produce useless answers.

❌ “What features would you like to see?”

This question trains users to think like product managers, not users. They start pitching features. They tell you about other apps they like. They suggest things that sound good in theory but won’t actually solve their problem. You end up with a wishlist, not insights.

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

People lie. Not intentionally, but they do. When you describe a hypothetical feature, users imagine the best-case version. They imagine it working perfectly. They imagine themselves being more organized, more productive, more disciplined than they actually are. They say “yes, I’d definitely use that.” Then you build it and they don’t. (Source: Nielsen Norman Group on User Research)

❌ “Do you like this design?”

This is asking for an opinion, not an insight. Some people will say yes to be polite. Some will say no because they don’t like the color blue. Some will give you feedback based on personal taste rather than usability. You end up with subjective reactions, not data you can design from.

❌ “Why don’t you use [feature]?”

People are bad at explaining their own behavior after the fact. They’ll give you a rational-sounding explanation that has nothing to do with the real reason. This is called post-hoc rationalization, our tendency to create logical explanations for decisions we made unconsciously or emotionally.

❌ “How often do you do [task]?”

Memory is unreliable. Users overestimate how often they do things they think they should do (exercise, meal planning, budgeting) and underestimate how often they do habitual things (check email, scroll social media). The numbers they give you are usually wrong.

What all these questions have in common: They’re asking users to do your job for you. They’re asking users to analyze their own behavior, predict their future behavior, or design solutions. That’s not their expertise. Their expertise is living the problem.

What great user interviews actually sound like

Good user interviews don’t feel like interviews. They feel like conversations where you’re genuinely curious about someone’s life, work, or struggle.

Here’s the shift: stop asking about the product. Start asking about the context around the product.

Instead of “what features do you want?” ask questions like:

✅ “Walk me through the last time you [did this task].”

This gets you real behavior, not hypothetical behavior. You hear what actually happened: where they were, what tools they used, what went wrong, what they did when it went wrong, how they felt about it.

Example: “Walk me through the last time you tried to book a flight.” Then you hear: “I opened Google Flights, then Kayak, then went back to Google Flights, then checked the airline direct... it took like 45 minutes and I still wasn’t sure I got the best price.”

That’s a real insight. That’s a problem you can solve.

✅ “What’s frustrating about how you do this now?”

This gets you to pain points without asking users to design solutions. They’ll describe the emotional experience: “It takes forever.” “I never know if I’m doing it right.” “I have to ask someone for help every time.”

Those frustrations point to real opportunities.

✅ “What do you do when [problem] happens?”

This reveals workarounds, which are gold. When users build workarounds, they’re telling you the current solution is broken and showing you what the real need is.

Example: “What do you do when you can’t find what you’re looking for in the app?” Answer: “I just Google it and hope the right page comes up.” That tells you navigation is broken and search might be too.

✅ “Show me how you currently do this.”

Have them share their screen or show you physically how they work. Watch what they click. Watch where they hesitate. Watch what they skip. Observation beats self-reporting every time. (Source: Don Norman, “The Design of Everyday Things”)

Speaking of Don Norman, Join him at UXCON26

His work shaped the field long before UX had a familiar name.
His ideas changed how teams build products.
His writing brought clarity where there was confusion.
His thinking continues to guide designers, researchers, engineers, and leaders around the world.

Having him with us at UXCON26 is an honor.
Join us, learn from a legend, and experience what the future of UX can be.

Join Don Norman at UXCON26

let’s continue

✅ “Tell me about a time when this went really well.”

Positive examples teach you what success looks like from the user’s perspective. What conditions made it work? What did they value about that experience? This helps you understand what to optimize for.

✅ “What else have you tried?”

This reveals the competitive landscape from their perspective, shows you what didn’t work (and why), and often uncovers adjacent problems you didn’t know existed.

The pattern: All these questions are grounded in real behavior, real moments, real experiences. Not hypotheticals. Not opinions. Not feature requests.

How to dig deeper without leading the witness

The first answer someone gives you is almost never the real answer. It’s the surface answer, the socially acceptable answer, the answer they think you want to hear.

Your job is to dig deeper without putting words in their mouth.

The most powerful follow-up question in user research:

→ “Tell me more about that.”

It’s open-ended. It’s neutral. It doesn’t suggest an answer. It just gives them space to keep talking. And in that space, the real stuff comes out.

Other killer follow-ups:

→ “Why is that important to you?” Gets to underlying motivations and values.

→ “What happened next?” Keeps them in storytelling mode, which surfaces details they’d skip in summary mode.

→ “How did that make you feel?” Uncovers emotional responses, which often drive behavior more than rational factors.

→ “Can you give me an example?” Turns vague statements into concrete scenarios you can design for.

→ “What would have made that easier?” Gets them thinking about solutions in the context of a real moment, not abstract feature brainstorming.

The key is staying curious, not jumping to solutions. When someone says something interesting, resist the urge to say “oh, so what if we built a feature that...” Just keep asking questions. Keep them talking. The insights emerge from the stories, not from direct answers.

A real example of digging deeper:

You: “Walk me through the last time you tried to organize your receipts for taxes.”

User: “Oh, it’s a nightmare. I just throw everything in a folder.”

You: “Tell me more about that.”

User: “Well, I take photos of paper receipts on my phone, but then they’re mixed in with all my other photos. And digital receipts I just leave in my email.”

You: “What happens when you actually need to find a specific receipt?”

User: “I usually can’t. I just scroll through my photos for like 20 minutes hoping I took a picture of it. Or I search my email if I remember which company it was from.”

You: “How does that make you feel?”

User: “Honestly? Stupid. Like I know I should have a better system, but everything I’ve tried is too much work.”

You: “What have you tried?”

User: “I downloaded like three different receipt apps, but they all wanted me to manually categorize everything and it just felt like more work than the problem was worth.”

See what happened there? You started with “organize receipts” and learned:

• The real problem is retrieval, not storage

• Photos are the default capture method but create a findability problem

• They’ve tried dedicated tools but abandoned them because of friction

• The emotional trigger is feeling disorganized, not the receipts themselves

That’s enough insight to design something valuable. And you never asked “what feature do you want?”

Turning messy conversations into clear design direction

Okay, so you’ve done great interviews. You’ve got pages of notes full of stories, frustrations, workarounds, and context. Now what?

This is where a lot of designers get stuck. They have rich qualitative data but no clear path to design decisions.

Here’s a process that works:

1. Look for patterns across interviews

After 5-7 interviews, you’ll start hearing the same things repeatedly. Those repetitions are your signal. Create a simple list:

• What problems came up in 3+ interviews?

• What workarounds did multiple people mention?

• What emotions came up repeatedly?

2. Identify the “jobs to be done”

What is the user actually trying to accomplish? Not what they said they wanted, but what functional and emotional job are they hiring your product to do? This framework, developed by Clayton Christensen, helps you see past feature requests to real needs. (Source: “Competing Against Luck” by Clayton Christensen)

Example: Users aren’t hiring your budgeting app to “track expenses.” They’re hiring it to “feel in control of their money and not be surprised by their bank balance.”

3. Map the current experience, warts and all

Create a journey map or workflow diagram that shows how users currently solve the problem, including all the friction points, workarounds, and emotional highs and lows. This becomes your “before” state.

4. Prioritize what to solve first

Not all problems are equal. Ask:

• Which problem showed up most frequently?

• Which problem caused the most frustration?

• Which problem has the biggest gap between current and desired state?

• Which problem can you actually solve given your constraints?

5. Design for the real behavior, not the ideal behavior

Users told you what they actually do, which is often different from what they think they should do. Design for reality. If users told you they only organize receipts once a year in a panic before tax deadline, don’t design a system that requires daily categorization.

🎯 Take-home: Good research gives you a clear problem statement and real constraints. From there, you can explore solutions with confidence that you’re solving the right problem.

📦 Resource Corner

The Mom Test by Rob Fitzpatrick The single best book on asking good research questions. Short, practical, and full of real examples. Especially strong on why most questions fail and what to ask instead.

Just Enough Research by Erika Hall Practical guide to doing user research that actually informs design. Covers when to do research, how to structure interviews, and how to synthesize findings.

Nielsen Norman Group: User Interviews Research-backed guidance on conducting effective user interviews, including question frameworks and common pitfalls.

Jobs to Be Done Framework Understanding the “job” users are trying to accomplish helps you see past surface requests to deeper needs.

Interviewing Users by Steve Portigal Comprehensive guide to the craft of user interviewing. Good for both beginners and experienced researchers.

UserInterviews.com Blog Practical articles on research methods, recruiting participants, and analyzing findings.

Final Thought

The best product insights don’t come from asking users what they want. They come from understanding what they struggle with, what they’ve tried, what they’ve given up on, and what they do when things go wrong.

Users are incredibly generous with this information when you ask the right questions. They’ll tell you stories. They’ll show you their messy workarounds. They’ll describe their frustrations in vivid detail. Your job is to listen carefully, dig deeper when something sounds interesting, and resist the urge to jump to solutions.

The designers who build products people love aren’t the ones who do what users ask for. They’re the ones who understand users deeply enough to build what they actually need, even when users couldn’t articulate it themselves.

That skill, listening past the surface, is learnable. Start practicing it in your next conversation.

--The UXU Team

UXCON26 is partnering with the Interaction Design Foundation, and if you care about where UX is headed, you need to know what that means.

The IxDF isn’t a newcomer riding a wave. They’re the organization that has quietly built the world’s most trusted UX education platform, over 170,000 members across 180+ countries, industry-recognized certifications, and a curriculum shaped by decades of real design practice. When they put their name on something, the community pays attention.

And they’ve put their name on UXCON26.

What that means for you: a conference that doesn’t just talk about design education, it delivers it, live, with the people who wrote the curriculum. October 8th at the Silver Spring Civic Center is going to be unlike any design event you’ve attended.

Special Offer: Experience This Live

Why the design community is paying attention

IxDF’s curriculum, live in the room. Their evidence-based, practitioner-led framework comes off the screen. Expect sessions built on the same rigor that’s shaped 170,000+ design careers.

Their global network, in one space. When IxDF shows up, their community follows. You’ll be in a room with designers, researchers, and product leaders who’ve built careers on their platform.

Exclusive resources you won’t find elsewhere. Co-branded learning materials, content previews from IxDF’s revamped platform, and takeaways built to last well beyond October 8th.

A career-level conversation. IxDF’s mission is to help designers build lives they love. This event is where that mission gets practical - through real connection and expert insight.

What to expect on October 8th

✅ Keynotes from industry legends - Including a keynote and live Q&A with Don Norman, the godfather of user experience and co-founder of Nielsen Norman Group. Hearing him speak in 2026 is a once-in-a-career opportunity.

✅ Talks from world-class practitioners - Speakers like Calvin Robertson (design leader at Corning, formerly Federal Reserve Bank, Lowe’s & Best Buy), Niyati from Netflix, Amanda and more - sharp, practical perspectives you’ll be quoting in meetings for months.

✅ Panels that go deep - Conversations between practitioners on the challenges actually shaping the field right now.

✅ One-on-one sessions with UX pros - Ask questions, pitch yourself, get personalized career advice from seasoned practitioners.

✅ Networking throughout the day - Unlimited coffee, product stands, and a room full of researchers, designers, product managers, and builders. The connections you make here last well beyond October 8th.

⚡ Special Offer - 3 Days Only. Ends Friday at Midnight.

As part of the UXCON26 × IxDF partnership, we’re running a special offer on tickets for the next 3 days only. It disappears at midnight on Friday. If you’ve been thinking about it, this is the moment.

Get Your UXCON26 Ticket

🔒 Offer closes Friday at midnight. Don’t miss it.

While you’re at it - explore IxDF’s revamped platform

The IxDF just relaunched their home. From your first course to your next job, it’s all in one place. Whether you’re breaking into UX, leveling up, or pivoting from another field, this is where that journey starts.

Design a Life You Love

Know a UXer who should be in the room? Forward this to them. The more great minds we bring together, the better this day gets for everyone.

See you October 8th.

UXCON26 × Interaction Design Foundation · October 8, 2026 · Silver Spring Civic Center

Same spacing patterns. Same everything. Users can’t tell companies apart anymore, and designers feel like they’re just assembling Lego blocks instead of actually designing.

Here’s why this happened, when consistency becomes a problem, and how to build systems that help instead of handcuff.

In this issue:

• Why every SaaS product looks exactly the same now

• The hidden cost of “perfect” consistency

• When your design system should bend (or break)

• How to build flexibility into rigid systems

• The difference between good constraints and creative death

• 📦 Resource Corner

Why every SaaS product looks exactly the same now

Open five B2B SaaS products right now. Go ahead. Pick any five. Chances are they all have:

• White or light gray backgrounds

• Blue primary buttons (that exact same shade of blue)

• Sans-serif fonts (probably Inter, Roboto, or SF Pro)

• 8px spacing grid

• Rounded corners (4px or 8px radius)

• The same card component with subtle shadows

• Left-side navigation that collapses to icons

• Avatar circles in the top right

• Pastel accent colors

• That same empty state illustration style

It’s not a coincidence. It’s design system convergence. And it happened fast.

Here’s what caused it:

🔹 Material Design and Apple’s HIG set the template Google and Apple published comprehensive design systems. Companies copied them. Then everyone copied each other. (Source: Material Design)

🔹 Design system libraries became default starting points Ant Design, Chakra UI, MUI, Tailwind UI. These are excellent tools. But when everyone starts from the same component library, everyone ends up with similar-looking products.

🔹 “Best practices” became “only practices” Design blogs and courses taught the same patterns. Use 8px grids. Make buttons 40px tall. Use consistent spacing. These are good guidelines, but they became rigid rules that everyone follows identically.

🔹 Speed became more valuable than differentiation Startups needed to ship fast. Using an off-the-shelf design system was faster than creating a unique visual identity. So they all picked the same systems.

🔹 Designers optimize for internal efficiency over user experience Design systems make it easy to build new screens quickly by reusing components. That’s great for productivity. But it also means every screen starts looking like every other screen, inside your product and across different products.

The result? Visual homogeneity. Products that are technically well-designed but completely forgettable. Users can’t tell them apart. Brands have no visual personality. Everything feels like a template.

The hidden cost of “perfect” consistency

Design systems sold themselves on consistency, and consistency is genuinely valuable. It makes products learnable. It makes design and development faster. It reduces decision fatigue.

But there’s a dark side nobody talks about: over-consistency kills the things that make products memorable.

Here’s what gets lost:

❌ Visual hierarchy gets flattened When every button is the same size, every heading uses the same weight, and every card has the same styling, nothing stands out. Everything is equal, which means nothing is important. Users can’t tell what to look at first.

❌ Emotional resonance disappears Great design makes you feel something. It has personality. It surprises you. It delights you. But design systems optimize for predictability, not emotion. Every interaction feels the same, so nothing feels special.

❌ Context-specific solutions become impossible Design systems give you components that work in most situations. But “most situations” is not the same as “this specific situation.” Sometimes the standard button doesn’t work. Sometimes you need something custom. But design systems make custom feel wrong.

❌ Designers stop designing When your job becomes “use the approved components in the approved ways,” you’re not designing anymore. You’re templating. Junior designers never learn how to make design decisions because the system made all the decisions already.

❌ Products lose competitive differentiation If your product looks and works exactly like every competitor, why would users choose you? Visual identity used to be part of brand strategy. Now it’s an afterthought because “we have to be consistent with the system.”

💡 Reality check: Consistency is a tool, not a goal. The goal is a great user experience. Sometimes that requires inconsistency.

Hold up… Join us at UXCON26

The UX landscape is shifting fast. The designers who stay ahead are the ones who invest in their craft and their community.

That’s what UXCON26 is built for.

One packed day of sessions from practitioners solving hard problems right now. Workshops that build real skills. And the kind of hallway conversations that turn strangers into collaborators.

Come ready to be challenged. Leave knowing exactly where your work is headed.

Join us at UXCON26

back to where we stopped….

When your design system should bend (or break)

Let’s be clear: not every screen deserves to break the rules. Most of the time, using standard components is the right call. But there are specific moments when following the system too strictly makes the experience worse.

Here’s when to break (or bend) your design system:

✅ High-stakes moments that deserve special treatment

Onboarding. Checkout. Error states that could lose the user. These aren’t normal screens. They’re critical moments in the user journey. They deserve custom design that makes them feel important.

Example: Stripe’s checkout doesn’t look like the rest of their dashboard. It’s visually distinct because the stakes are high and they want users to trust it. (Source: Stripe)

✅ Marketing or landing pages

Your product needs personality to attract users. Marketing pages should feel like your brand, not like every other SaaS dashboard. This is where you tell your story, show your differentiation, and make an emotional connection.

Don’t force landing pages into the same components you use for data tables and settings screens.

✅ Empty states and first-time experiences

These screens have one job: make someone want to use your product. A generic empty state with a standard icon and “No items yet” text doesn’t do that. This is where illustration, storytelling, and visual interest matter.

✅ Moments of delight

Completing a goal. Hitting a milestone. Unlocking something new. These moments should feel special. Use animation, color, unique layouts. Make them memorable. Design systems often strip this out because it’s “off-brand” or “inconsistent.”

✅ Complex, domain-specific interfaces

Financial dashboards. Medical records. Design tools. These have unique requirements that standard components can’t solve. You need custom visualizations, specialized controls, domain-specific patterns.

Trying to force these into a generic design system creates a worse experience than building custom solutions.

✅ When the standard component objectively fails

Sometimes the approved button is too small for this context. Sometimes the standard table doesn’t handle this data well. Sometimes the spacing feels wrong. Trust your design judgment. If the system isn’t working, don’t force it.

The test: Ask yourself: “Is following the system making this experience better or just easier for me?” If it’s just easier, that’s not good enough.

How to build flexibility into rigid systems

The problem isn’t design systems themselves. The problem is how they’re implemented. Most design systems are too rigid because they’re built for consistency above all else.

Here’s how to build systems that enable great design instead of preventing it:

1. Build in multiple levels of components

Not everything needs to be a locked, atomic component. Have three levels:

🔹 Foundations (locked) → Colors, typography, spacing values, grid system. These stay consistent.

🔹 Core components (mostly locked) → Buttons, inputs, cards, modals. Standard patterns that solve common problems. Use these most of the time.

🔹 Flexible patterns (unlocked) → Layout patterns, composition examples, principles instead of rules. These show how to apply the foundations in new ways.

Most systems only have the first two levels. The third level is what gives designers room to solve unique problems. (Source: Nathan Curtis on Design System Levels)

2. Document when to break the rules

Don’t just say “use the button component.” Say “use the button component for standard actions. For high-stakes CTAs or moments that need emphasis, here’s how to create variations.”

Make rule-breaking official. Give designers permission and guidance for when standard components aren’t enough.

3. Use design tokens for easy customization

Instead of hard-coded values, use tokens. This lets you customize components for specific contexts without breaking the system.

Example: Your standard button uses color-primary and spacing-medium. But for your checkout page, you can override those tokens to color-emphasis and spacing-large without rebuilding the component.

4. Show examples of good inconsistency

Include case studies in your design system docs that show when someone broke the rules well and why. This teaches designers how to think, not just what to use.

Example: “We built a custom data visualization for the analytics dashboard because standard charts didn’t show the relationships our users needed to understand.”

5. Make custom components easy to build

Don’t make designers go rogue and build components in isolation. Give them primitives, composable building blocks that let them create new patterns that still feel cohesive.

Example: Instead of only having a “Card” component, have “Box,” “Stack,” and “Text” primitives that designers can compose into custom layouts that still use your spacing and color tokens.

6. Review and absorb good deviations

When designers build something custom that works well, don’t punish them for going off-system. Review it. If it’s good, add it to the system. Let the system evolve based on real needs, not just consistency for consistency’s sake.

🎯 Take-home: The best design systems are living documents that grow with real product needs, not static rulebooks that designers have to fight against.

The difference between good constraints and creative death

Constraints are essential for good design. But there’s a difference between helpful constraints and ones that just kill creativity.

Good constraints:

✅ Limit choices so you can focus on the hard problems
✅ Create a shared language across teams
✅ Prevent designers from reinventing solved problems
✅ Make products learnable because patterns repeat
✅ Speed up implementation of standard screens

Example: “Use our spacing scale (4px, 8px, 16px, 24px, 32px)” is a good constraint. It prevents random spacing and creates visual rhythm without telling you exactly how to use space.

Bad constraints:

❌ Force you to use solutions that don’t work for the problem
❌ Punish designers for solving real user problems
❌ Optimize for visual consistency over user needs
❌ Make every screen feel identical regardless of context
❌ Turn designers into component assemblers instead of problem solvers

Example: “Every screen must use the standard page template with left nav and content area” is a bad constraint if some screens need full-width layouts or different navigation patterns.

How to tell the difference:

Ask: “Does this constraint help me solve the user’s problem, or does it just make my life easier?”

If it’s only making your life easier as a designer or developer, it might be a bad constraint. Good constraints guide you toward better solutions. Bad constraints guide you toward easier solutions.

The balance: Design systems should make common things easy and custom things possible. Right now, most systems make common things easy and custom things impossible.

📦 Resource Corner

Design Systems by Alla Kholmatova One of the best books on building design systems that balance consistency with flexibility. Goes deep on when to systematize and when to leave room for creativity.

Untitled UI A design system that shows how to build flexibility into components. Good examples of how to document variations and when to use them.

Modulz/Radix Component library built on composable primitives instead of rigid components. Shows how to give designers building blocks instead of finished pieces.

Nathan Curtis - EightShapes Nathan writes extensively about design systems. His articles on component levels, documentation, and governance are essential reading.

Design System Governance (NN/g) Research-backed guidance on how to manage design systems without making them too rigid. Good on balancing control and creativity.

Brad Frost - Atomic Design The methodology that started the component-based design system trend. Still valuable for understanding how to think about component hierarchies.

Final Thought

Design systems were supposed to free designers from repetitive decisions so they could focus on hard problems. But we over-corrected. We built systems so rigid that they removed all the decisions, even the important ones.

The goal was never to make everything look the same. The goal was to make the easy stuff easy so designers could spend time on what matters: understanding users, solving real problems, and creating experiences that feel crafted, not templated.

Your design system should be a tool that helps you design better, faster. If it’s preventing you from designing at all, if every screen feels like every other screen, if you’re fighting the system to build something good, then the system is the problem.

Good design systems have rules. Great design systems know when to break them.

— The UXU Team

But the designers who keep winning through every wave of change aren’t the ones who learn tools fastest. They’re the ones who understand people deepest.

You already know this. You’ve seen it. The researcher who asks the one question that reframes the whole product direction. The designer who walks into a stakeholder meeting and shifts the room. The IC who sees the systemic problem three sprints before anyone else does.

These 10 skills are what those people have in common. They’re worth investing in like compound interest because the returns only grow.

01 · User Research

Listening better than anyone in the room

You know the moment: a participant says “it’s fine” while visibly hesitating. The skill isn’t the interview guide. It’s knowing what to ask next, and how to create enough safety that people tell you what they actually think.

Research is about constructing the right questions, reading what’s unsaid, and turning messy human behaviour into something a product team can act on.

📌 Contextual inquiry · User interviews · Usability testing · Diary studies · A/B testing 🔗 User Interviews Blog

The gap between what users say they do and what they actually do - that’s where all the real insight lives.

02 · Information Architecture

Making complexity navigable

Before any component gets placed, someone has to decide how information relates to other information. IA is the invisible skeleton users feel without ever seeing it. Get it wrong and no visual polish saves you. Get it right and even a simple product feels effortless.

The hardest part isn’t building it. It’s inheriting five years of product entropy and untangling the structure without breaking users’ existing mental models.

📌 Card sorting · Tree testing · Sitemap design · Navigation patterns · Mental models 🔗 Optimal Workshop Academy · The Polar Bear Book

03 · Interaction Design

Designing how things behave, not just look

Every tap, hover, error state, and transition is a conversation between the product and the user. IxD means thinking in time: how someone moves through a flow across minutes and sessions, not just how a single screen renders.

Affordance. Feedback. Constraint. These principles predate software and will outlast every tool that comes next.

📌 Flow mapping · State design · Microinteractions · Affordance theory · Error handling 🔗 The Design of Everyday Things · Smart Interface Design Patterns

Don Norman’s “gulf of evaluation” explains more product failures than any other single concept. Close that gulf and you’re doing your job.

SPEAKING OF DON NORMAN

He coined that concept. He wrote the book that shaped how this entire field thinks about design. And this year, he’s taking the stage at UXCON26.

If you’ve spent any time in UX, you know what it means to hear someone like Norman think out loud, not from a keynote slide deck, but in conversation, in real time, with a room full of people who actually care about this work. That’s what UXCON26 is built for.

We currently have a special offer running, but it closes tonight. If you’ve been sitting on it, this is your nudge.

Join Don Norman at UXCON26

04 · Accessibility

Design that works for every human, full stop

1 in 4 adults has a disability. Designing without considering this isn’t a niche concern, it’s excluding a quarter of your audience by default. And with an ageing global population, that share only grows.

The curb-cut effect is real: what you build for people with disabilities consistently improves the experience for everyone else too. Accessibility isn’t a checklist at the end of the project. It’s a lens applied from the first wireframe.

📌 WCAG 2.1/3.0 · Screen reader testing · Keyboard navigation · Cognitive load · Color contrast 🔗 W3C WCAG Guidelines · Microsoft Inclusive Design · Deque Axe Tools

05 · Storytelling and Presenting

Making others feel the user’s experience

The best research in the world dies in a readout if it isn’t structured well. The best design dies in review if the designer can’t defend it. Problem, insight, solution, impact: that narrative structure works every time, in every room.

Senior designers spend more time communicating design than making it. The sooner you treat presentation as a core craft skill, the faster everything else accelerates.

📌 Research readouts · Design critiques · Executive storytelling · Case study writing · Workshop facilitation 🔗 Duarte Presentation Resources · Presenting Design Work (A Book Apart)

Designers who present with clarity get their work shipped. The rest get their decisions made for them.

06 · Systems Thinking

Seeing the whole board, not just this screen

Designing one screen well is a skill. Designing a system that makes 10,000 future screens consistent, accessible, and fast, that’s a different order of thinking entirely.

Design systems work means understanding tokens, component APIs, documentation, and governance. It means caring about the designer who inherits your work two years from now as much as the user who sees it today.

📌 Atomic design · Token architecture · Component documentation · Design-dev handoff · Governance 🔗 DesignSystems.com · Atomic Design by Brad Frost

07 · Psychology and Cognitive Science

Understanding why people actually click

Users don’t read, they scan. They don’t evaluate options rationally, they pattern-match from memory. They don’t decide logically, they feel first and justify later.

Fitts’s Law, Hick’s Law, cognitive load theory, the Von Restorff effect — these aren’t trivia. They’re the operating system underneath every good design decision. The designers who know them don’t just make better work; they argue for it more convincingly.

📌 Cognitive load · Gestalt principles · Behavioral nudges · Dark pattern awareness · Mental models 🔗 Laws of UX (free) · Thinking, Fast and Slow

08 · Visual Design Fundamentals

Training your eye, not just your tools

Tools are democratising interface creation fast. But trained visual judgment — knowing when a layout breathes, when contrast creates hierarchy, when a typeface choice signals intent - that remains deeply human.

You don’t need to be a graphic designer. You need enough visual vocabulary to evaluate and improve any interface you’re responsible for.

📌 Grid systems · Type hierarchy · Color theory · White space · Gestalt proximity 🔗 Refactoring UI · Type Scale Tool

Aesthetics without function is decoration. Function without aesthetics is friction.

09 · Cross-Functional Collaboration

Designing with engineers and PMs, not around them

Design doesn’t ship in isolation. The UX designer who can speak the language of engineering constraints, connect design decisions to business outcomes, and hold the user’s perspective under pressure - that person is irreplaceable.

Collaboration is a skill, not a personality type. It can be studied, practiced, and meaningfully improved. The Sprint methodology didn’t just create a framework; it created a shared vocabulary for alignment. That’s the deeper lesson.

📌 Design sprints · Stakeholder alignment · Critique facilitation · Design advocacy · Trade-off negotiation 🔗 The Sprint Book ·

10 · Critical Thinking and Ethical Design

Knowing when to push back - and how

As AI automates more of UX execution, the questions that matter most are the ones it can’t answer. Should we build this at all? Who does this harm? What happens two steps downstream?

The designer who thinks critically about consequences, who looks at a pattern and sees not just its conversion rate but its human cost - will be the most valuable person in any product room this decade. This is the skill that turns a good designer into someone a team actually needs.

📌 Dark pattern recognition · Ethical frameworks · Consequence mapping · Inclusive framing 🔗 Ethics for Designers · Center for Humane Technology · Design Justice, MIT Press (free)

Design is never neutral. Every default, every opt-out, every notification cadence is a value judgment.

None of these have an expiry date. They don’t belong to any tool, any trend, or any AI moment. They belong to the practice of understanding humans - which is the oldest and most durable work in this field.

Pick one you’ve been neglecting. Go deep on it. Then pick the next.

—

The UXU Team

After two years of bringing the UX community together for conversations that actually matter, we’re back with our biggest, most inspiring lineup yet. If you were at UXCON24 or UXCON25, you already know what this day feels like. If this is your first time hearing about us: welcome. You picked a good year to show up.

This is the event where practitioners, researchers, leaders, and builders come to think harder, connect deeper, and leave genuinely changed by the conversations they had. We don’t do surface-level. We go into the work.

And this year, the work starts with someone who invented the field.

The Speakers

#01 · Don Norman

Co-Founder, Nielsen Norman Group · Former VP of Advanced Technology, Apple · Founder, Design Lab at UC San Diego Headlining Keynote

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.

He coined the term “user experience.” He wrote The Design of Everyday Things, the book on virtually every designer’s shelf, now in its revised edition and still as essential as the day it was published. He helped found the world’s first Department of Cognitive Science at UC San Diego. He became Vice President of Advanced Technology at Apple. He co-founded the Nielsen Norman Group, the firm that shaped how the entire industry thinks about human-centered design. He has published 21 books translated into over 20 languages. He holds three honorary degrees and is a member of the National Academy of Engineering.

One of his postdoctoral fellows at UCSD once told him he was wrong. That postdoc 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. His latest book, Design for a Better World: Meaningful, Sustainable, Humanity Centered, pushed him beyond writing into action. He now runs the Don Norman Design Award, a global charity recognizing early career practitioners doing humanity-centered design, with applications from 26 countries.

He does not just think about where design needs to go. He is doing something about it.

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

Today, we are celebrating our speaker announcement with a special Unveiling Discount, available for the next 3 days only. This offer expires Friday at midnight.

Join Don Norman at UXCON26

#02 · Calvin Robertson

Enterprise Design Leader Keynote Speaker

Calvin Robertson is a designer, leader, and educator with over two decades of experience in human-centered innovation. He has built and led design teams at the Federal Reserve Bank, Lowe’s, and Best Buy, delivering enterprise solutions across retail, finance, education, and manufacturing. He currently leads Employee Experience within Global IT at Corning, overseeing UX, communications, and learning and development with a focus on building a design culture rooted in creativity, transparency, and meaningful connection.

Beyond enterprise design, Calvin is expanding into the gaming industry through Jubileague, where he founded a youth mentorship program called Playmaker to guide aspiring game designers in creating original, resonant experiences.

His session, Overflowing Leadership, brings all of that together: what it looks like when design thinking, strategic planning, and genuine care for people drive outcomes at every level of an organization.

#03 · Amanda Gelb

Founder · Aha Studio Keynote Speaker

Amanda’s official title is Professional Question Asker. She is not joking, and once you see her work, you will understand why that is exactly the right description.

Through Aha Studio, Amanda designs high-impact workshops and learning experiences that spark genuine insight and move people toward real action. She specializes in translating complex challenges into clear frameworks that help teams move forward with confidence. Her keynote at UXCON26 will be sharp, practical, and the kind of thing you find yourself quoting in meetings for months afterward.

before we continue……

JOIN OUR TEAM

We are looking for a Community Engagement and Service Design Lead to support a community-funded initiative focused on strengthening relationships with local businesses and improving participation across a commercial corridor in Maryland.

If you are a strong communicator, a relationship builder, and available for some in-person work in the Maryland area, this one is for you.

Click Here To Apply

#04 · Niyati Gupta

Product Design Lead · Netflix Speaker and Panelist

People ask Niyati what she does at Netflix. She tells them she designs. What she does not say is that half her job never shows up in a design file.

Niyati shapes global commerce and partnership experiences at Netflix. Over the past decade she has led design at Google and WhatsApp, building products used by hundreds of millions of people. Her superpower is the messy middle: the space where user needs, business goals, and engineering constraints do not naturally agree. She has spent her career helping cross-functional teams find clarity there and making sure design has a real voice when it matters most.

Her talk, The Invisible Work of UX, pulls back the curtain on the facilitation, the framing, and the organizational influence that separates good designers from indispensable ones. You will leave with a new lens on the hidden work that makes design matter at every level, and concrete ways to practice it whether you are growing into leadership or already there.

#05 · Raven Adaramola

Senior Product Designer · The New York Times Panelist

Millions of people open the New York Times Games app every single day to play Wordle, Connections, or The Crossword. Raven Adaramola helps design that experience.

As a Senior Product Designer and published artist on the NYT Discovery team, Raven has built a career at the intersection of creativity and strategy, crafting designs that resonate with diverse audiences. Her career spans edtech, social good agencies, streaming, and media, giving her a cross-industry depth that very few designers have and a perspective on designing for genuine daily habit that is hard to find anywhere else.

Claim Your Unveiling Discount Here

#06 · Leo Hoar, PhD

Founder · UXR Institute Panelist and Workshop Leader

Leo Hoar saw a gap in the industry. UX researchers needed advanced, career-focused education and it simply did not exist. So he built the UXR Institute to fill it.

A former academic who began his UX research career at Samsung, Leo has spent years helping start-ups find product-market fit through great research and now helps UX leaders build meaningful learning programs for their communities. His talk at UXCON26 will give you the kind of advanced, practical research education that most conferences simply do not offer.

#07 · Twisha Shah Brandenburg

Design Leader, UX Enterprise · Target Panelist

AI is already on your team. The question is whether your collaboration design has caught up.

Twisha is a design and product leader at Target whose work sits at the intersection of UX, product strategy, engineering constraints, and organizational systems, where experience quality gets decided long before anything ships. Over the last decade she has led cross-functional initiatives helping teams move beyond siloed execution toward shared understanding and coordinated decision-making. She writes the Substack Making an Impact, speaks internationally including at UXPA, and brings practical, experience-driven frameworks that cut through the noise.

#08 · Zach Thomas

Design Lead · Skylight Panelist

DHS. The U.S. Air Force. The CDC.

Zach Thomas leads cross-functional teams at Skylight modernizing mission-critical federal systems through human-centered design, the kind of work where getting it wrong has real consequences. Previously Global Product Design Lead at General Assembly and co-founder of the District Innovation Lab, collaborating with institutions including MIT and the International Monetary Fund. His work has been recognized by Fast Company and he serves as a NASA JPL Solar System Ambassador.

#9 · Basel Fakhoury

SVP · UserTesting · Co-founder, User Interviews Panelist

If you have ever recruited research participants through User Interviews, you have used something Basel Fakhoury built.

Basel co-founded User Interviews, one of the most widely-used research recruitment platforms in the industry, which was acquired by UserTesting where he now serves as SVP. He brings a founder’s perspective on what it takes to build infrastructure that makes great UX research actually possible at scale, and where the tools and the industry are heading next.

Get Your Ticket

Heads up: this is just the tip of the iceberg. Nine speakers, with more unveiling soon. Three keynotes. Two panels. Workshops. One day.

UXCON24 sold out. UXCON25 sold out. UXCON26 will too.

We are celebrating today’s speaker announcement with a special Unveiling Discount, available for the next 3 days only. This offer expires Friday at midnight.

If you have been on the fence, this is your sign. Get in the room with Don Norman, Calvin Robertson, Amanda Gelb, and ten other incredible voices in UX, all on October 8.

Claim Your Unveiling Discount Here

Here’s what’s actually happening with screen sizes in 2026, and how to design for reality instead of assumptions.

In this issue:

• The screen size distribution that surprised everyone

• Why “mobile-first” became “mobile-only” (and why that’s a problem)

• The contexts you’re not designing for

• Responsive design vs. adaptive design (and when each matters)

• How to actually test across real device usage

• 📦 Resource Corner

The screen size distribution that surprised everyone

Let’s start with data, because what designers assume about device usage and what’s actually happening are often very different.

Here’s what changed in the last few years:

📱 Tablet usage went up, not down Everyone predicted tablets would die. Instead, iPad sales hit record numbers. Android tablets made a comeback. And crucially, people started using tablets for work tasks, not just media consumption. (Source: Statcounter Global Stats)

💻 Laptop screens got smaller and touch-enabled The 13-inch MacBook became the default. Surface devices and Chromebooks blurred the line between tablet and laptop. Suddenly you have desktop browsers on small screens with touch input.

📱 Phone screens got bigger and foldable The average phone screen size is now over 6 inches. Samsung’s foldables open to tablet size. The “small mobile screen” you’re designing for might be bigger than some laptops.

🖥️ Ultra-wide monitors became common 34-inch curved monitors. Multiple displays. People running your web app at 3440x1440 resolution. Your 1440px max-width container looks tiny on these screens.

What this means: The old breakpoints don’t match reality anymore. Designing for “mobile” at 375px, “tablet” at 768px, and “desktop” at 1024px misses huge chunks of real usage.

Hold up… Join us at UXCON26

The UX landscape is shifting fast. The designers who stay ahead are the ones who invest in their craft and their community.

That’s what UXCON26 is built for.

One packed day of sessions from practitioners solving hard problems right now. Workshops that build real skills. And the kind of hallway conversations that turn strangers into collaborators.

Come ready to be challenged. Leave knowing exactly where your work is headed.

Join us at UXCON26

back to where we stopped…..

Why “mobile-first” became “mobile-only” (and why that’s a problem)

Mobile-first was supposed to mean: start with the most constrained experience, then progressively enhance for larger screens. It was about prioritization and clarity.

But somewhere along the way, it became: design for phones, then stretch it for everything else.

Here’s what that looks like in practice:

🔴 Tablet apps that are just blown-up phone interfaces Giant buttons. Huge whitespace. Single column layouts on a 12-inch screen. It works, technically. But it wastes the screen real estate and feels awkward to use.

🔴 Desktop experiences that feel like phone apps Hamburger menus on a 27-inch monitor. One column of content in the middle of a massive screen. Navigation hidden behind icons because “that’s how we do it on mobile.”

🔴 Features that only exist on one platform “Swipe to delete” only works on touch. Keyboard shortcuts only work on desktop. Hover states only work with a mouse. So features appear and disappear depending on what device you’re using.

🔴 Layouts that break when rotated Design for portrait phone. Test in portrait phone. Ship it. Then someone rotates to landscape and half the UI is cut off or the layout collapses awkwardly.

The root problem: Teams design mobile-first but test mobile-only. They assume other screen sizes will “just work” with CSS breakpoints. They don’t.

💡 Real talk: Mobile-first is still good. Mobile-only is lazy.

The contexts you’re not designing for

Screen size is just one dimension. Context matters more. And most design teams aren’t thinking about the full range of contexts their product gets used in.

Context 1: The “in-between” device → Tablets

Tablets are weird because people use them in multiple postures and contexts:

• On the couch, casually browsing (consumption mode)

• At a desk with a keyboard, working (productivity mode)

• In bed, propped up on a stand (passive mode)

• In hand, walking around a warehouse or hospital (mobile mode)

Your design needs to work in all of these. A tablet user might want desktop-level functionality but with touch-friendly targets. They might need to see more information than a phone but can’t use hover states.

What fails: Assuming tablet = scaled-up phone. Tablets have more screen space. Use it. Multi-column layouts. Side-by-side views. Toolbars that stay visible. (Source: Apple Human Interface Guidelines - iPadOS)

Context 2: The “desk-but-touch” device → Surface, Chromebook, touchscreen laptops

These devices break your assumptions about input methods. They have large screens (desktop-sized) but are often used with touch. Your hover states don’t work. Your small click targets are hard to tap. Your right-click menus are inaccessible.

What fails: Relying on mouse-specific interactions. Designing buttons smaller than 44x44px because “it’s desktop.” Putting critical actions in hover-only states.

Context 3: The “sometimes folded” device → Foldables

Samsung Z Fold, Google Pixel Fold, and others. These devices switch from phone-sized to tablet-sized mid-session. Your app needs to gracefully handle the screen size changing without losing the user’s place or breaking the layout.

What fails: Fixed layouts that don’t reflow. Modals that assume screen dimensions. Video players that don’t adapt. (Source: Samsung Developer Docs)

Context 4: The “giant desktop” → Ultra-wide and multi-monitor setups

People run your web app on 34-inch curved monitors or across multiple displays. If your max-width is 1440px, you’re wasting 70% of their screen. Everything feels small and cramped in the center.

What fails: Arbitrary max-widths without considering actual large-screen usage. Not designing for when users want to see more information at once.

Context 5: The “actual mobile” context → Moving, one-handed, distracted

This is what mobile-first was supposed to optimize for, but many “mobile” designs are tested sitting at a desk. Real mobile usage happens while walking, on the bus, holding coffee, in bright sunlight.

What fails: Small touch targets. Low contrast. Actions requiring two hands. Multi-step flows that require focus.

Responsive design vs. adaptive design (and when each matters)

Let’s clarify these terms, because they get used interchangeably but they’re different approaches.

Responsive design = fluid layouts that stretch and compress based on viewport width. Same HTML, same components, just rearranged with CSS. This is what most teams do.

Adaptive design = different layouts or even different components for different contexts. You might show a completely different navigation pattern on mobile vs desktop, or different information density.

When responsive works well:

✅ Content-heavy sites where the information hierarchy is consistent across devices (blogs, news, documentation)

✅ Simple layouts that don’t need dramatically different structures

✅ When development resources are limited and you need one codebase

When responsive fails:

❌ Complex applications where mobile and desktop have fundamentally different use cases

❌ When the same information density doesn’t work across all screen sizes

❌ When touch vs mouse input requires different interaction patterns

When you need adaptive:

✅ Productivity tools where desktop users need power features and mobile users need quick actions

✅ When different devices are used in genuinely different contexts (e.g., managers use desktop for analysis, field workers use phones for data entry)

✅ When you can justify the extra development cost for significantly better experiences

The hybrid approach that works: Responsive layout structure with adaptive components. Your grid system responds to screen size, but individual components might render differently based on input method or context.

Example: A data table is responsive in its column widths, but adaptively switches to cards on small screens because tables don’t work well in narrow viewports.

How to actually test across real device usage

This is where most teams fall short. They design in Figma at standard breakpoints, test in Chrome DevTools device mode, and call it done. That’s not enough.

Here’s what comprehensive device testing actually looks like:

1. Test on real devices, not just simulators

DevTools responsive mode is useful for quick checks, but it doesn’t show you:

• Actual performance and load times

• Touch target accuracy

• How readable text is on a real screen

• Gesture interactions (pinch to zoom, swipe, etc.)

• How bright/dark your UI is in different lighting

Get your hands on: An iPhone, an Android phone, an iPad, a cheap Android tablet, and if possible, a foldable device. You don’t need every device, but test on actual hardware regularly.

2. Test in both orientations

Portrait and landscape can have very different implications for your layout. Landscape on a phone often reveals layout issues you didn’t catch. Portrait on a tablet might show wasted space.

Build this into your workflow: Every time you test a screen, rotate the device. This takes 5 seconds and catches so many issues.

3. Test with actual input methods

Use your finger, not a mouse cursor pretending to be a finger. Try navigating with a keyboard. Try using a stylus if your users might. Try your app with a trackpad, with a mouse, with touch.

What you’ll discover: That hover state you relied on doesn’t work with touch. That drag interaction is awkward with a trackpad. That button is too small to tap accurately.

4. Test at the extremes

Don’t just test at your breakpoints. Test at the smallest screen you support and the largest. Test at weird in-between sizes like 950px or 1180px. This is where breakpoint bugs hide.

5. Test with real content, especially long content

Don’t test with “Lorem ipsum” or “Jane Smith.” Test with:

• A really long name: “Dr. María José Fernández-González”

• A really long title: “Senior Vice President of Digital Transformation and Customer Experience”

• Lots of items: 47 notifications, 200 emails, 12 tabs open

• No items: empty states with no data

What breaks: Truncation that cuts off important info. Layouts that overflow. Infinite scrolling that performs badly. Empty states nobody designed for.

6. Use accessibility tools to test at different zoom levels

Many users zoom to 200% or more. Your layout should still be usable. Text should reflow, not disappear off screen. Buttons should stay tappable.

Test this by: Zooming your browser to 200% and trying to complete core tasks. (Source: WCAG 2.1 Guidelines)

🎯 Take-home: You can’t design for screens you’ve never actually used. Budget for real devices and test on them regularly.

📦 Resource Corner

Statcounter Global Stats Live data on actual screen resolutions and device usage worldwide. Updates monthly. Use this to inform your breakpoint decisions based on real usage, not assumptions.

Responsively App Free tool that lets you preview your site on multiple device sizes simultaneously. Way better than toggling device mode in DevTools.

Apple Human Interface Guidelines Comprehensive guidance on designing for iOS, iPadOS, and macOS. Especially strong on adaptive layouts and input methods.

Google Material Design - Adaptive Design Material’s approach to responsive and adaptive layouts, including their window size class system.

Can I Use Check browser support for CSS features before relying on them for responsive layouts. Saved me many times.

BrowserStack Paid service but worth it for testing on real devices in the cloud. Good for testing devices you don’t own.

The New CSS for Responsive Design (Every Layout) Modern CSS layout primitives that make responsive design more robust. Moves beyond breakpoint-heavy approaches.

Final Thought

The phrase “mobile-first” was never meant to be “mobile-only.” It was about starting with constraints and progressively enhancing. But somewhere along the way, teams started treating other screen sizes as afterthoughts.

The reality is messier than our breakpoints suggest. People switch devices mid-task. They rotate their phones. They use tablets like laptops and laptops like tablets. They have giant monitors and tiny phones and weird foldable things in between.

Your job isn’t to design for three breakpoints. It’s to design for the contexts where your product actually gets used, on the devices people actually have, with the input methods they actually prefer.

That’s harder than slapping some media queries on a mobile design and calling it responsive. But it’s also what separates products that feel native to each context from ones that feel like they’re fighting against the device.

— The UXU Team

I figured it out the hard way. A designer on one side, a PM on the other, both convinced they were right, both working toward the same goal, somehow making each other’s lives harder every single day. — Yao A.

If you’ve been there, you know exactly what I’m talking about.

The thing is, nobody sits down and decides to make collaboration difficult. It just happens. Priorities drift. Communication gets lazy. Someone stops being included in a meeting they should have been in. Before you know it, you’re shipping things that feel off and nobody can quite explain why.

The teams that figure this out don’t have a secret. They just have better habits, better language, and usually someone who’s been through it enough times to know where things go wrong before they go wrong.

That’s exactly who is showing up on Tomorrow March 5th.

RSVP

Who’s in the Room

Ivan Carter has been designing for over 20 years.

Leo Hoar left academia to build something that would actually help UX researchers get their work taken seriously.

Tad Marsili has spent 15 years in rooms where design either shapes the strategy or gets ignored, and she knows the difference between the two.

Caitlin Cooper has led cross functional teams through the kind of complex product decisions that most people avoid talking about honestly.

Teyibo founded Analog Teams and Guardian AI and co-chairs UXCON, and he thinks about design and product collaboration at a scale most of us haven’t considered yet.

Five people. One room. One honest conversation about what it actually takes to make UX and Product work well together.

Secure your spot

This is the kind of evening where someone says the thing you’ve been thinking but never said out loud in a professional setting, and the whole room quietly exhales.

Come if you work in UX. Come if you work in Product. Come if you manage people who do either of those things and you’re tired of watching them misunderstand each other. Come if you just want to be in a room full of people who take this work seriously.

It’s FREE. It’s in Silver Spring. And it’s the kind of evening you’ll still be thinking about two weeks later.

This Thursday March 5, 6 to 9 PM EST Silver Spring Civic Building at Veterans Plaza 1 Veterans Pl, Silver Spring, MD

Secure your spot

We’ll see you there.

In this issue:

• Why “good work” isn’t enough to get interviews

• The 3 things that get your portfolio closed in 30 seconds

• What hiring managers actually look for (and how long they look)

• The portfolio structure that gets callbacks

• How to present projects when you don’t have “real” client work

• 📦 Resource Corner

Why “good work” isn’t enough to get interviews

Here’s the hard part: your design skills might actually be solid. Your screens might look great. Your prototypes might be smooth. But none of that matters if a hiring manager closes your portfolio after 30 seconds.

And that’s the reality. Most hiring managers spend less than 2 minutes on a portfolio during initial screening. Some spend 30 seconds. They’re not studying your work deeply. They’re looking for reasons to move you to the “yes” pile or the “no” pile, fast.

This isn’t because they’re lazy. It’s because they’re looking at 50+ portfolios for a single role. They need a filtering mechanism. And that mechanism isn’t “is this person talented?” It’s “can this person clearly show me they can do the job I’m hiring for?”

That’s a different question. And most portfolios don’t answer it.

Here’s what actually happens when someone opens your portfolio:

First 10 seconds: They’re scanning for visual quality and professionalism. Does this look like the work of someone who takes design seriously? This is surface-level, but it matters.

Next 20-40 seconds: They’re looking for context. What kind of projects are these? Can I quickly understand what you did? Is there a clear problem and solution?

If you make it past that: They’re reading one project more carefully to see if you think like a designer. Do you understand users? Can you articulate decisions? Do you show process or just outcomes?

Most portfolios fail at step 2. They show beautiful screens with no context, or they bury the context so deep that hiring managers give up looking for it.

Join us this Thursday in Silver Spring

Something feels off when UX and Product aren’t actually working together. You feel it in the meetings. You feel it in the product.

This Thursday we’re fixing that conversation.

Ivan Carter, Leo Hoar, Tad Marsili, Caitlin Cooper, and Teyibo are coming together to talk about what real collaboration looks like, what gets in the way, and what actually works.

Come through. It’s free, it’s in Silver Spring, and it’s worth your Thursday evening.

March 5 · 6 to 9 PM EST Silver Spring Civic Building · Silver Spring, MD

Secure your spot

The 3 things that get your portfolio closed in 30 seconds

Let’s be specific about what kills portfolios quickly. These aren’t subtle issues. They’re instant disqualifiers.

❌ 1. No clear explanation of what you actually did

“Redesigned the checkout flow for an e-commerce app” tells me nothing. Did you do user research? Did you design the whole thing solo? Were you one person on a team of five? Did you just make it look prettier or did you solve a real problem?

Hiring managers need to know what YOUR contribution was. Not the team’s. Not the company’s. Yours. When this is unclear, they assume you didn’t do much, or worse, that you’re hiding something.

The fix: Every project needs a clear “My Role” section right at the top. Be specific. “I conducted 8 user interviews, synthesized findings into 3 key pain points, designed and tested 2 solutions, and delivered final mockups to the dev team.” That’s clear. That’s hireable.

❌ 2. Only showing final designs with no process

A grid of polished screens tells me you can use Figma. It doesn’t tell me you can solve problems. And problem-solving is the job.

This is the most common portfolio mistake, especially among designers who learned UX through online courses or bootcamps. They present case studies like product showcases instead of problem-solving narratives. (Source: Nielsen Norman Group on Portfolio Research)

The fix: Show your thinking. Show research insights, wireframes, iteration, testing results. Show what you tried that didn’t work and why you changed direction. This proves you can do the messy, strategic work that happens before the pretty screens.

❌ 3. Projects that don’t match the job you’re applying for

If you’re applying for a B2B SaaS role and your portfolio is full of colorful consumer apps and personal passion projects, that’s a mismatch. Hiring managers want proof you can do their type of work, not just any work.

This doesn’t mean you need a different portfolio for every application, but it means you need range, or you need to be strategic about what you lead with.

The fix: Reorder your projects based on relevance. Put the most relevant one first. If you don’t have relevant work, create a spec project that demonstrates you understand the domain. One targeted case study is worth five generic ones.

💡 Reality check: Hiring managers aren’t trying to find reasons to reject you. They’re trying to find reasons to interview you. Make it easy for them.

What hiring managers actually look for (and how long they look)

Let’s get inside the decision-making process, because understanding this changes how you structure everything.

When a hiring manager opens your portfolio, they’re asking these questions in order:

Question 1: Does this person’s work look professional? (10 seconds) This is about visual craft and polish. Clean layouts, good typography, intentional use of color and spacing. If your portfolio itself is poorly designed, that’s an instant red flag.

Question 2: Can I quickly tell what this person does? (20 seconds) Is there a clear headline or intro that says “I’m a product designer who specializes in...” or “I’m a UX researcher focused on...”? Or do they have to hunt for it?

Question 3: Do these projects seem relevant to what I need? (30 seconds) Scanning project titles and thumbnails. Looking for keywords and visual cues that match the job. If they don’t see it quickly, they move on.

Question 4: Can this person explain their work clearly? (1-2 minutes) Reading one project summary. Looking for: problem statement, your role, what you did, what the outcome was. If this is unclear or overly long, they stop reading.

Question 5: Do they think like a designer I’d want on my team? (2-5 minutes) If they made it this far, they’re reading a full case study. They want to see: user research or user understanding, clear design rationale, iteration based on feedback, measurable or meaningful outcomes.

Most portfolios lose people at Question 3 or 4. Not because the work is bad, but because the presentation makes it too hard to find the answers.

The portfolio structure that gets callbacks

Okay, so what actually works? Here’s a structure that consistently gets positive responses from hiring managers, based on what they’ve said they look for.

1. Homepage: Make it instantly clear who you are and what you do

Not “I’m a creative problem solver passionate about user-centered design.” That’s everyone. Be specific.

✅ Good: “Product designer focused on complex B2B tools. I turn messy workflows into intuitive systems.” ✅ Good: “UX researcher specializing in early-stage discovery for fintech products.”

Then show 3-5 of your best projects with:

• A clear project title

• One sentence about what it is

• A strong visual thumbnail

2. Case study structure: Answer the hiring manager’s questions upfront

Every case study should follow this flow:

→ Project overview (top of page, can’t be missed)

• What the project was

• Your role (specific)

• Timeline

• Tools used

• Team context if relevant

→ The problem (1-2 paragraphs max) What user problem or business challenge were you solving? Be specific. Use real context. “Users were abandoning checkout at a 68% rate” is more compelling than “checkout needed improvement.”

→ Research/Discovery (show your thinking) What did you do to understand the problem? User interviews? Analytics? Competitive analysis? Show a few key insights, not everything. Use quotes, photos, data visualizations. (Source: NNG on Showing UX Work)

→ Design process (show iteration, not just finals) Sketches or wireframes. Multiple concepts you explored. Why you chose one direction over another. What changed after testing or feedback. This section proves you can think, not just execute.

→ Final solution (now show the polished work) High-fidelity designs. Prototypes. Annotated screens that explain key decisions. Make it visual, but always with context.

→ Impact (prove it mattered) Metrics if you have them: “Reduced support tickets by 34%” or “Increased conversion by 12%.” Qualitative feedback if you don’t: user quotes, stakeholder reactions, what shipped and how it’s being used.

→ Reflection (optional but powerful) What you learned. What you’d do differently. This shows self-awareness and growth mindset, which hiring managers love.

3. About page: Make yourself memorable and hireable

This is where personality matters. Don’t just list skills. Tell a story about why you do UX work, what you care about, what kind of teams you thrive in.

Include a professional photo. Link to your LinkedIn. Make it easy to contact you. Add a line about what you’re looking for: “Currently seeking a product design role at an early-stage startup where I can own projects end-to-end.”

How to present projects when you don’t have “real” client work

This is the anxiety every junior designer or career switcher faces: “My portfolio is all practice projects. Will anyone take me seriously?”

Short answer: yes, if you present them right.

What doesn’t work: Calling them “concept projects” or “passion projects” or apologizing for them. Don’t say “this is just a fake project I made up.” That kills your credibility immediately.

What does work: Treating them like real projects with real constraints. Here’s how:

→ Pick real problems to solve Don’t redesign Instagram for the 100th time. Find an actual problem in a product you use, or an underserved user group, or a local business that could use help. Make it specific and grounded.

Example: “I noticed my local library’s website had a 12-step process to reserve a book. I redesigned it based on research with 5 regular library users.” That’s real and relatable.

→ Do actual research Talk to real people. Even 5 interviews is research. Run a usability test with friends or family. Look at reviews and complaints. Treat it like a real project because the skills you’re demonstrating are real.

→ Define realistic constraints “I gave myself 2 weeks and a mobile-first constraint because most library users access the site on their phones.” Constraints show you understand how real design work happens, not in a vacuum.

→ Present it professionally Use the same case study structure you’d use for client work. Don’t apologize. Present your thinking, your process, your decisions. The fact that it’s not shipped doesn’t matter if you can prove you know how to think through design problems.

🎯 Take-home: Self-initiated projects are only a problem if you present them like you’re embarrassed by them. Present them like real work, and they become real portfolio pieces.

📦 Resource Corner

Bestfolios A curated collection of strong UX portfolios. Study what works. Notice patterns in how the best portfolios structure case studies and present thinking.

Cofolios Another excellent portfolio gallery with filtering by role type. Especially useful for seeing how people present different kinds of work.

Case Study Club A collection of well-structured case studies across different design disciplines. Great for studying narrative flow and presentation techniques.

How to Build a UX Portfolio (NN/g Article) Research-backed guidance from Nielsen Norman Group on what actually matters in UX portfolios. Based on studies of what hiring managers look for.

Lapa Ninja Landing page inspiration, but useful for portfolio homepage design. Shows effective ways to present yourself and your work at a glance.

Figma Portfolio Templates Free templates to give you a structural starting point. Don’t copy them directly, but use them to understand professional portfolio layouts.

💭 Final Thought

Your portfolio rejection isn’t personal. It’s structural.

The difference between a portfolio that gets interviews and one that doesn’t usually isn’t talent. It’s clarity. It’s making it easy for someone who’s looking at 50 portfolios in one afternoon to quickly see: this person can do the job, this person can think through problems, this person can communicate their work.

That’s it. That’s the bar.

You don’t need more projects. You don’t need more years of experience. You need to present what you already have in a way that answers the questions hiring managers are actually asking.

Fix the structure. Show your thinking. Make your role clear. Do that, and the interviews will come.

— The UXU Team