UI/UX Rework Pain: What It Looks Like From the Field

I read Ragate’s survey report on UI/UX rework.
The later half is basically promotion, so I will leave that aside, but the survey results in the first half were interesting enough that I wanted to write down what came to mind from a real-world perspective.

Key Findings

• About 50% of projects experienced rework due to gaps between design and implementation
• One in four companies said it happens “almost every time” or “more than half the time”
• PowerPoint / Keynote was the top design tool at 32.4%
• 21.8% are already using vibe coding
• About half have adopted or are considering vibe coding

The Reality of Design Tools

It is a little surprising that PowerPoint / Keynote is on top, but it makes sense when I compare it with my own experience.

• Large enterprises: They send PowerPoint or PDF. The format has to be something anyone can open so the approval flow can run
• Mid-sized / creative companies: Start from wireframes and make mocks in AI / PSD. Designers use the tools they are comfortable with
• Figma: Only a very small number

Figma markets itself around “working with engineers,” but that only matters if the client can actually use Figma. In outsourcing, you have to use a tool the client can handle, so you end up back at PowerPoint or PSD.

Personally, I liked XD more, or maybe XD was also terrible, or maybe just use Illustrator. Every time a new tool appears, people say “let’s standardize on this,” and then everyone goes back to what they already know.

Vibe Coding Is Invisible

The survey says 21.8% are using it, but I have not seen it in my own environment. Or rather, I am the only one using it.

That may just be because I am the one doing the main writing. If nobody else is owning the part being written, it is hard to tell whether AI was involved.

Code is code in the end, so from the outside you cannot really tell whether AI wrote it. There is no culture of self-reporting “I used AI,” and it is not recorded in commit logs either.

The real adoption rate of vibe coding probably has an invisible undercount even within teams.

Two Types of Rework

Rework generally falls into two patterns.

Pattern A: Recreating the designer’s mental image in implementation is hard

“This subtle shadow falloff” or “this smooth hover motion.” It does not come across in a still image, and if you try to recreate it in CSS, the effort explodes. You usually end up choosing between “export it as an image” or “compromise.”

Pattern B: The client’s ‘It feels wrong somehow’

This one is the hardest. You followed the instructions, passed review, and kept polishing it, only to hear “it is not the image I had in mind.” Either the original image was never verbalized, or their mental picture changed midstream.

Both problems ultimately come down to the same thing: the final shape was never shared.

My Unease with the Full-Stack Narrative

Lately I often hear that “you need to be able to do both frontend and backend,” and while being able to do both is great, I think work generally moves better when the tasks are split.

I am not that good at HTML coding myself, so I usually hand it off to someone else. But no matter who does it, rework still happens.

The benefits of splitting work:

• Parallel work is possible, which shortens the schedule
• People do what they are good at, which stabilizes quality
• Review actually works

Also, from experience:

• Backend people: tend to prioritize “working” and produce something with weak visual design
• Frontend people: tend to prioritize design and produce something that is dangerous from a system architecture standpoint

This is not solved by “being full-stack and doing both.” It is about which thinking mode you prioritize.

“Full-stack for mutual understanding” makes sense. It helps you understand the other side’s constraints, which makes the conversation work. But “you, do everything as full-stack alone” breaks down. It is just a way to save labor costs, and quality on one side inevitably suffers.

Teams That Know What They Cannot Do

The ideal team is one made up of people who know what they cannot do.

• Coder: “That design will be a pain to implement”
• Designer: “Okay, we can cut that”
• Server-side dev: “Isn’t this API design going to be rough on the frontend?”
• Backend: “Okay, I will return it like this then”

What matters is whether that conversation can happen. Understanding the other person’s limits is more valuable than being able to do everything yourself.

At least the team’s intent can stay aligned. The client is another matter.

Where AI Fits

My conclusion is that the practical use cases for AI are:

• Code generation: Not万能, rework still remains
• Verbalizing and translating thought: This might be more effective

For example, you could throw your thoughts at AI every time and have it translate them into something reasonable, then store that in Slack or somewhere similar. Turning tacit, person-specific knowledge into explicit team knowledge might be the better use.

Even if vibe coding lets you build something end-to-end, design rework does not disappear.
At the moment, no matter how good your specs, docs, or references are, you do not get something usable on the first try. The larger the project, the worse that gets.

So you still need people involved, and amateurs cannot handle it. You still need people who know the domain.

AI is an aid. Humans still decide what should be made and what is problematic. That has not changed.

---

There is also a famous illustration that satirizes how requirements get mangled through “telephone game” communication.
Search for “Tree Swing Cartoon” and you will find it. The same problem has been repeating for decades.