Enterprise UX Design Would Be Fine If Enterprises Weren't Allergic to Decisions

Got a call two months ago. Enterprise software company, 650 employees, been around 12 years, profitable.

"We need to improve the UX of our internal platform. Our teams keep complaining it's hard to use. Can you help?"

Sure. I've done enterprise UX work before. Asked the obvious question.

Me: "Who makes product decisions for this platform?"

Them: "We have a Product Steering Committee."

Already a bad sign, but okay.

Me: "How many people?"

Them: "Fourteen. One from each department that uses it."

Me: "And when you need to change something, how does that work?"

Them: "The committee meets every two weeks. We try to reach consensus. If we can't, we escalate to the VP of Operations."

Me: "How often do you reach consensus?"

Long pause.

Them: "Not often."

Me: "And escalation takes...?"

Them: "Three to six weeks. Sometimes longer if it touches multiple departments. Which, you know, most things do."

I didn't take the project. Not because enterprise UX design is impossible – it's not. But because they didn't need a designer. They needed someone to fire 13 people from that committee.

Enterprise software UX is usually terrible. We all know this. We've all suffered through it.

But it's not because enterprises can't afford good designers. They have money. It's not lack of talent – plenty of great designers would work on enterprise products. It's not even technical constraints, though everyone loves blaming "legacy systems."

It's that enterprises have accidentally built organizational structures where making a decision is physically impossible.

Not hard. Not slow. Impossible.

When 14 people need to agree before you can change a button label, that button label is never changing. When every tiny UX improvement needs Security + Compliance + Legal + IT Operations + three VPs to sign off, nothing improves. Ever.

The design work would be fine. The designers are competent. But you can't design your way out of an organization that's structurally incapable of picking a direction.

And somehow everyone agrees to blame "bad UX" instead of looking at the 14-person committee that's been meeting biweekly for 18 months and hasn't shipped a single change.

Let me show you what actually happens when an enterprise decides to fix their UX.

This is composite but I've watched variations of this exact sequence at four different companies:

Months 1-3: Employees complain about the internal tools at an all-hands. VP of Operations forms a "UX Improvement Task Force." Task Force meets. Everyone agrees UX is bad. Task Force creates a 40-slide deck titled "Internal Platform UX Assessment." No decisions made, but now there's a deck.

Months 4-6: Task Force decides to "gather data" on what users actually want. Survey goes out to 300 people. 47 respond. Insights: "make it easier to use" and "it's confusing." Task Force reviews six possible approaches to fixing this. Can't pick one. "Let's do focus groups."

Months 7-9: Legal spends three weeks reviewing focus group consent forms. Focus groups happen. Users say the same things as the survey. Task Force discusses findings for six weeks. Still can't agree on priorities. Escalate to VP for decision. VP says "let's form a smaller working group to create recommendations."

Months 10-12: Working Group of 8 people (down from 14!) creates three UX improvement proposals. Presents them to the original Task Force. Task Force can't decide between them. Escalate to VP again.

One year in. Zero UX changes shipped.

Months 13-18: VP finally picks "Option B." Procurement begins process to hire a design vendor. Reviews three vendors over two months. Can't pick one. "Let's do paid pilots with each." Legal reviews pilot contracts for four weeks.

18 months in. Finally contracting someone to do actual design work.

Months 19-24: Vendors create designs. Working Group picks one. Task Force reviews it. Requests changes. Designer implements. Security review flags six concerns. Designer addresses them. Compliance review requires changes that directly conflict with what Security wanted. Designer tries to satisfy both. Can't.

Months 25-27: Escalate Security vs Compliance conflict to VP. VP forms sub-committee to resolve it. Sub-committee meets for six weeks. Recommends a compromise that makes the design worse than the original. IT Operations reviews the compromised design, says "this breaks our deployment pipeline, needs complete rearchitecting."

Two years. Nothing shipped. The original UX problem is worse because frustrated employees built 14 different workarounds in Google Sheets and half the team doesn't even use the platform anymore.

Month 28: New VP of Operations starts. Reviews progress. "Let's table this and revisit our strategy." Forms a strategy review committee.

Project dies. Everyone agrees "the design vendor didn't deliver."

The vendor delivered in week 8. Everything after that was organizational paralysis with PowerPoint.

Nobody wants to be the person who made the wrong call

If one person approves a UX change and it causes problems, that person gets blamed. Career consequences. Performance reviews. The works.

But if 14 people approved it together? Blame gets distributed so thin it evaporates. Nobody's individually responsible. It was a "collective decision."

So instead of one person with authority making decisions (some good, some bad, all of them actual decisions), you get 14 people protecting themselves by never deciding anything.

The result: designs that satisfy 14 different political agendas but help zero users. Because compromise between 14 viewpoints doesn't produce good UX. It produces the least offensive option to the most people.

That's not design. That's conflict avoidance with Figma files.

"Being thorough" means never shipping

Nobody says "we're stalling because we're scared." They say "we want to be thorough and consider all perspectives."

Which sounds reasonable! Thoroughness is good, right?

Except thorough would be: research for 6 weeks, design for 4 weeks, approval in 2 weeks, ship in 3 months total.

What actually happens: research for 4 months (because scheduling 14 people), design for 3 months (because each person wants revisions), approval for 9+ months (because everyone can raise "concerns" that halt everything). Nothing ships.

There's always one more stakeholder to consult. One more edge case to consider. One more approval layer that definitely needs to weigh in. "Thorough" becomes infinite. And infinite thoroughness is indistinguishable from paralysis.

The process becomes the point

At some point – usually around month 8 – the committee stops trying to improve UX. Now it's trying to keep the committee running.

Meetings still happen every two weeks. Agendas get created. Minutes get distributed. Status updates get written. Slide decks get refined. From the outside, it looks like progress is happening! Everyone's busy!

But nothing changes for actual users. The platform is still bad. And when someone asks "why hasn't this improved," the answer is always "we're working on it" – which is technically true. The process is active.

Just not producing anything.

It's like redesigning to avoid admitting your pricing is broken – you're doing activity that looks like solving the problem while carefully avoiding actually solving it.

Let's say you pay 14 people an average of $110K/year. That committee meets every two weeks for 90 minutes.

Per meeting cost: (14 people × $110K ÷ 2,080 hours) × 1.5 hours = ~$1,100 per meeting
Annual cost: $1,100 × 26 meetings = $28,600 just for the meetings
Plus prep time: Each person spends 30 minutes prepping = $14,300 more
Total annual cost of the committee: $42,900

That's $42,900 spent making no decisions.

Compare that to hiring a designer for $95K who could actually ship improvements – if given the authority to make decisions.

But that would mean one person being accountable. Which feels scarier than spending $43K on a committee that produces PowerPoints and occasional "action items" that never get actioned.

I stopped taking enterprise UX projects where the approval structure has more than 3 layers.

Same way I learned that companies who need 17 stakeholders to agree can't ship anything interesting. Same way I figured out that hiring "freelance" often means avoiding commitment.

Now when enterprise companies call about UX work, I ask different questions:

Who has final decision authority?

Not "who's involved in decisions." Who can actually say "we're doing this" and it happens?

If the answer involves the word "committee" or "consensus" or "escalation," that's not decision authority. That's decision theater.

Real answer sounds like: "Sarah, the Head of Internal Tools. She reviews, approves, and we ship."

Fake answer sounds like: "Well, it goes through Product, then Engineering, then Security and Compliance review, and if there are no concerns it moves forward."

What's the longest a decision has taken?

"How long does a typical approval take?" gets PR answers. "What's the longest?" gets truth.

If they say "Oh, we had one that took 8 months" – that's your real timeline. Not the "usually 2-3 weeks" they claim. The outlier is the norm, they've just normalized it.

Who can say no?

Wrong answer: "Well, anyone can raise concerns that we need to address."

Translation: Everyone has veto power. One person's "concern" stops everything until resolved. Which means nothing gets resolved because someone always has concerns.

Right answer: "Security can say no for genuine security risks. Otherwise, the Product Lead makes the call."

How many UX improvements shipped last year?

If they can't name a number: They don't actually ship UX improvements. They talk about shipping them.

If they say "well, we made several small updates": Small updates don't count. If it's not significant enough to remember, it's not significant enough to matter.

If they name a specific number: "We shipped 7 improvements across 3 areas." That's real. Now ask how long each took from idea to production. If the average is over 4 months, you're back in decision paralysis territory.

Enterprise UX design work can be fine. The problems are interesting. The scale is significant. When improvements ship, they help thousands of people.

But you can't do good enterprise software UX design in an organization allergic to decisions.

If you're an enterprise searching for UX help: I'm not saying don't hire designers. I'm saying fix your decision-making structure first. Give someone authority. Reduce approval layers. Create consequences for committees that meet for 18 months without shipping anything.

Then hire designers. They'll actually be able to help.

But if your plan is to hire a designer, subject them to your 14-person consensus-driven approval process, and expect good UX to emerge – it won't. You'll waste their time, waste your money, and in two years wonder why enterprise UX is still bad.

The UX is bad because decisions are impossible. Not because designers aren't trying.

Fix the organization. Then fix the UX. In that order.

Otherwise, you're just hiring designers to attend meetings where nothing gets decided. Which we can do. We're good at meetings. But that's not UX design work. That's very expensive note-taking.

(And in 18 months when nothing has improved, you'll blame the designer for not navigating your org structure better. Ask me how I know.)