Why Good UX Is So Hard to Find

Think about the digital tools you cannot avoid — intranets, government portals, password resets, project management software. How many of those interactions have drained your energy in the last few days? As our reliance on digital connections grows across work, health care, education, and daily transactions, experts increasingly describe a move toward a “tele-everything world.” That shift places a heavy responsibility on the people building those tools: their products must simplify life, not complicate it.

As a UX designer and design manager, I have seen the operational and cultural forces that produce bad UX. The common assumption is that bad UX stems from individual designers or developers — but hiring the most competitive talent will not fix the problem if the root causes lie elsewhere. Based on my practice, here are the four underlying reasons tech products end up with bad UX.

1. Dev Teams Outnumbered by Company Goals

When development teams are under-resourced relative to the size of a company’s ambitions, they operate in a sort of starvation mode. Delivering anything on time becomes the only priority, and the deliberate steps quality UX requires are nearly impossible to schedule. Leadership often treats good UX as a luxury or as a drag on velocity — a view that ignores how badly UX failures can damage velocity over the long run.

“I encounter under-resourced dev teams constantly, and it’s disheartening every time. Usually, quality is the first thing to go, even though most professionals know it should be scope. Decision-makers in these contexts have a very hard time imagining scoping down, so they consistently push the team to move faster instead.”

— Aidan Gordon, Technology Lead

2. Design Teams Outnumbered by Developers

A Nielsen Norman Group survey of 377 professionals found that about a third of designers are outnumbered by at least 10 developers. At ratios like that, designers are forced to rush out screens for developers to work on each week, and the team’s output is measured by its development speed alone. With such a bottleneck, developers improvise the UX on their own, and user testing gets pushed aside entirely.

3. Agile Mistaken for “As Fast As Possible”

Agile methods became mainstream without much attention to the rituals that make them work. Atlassian, creator of Jira and Confluence, defines Agile as a call for “collaborative cross-functional teams, open communication, collaboration, adaptation, and trust amongst team members.” Those requirements are exactly what gets dropped first when teams feel pressured to ship quickly. Agile depends on iterative back-and-forth across the product team — a collaborative mode that disappears when deadlines take over.

“I’ve observed companies that aren’t committed to an iterative mindset and process, but use ‘Agile’ as a bandaid for quicker releases. Sometimes, there’s a fear coming from leadership that we might never return to fix something, or a fear that we won’t be able to sell version 1 without a fully functional feature X. Unless the whole company embraces iterations, the product team will either struggle to release quickly, or to release quality… the concern is if we release a v1 with less than perfect scope we will never go back to fixing it.”

— Jill Hesse, Director at Genomics Data Management

4. Misreading the Meaning of UX

In my experience, the simplest explanation for persistent UX problems is genuine confusion — across both tech and business teams — about what user experience actually is. When leadership misunderstands UX, design resourcing suffers. When the product team misunderstands it, UX is dismissed as mere UI, “something that can be added later.” Misunderstanding the purpose of UX is the same as misunderstanding its value, and the consequences ripple through everything a team ships.

If you lead a tech organization, the link is essential: team happiness, user experience quality, and revenue are connected. Your product team can tell you exactly what conditions they need to produce great UX — and the answers are often simpler than you think.

The Toll Bad UX Takes on the People Who Build Products

The familiar workplace principle holds that happier employees do better work. I would add users into that equation: excellent experiences create a virtuous cycle back into revenue and reinforce the meaning we feel in contributing positively to others. On the flip side, when bad UX lingers in a product for a long time, it can feel like a mountain to overcome — and it grinds down the talented people working on it.

Here is how that plays out in practice:

  • Long-term UX bugs wear down morale.
    The longer glaring UX issues sit unresolved, the more a redesign becomes necessary yet increasingly harder to resource. Designers end up shipping band-aid features rather than elegant solutions. Teams still create innovative work, but at the cost of extra mental and emotional effort — and it gets harder and harder to remain proud of the output.
  • Lost opportunities for good UX diminish confidence.
    For designers, the quality of the work affects more than the product — it touches credibility, portfolio, and even self-worth. When a designer knows they are capable of producing excellent results but is stuck in a bad UX environment, the joy and creativity of the craft begin to fade.
“As a designer, working in a user-driven product culture is so important for your own satisfaction. If you’re working within a company or team with a weak UX culture, you can get stuck meeting one or a few people’s biased preferences instead of hundreds or thousands of users’ real needs. You know you’re letting users down. In some cases, you’re even adding *more* friction and frustration into someone’s life… Over time, your confidence in the quality of your designs diminishes, and, eventually, so does your overall engagement at work.”

— Erica Gregor, Head of Design & Product at Penrose Partners
  • Bad UX stalls a team’s growth.
    Persistent UX problems lead to time lost and motivation depleted until under-delivery becomes routine. Viewed from the outside, the team starts to look like it lacks relevance or competence. When it becomes difficult to demonstrate strategic and business value, the investment in growing the team slows — and with it, access to new skills and diverse talent.

These patterns illustrate what is at stake. The causes of bad UX are not usually a single failure but a set of structural conditions — resourcing gaps, misunderstood workflows, or a missing appreciation for what user experience requires. None of those conditions are trapped behind budget constraints alone. The common thread across all of them is the need for an integrated product workflow where design, development, and leadership all understand their shared accountability for the user experience.

Why More Resources Are Not The Answer

When product teams discuss why they ship with bad user experience, the conversation inevitably turns to time and budget constraints. But some of the best-funded teams in the industry also produce frustrating interfaces. Anyone who has attempted to join a Microsoft Teams call as a free user has likely encountered a login loop that makes no logical sense. Resources alone do not solve UX problems, and framing good UX as something only well-funded projects can afford does a disservice to smaller teams.

“I am not sure if I have got stuck in Groundhog Day, or have become the center of the universe. I try to log in… It says I am not on Teams yet, and asks me to ‘Sign up.’ I am taken to the Teams home page, where I click on ‘Sign up for free.’ It says, I already have an account setup... So I click on ‘Sign in.’ Now it asks me to open the app... And then it says that I am not on Teams…”

— Sumit Anantwar, on being stuck in a login loop on Microsoft Teams
The Microsoft Teams login loop

The belief that good UX is a luxury reserved for large budgets leads smaller companies to accept sub-par experiences as unavoidable. This creates a culture of complacency around design quality. In reality, smaller teams have an agility advantage they can exploit against larger competitors. The deciding factor is how a team structures its culture and workflow around user experience, not how many people it can assign to the problem.

Regardless of team size or maturity, several working practices can improve UX quality without requiring dramatic changes to how much time is spent working.

Spread UX Ownership Beyond Designers

A common industry assumption holds that designers alone should advocate for users, validate use cases, and catch edge cases. As products grow in technical and interactional complexity, this division of responsibility becomes less practical. Non-designers are often more capable of contributing to UX quality than they are given credit for.

Shared responsibility does not mean turning developers into designers or expecting equal effort across roles. It means everyone on the team acknowledges they are responsible for the overall user experience and takes steps to improve it through intentional workflow changes.

Rethink Team Workflows Around UX

Standard workflows in the industry are often adopted more out of tradition than proven effectiveness. A multi-million-dollar company publishing its polished process does not mean that process will work for your team. Some collaborative practices have demonstrated real results:

  • Early and creative collaboration between designers and developers.
    Open conversations before implementation begins reveal potential limitations in backend or frontend logic that would otherwise surface as project-defining surprises later.
  • Map out complexity in a collaborative way.
    Documenting edge cases, user flows, sitemaps, and system logic through drawings together as a group is an efficient way to think through conditional logic and align the vision. Speaking about complicated concepts with drawings saves time compared to verbal descriptions alone.
  • Make research findings accessible to all team members.
    Developers often show genuine enthusiasm for user feedback but rarely have direct access to it. Inviting developers to take notes during interviews and asking for their input on user insights regularly creates a deeper connection to UX than simply reading reports.
  • Set a standard for what good quality means together.
    Code should not ship until it meets functional and non-functional requirements important to QA specialists, developers, designers, and product owners alike. A shared definition of quality ensures everyone agrees on what acceptable and great UX looks like.

Challenge Role Assumptions

Most teams organize around the same identities: management, research, design, development, and QA. Designers on one team generally have the same responsibilities as designers on another. These role definitions emerged through years of industry standardization, yet they have not produced widespread good UX. Giving team members permission to contribute beyond their job descriptions can uncover unexpected strengths.

When developers gravitate toward learning basic UX principles, they become capable of contributing to the project's overall quality. Similarly, designers often discover a need to understand technical concepts. Welcoming overlap between disciplines strengthens the team's connection and introduces more avenues for identifying problems early.

Collaboration In Practice

Fintech: Complexity Mapping Reveals Data Model Issues

While mapping out the main flows for a fintech application with an intensive application process, the crew discovered a fundamental problem with the data model. During collaborative planning, the tech lead examined the data and found that more than fifty percent of applications included more than one person. The design assumed a single-person application, but the data showed otherwise. The team pivoted to build the foundational backend work to support multiple people per application, giving the majority of users a smooth experience.

A screenshot of a fintech app
(Large preview)

Enterprise: Early Feedback Identifies A Dealbreaking Barrier

A redesign project for an enterprise command-line tool involved uploading and downloading XML files. The tool's primary weakness was a lack of guidance and feedback during use. When the team shared wireframes with new error messages and guidance, developers revealed that the tool could not parse errors in the right order due to how the XML file interacted with the underlying database. This fundamental constraint meant the redesign's main goal was impossible within the project's scope. The team decided to abandon the project until the underlying issue could be properly fixed.

A screenshot of redesigning an enterprise product
A sneak peek of one of the drafts created when redesigning an enterprise product. (Large preview)

Biotech: Developer Review Prevents Scope Creep

Designing a custom field configuration interaction for a biotech platform involved creating number fields, text fields, radio button dropdowns, toggles, and more. Two developers reviewed the design team's wireframes and logic early, pointing out additional requirements buried in the code. Scientific software needed specifications like decimal precision and maximum allowed values to be defined upfront. This early intervention prevented both significant scope creep during implementation and blocked users during migration.

A picture of some notes for designing a custom field configuration interaction
Notes taken when designing a custom field configuration interaction. (Large preview)

None of these outcomes resulted from adding more designers or throwing more time at the problem. Each came from intentionally rethinking who participates in UX decisions and when collaboration happens.

Making UX a Shared Responsibility

When deadlines are tight and complexity is discovered late, teams end up patching awkward UX workarounds just to ship. That pattern usually signals a deeper issue: design is treated as a phase rather than a shared discipline. Fixing it requires more than a new process — it requires aligning everyone around the same definition of quality.

Here is a practical recap of steps that can improve the UX culture on your team, depending on your role.

For Product Leaders

  • Ask the hard question. Open a discussion with your team: What needs to be true in order to deliver higher quality user experiences? The answers should reveal friction points in team structure and workflows.
  • Invest in shared UX education. Offer the whole team — developers, researchers, managers, and quality analysts — a learning experience about UX, such as this introductory course. Celebrate completion by designing and implementing a new feature together.
  • Do the same for Agile. Get everyone aligned on methodology through a common learning experience, like this book, and immediately put it into practice on a shared project.
  • Introduce quick, inclusive rituals. Gather the whole team during the design process, especially in its early and messier stages. Developers, managers, and QA may feel out of place at first, but exposure will shift their sense of responsibility for good user experiences.

For Product Team Members

  • As a designer: Invite a developer to a 30-minute meeting showing them a feature you’re conceptualizing or fresh research insights you’re working with.
  • As any team member: Host a discussion about how you might deliver higher quality design without needing new resources. Test your ideas and share the learnings with your manager.
  • As a developer: Pick up some tactical UX/UI basics, and apply those principles the next time you work on a feature. Share the most seamless pieces you implemented with your team.

When all levels of a company and all members of a product team work with the same definition and values around UX, collaboration flows organically. That constant meeting of perspectives is the way forward if we want technology to genuinely help people save time and effort.

Resources & Further Reading