Balsamiq newsletter #94

The real cost of rework

Rework starts earlier than you think. Here’s how to catch it.

February, 2025

4 min read

Ciao friends,

Launch day is getting closer. The team’s pumped. You breathe a sigh of relief. It’s almost out there, just some internal reviews left.

Then the Slack message comes in: “Hey… this isn’t what we wanted.”

Here we go again. More fixes. More meetings. More Slacks with questions that should have been answered weeks ago. Rework is happening. Again. And if you’re like most teams, you chalk it up as an unavoidable part of building products.

But is it?

The real cost of rework

Rework isn’t just annoying, it’s expensive. It slows launches, drains energy, and chips away at trust.

We hear this from teams all the time: "Our engineers keep redoing work. The specs made sense when we wrote them, but the final product isn’t what we expected." Sound familiar?

That’s because rework isn’t a mistake—it’s a symptom. A sign that somewhere along the way, clarity slipped through the cracks.

It’s proof that a decision wasn’t really made. Proof that assumptions took the place of clear agreements. Proof that alignment didn’t happen until it was too late and fixing was the only option left.

We’ve learned (sometimes the hard way) that when something keeps getting reworked, it’s not about the execution. It’s about the decision-making that led to it.

One startup leader put it this way: “The specific moment we realized our engineer-led process wasn't working was when some of our engineers complained that they had to redo things. Their eyes are perfectly fine, but the results weren't necessarily what the business development team was expecting."

Why does this keep happening?

You thought you agreed. You didn’t. The team nodded along in meetings. No one actually asked, “What do you mean by that?”
You assumed alignment. A decision gets made, but everyone walks away with a slightly different interpretation of what was actually agreed upon.
You deferred decisions. “We’ll figure it out later” means you’ll figure it out when it’s most expensive.
You left gaps, and someone had to fill them. If you don’t define it, a developer, designer, or PM will. And they’ll all do it differently.

Then suddenly, the dev team is asking questions. The PM is clarifying things in Slack. And before you know it, you’re back to fixing something you thought was settled weeks ago.

From a PM: “The developer has tons of questions; the user story just isn't enough. So they have to keep getting that person on the phone. It’s like we have two people working on it instead of one.”

The fix: wireframe for decisions, not just screens

Wireframing isn’t just about documenting ideas. It’s about forcing clarity before mistakes happen. Before code is written, wireframes should put your ideas in the hot seat:

What happens if the user does X?
Where does this actually live?
Are we solving the right problem?

At Balsamiq, we use wireframes to stress-test potential solutions early, uncovering blind spots before they become expensive problems. It’s even built into our product process:

After research and discovery, Design (which could be a designer, engineer, or PM here) wireframes a number of possible solutions.
They share them in that project’s Slack channel for feedback from the project team. The team will ask questions, challenge ideas, and help Design iterate through comments, Slack threads, and team meetings. Usually the project team’s cross-functional too, so we’re getting a wide variety of perspectives.
The project team will debate, settle on a solution that addresses their goal, and dive into more in-depth design phases.

A key step in our product process: exploratory solution design

Your turn

Rework isn’t the enemy. It’s the receipt for decisions you didn’t make. Here’s a small but powerful way to catch misalignment before it leads to rework: run a ‘Red Team' review.

Before build, pick someone who wasn’t deeply involved in initial discussions to play the skeptic. They might ask, “Where could this break? What are we assuming? What’s confusing at first glance?” It’s their job to poke holes, and a great way to make sure you’re working towards clarity.

Anyway, that’s our message for the month. Iterating in a wireframe is normal—it’s where you should be reworking. But reworking in code? That’s expensive and most of us need to keep it to a minimum.

If this resonated with you today, I’d love to hear from you: What’s one decision your team assumed was clear, but wasn’t?

Until next month,

Arielle for the Balsamiq Team

What's new at Balsamiq?

We gave Balsamiq a fresh new look! Our UI and website got a full refresh: cleaner, clearer, and more modern, while still keeping the simplicity and speed you love.

We’d love to hear what you think! Learn more in this month’s release notes and the story behind it.

Happy customer of the month

Balsamiq is such a great tool to brainstorm and collaborate on for UX/UI work. It's quickly useful, quirky, fun to use, reminds me of old school Google tools. — Baris

Editor's picks

Liked this newsletter?

If this newsletter made you think, please share it with a friend or colleague who might find it useful. The best ideas spread through great conversations!

If someone sent this your way, make sure you get the next one. Subscribe here.

View in browser | Update your preferences | Unsubscribe

Balsamiq - Why are we still fixing this?

The real cost of rework

The real cost of rework

Why does this keep happening?

The fix: wireframe for decisions, not just screens

Your turn

What's new at Balsamiq?

Happy customer of the month

Editor's picks

Liked this newsletter?

Older messages

Planning mode

Your UI is costing you—here’s how to fix it

How Radical Candor transformed our team in 4 months

How we’re planning Q4 at Balsamiq—feel free to copy

Why we rebuilt Balsamiq Templates

You Might Also Like

#495: Accessibility and Inclusive UX

AD Editors Share Their Favorite March Issue Moments

🐺 Did you know about this?

🐺 If you want press for your products.

How to Land a Celebrity Client

How to build an agent

Self-disruption

Accessibility Weekly #437: Another Web Access Overlay Company Sued

🐺 What you missed...

Ross Cassidy’s Insider’s Take on Round Top