It looks the same. Why change it?
How to show the value of a change stakeholders barely notice.
You walk into a design review after a sprint spent improving a setup flow. From your perspective, the changes are significant. You’ve tested the prototype, and task success rates were much higher. You’re expecting an easy conversation and pats on the back.
Then someone looks at the before and after and says, “It looks kind of the same. I don’t really see a difference.”
And maybe they’re right. The screen barely looks different. However, can people get through it now without hesitating, backtracking, or asking for help?
Some of the most useful UX fixes are “easy to miss” because they make a product work the way people already expected.
People don’t notice the fix. They just stop struggling.
The challenge is showing the value when the stakeholders deciding what business dollars fund don’t immediately understand what changed.
What makes a fix invisible?
People bring expectations to every product they use, shaped by their mental model of how it should work. Jakob’s Law explains how experiences with other websites and digital products help form those expectations.
Familiar patterns shape what people assume a button or progress bar will do. Useful in principle, but always research to understand your specific audience’s mental models and expectations.
So what do I mean by an “invisible fix”? An invisible fix closes the gap between user expectations and their experience with your product.
Imagine your users mistake a progress indicator for a swipeable carousel. Updating the visual indicator to a continuous line is a potential solution you could test. Does it remove the misleading cue while still making progress clear?
That gap can also appear when an onboarding image doesn’t match what someone sees in front of them. The image shows the device from one angle; they’re looking at it from another. Changing the image orientation to match their view can remove that microfriction, reducing confusion and the time spent figuring out what to do.
Or consider a setup step we left out because it seemed obvious: “Of course they’ll plug the product in. We don’t need to tell them that.” But if someone misses that step, they may spend time trying to figure out why pairing isn’t working. Including it can spare them that confusion.
The difference is easier to see in how they complete the task than by simply looking at the screens before and after.
Steve Krug’s Don’t Make Me Think makes the case for reducing unnecessary mental effort. It’s easy to forget how much people already have going on around them and in their minds. Asking them to fill in missing steps adds to their cognitive load.
A confusing setup can become what they remember about your product. State the obvious. Show the device as they’ll see it. Make the next step clear.
Why a small fix can matter
When someone stops during setup and asks themselves, “Did that work?” they’re spending mental effort figuring out what happened.
They already have other things competing for their attention. If they have to keep checking, guessing, or retracing their steps, that increases their cognitive load. They may start questioning whether they understand the product or whether it works at all.
That uncertainty can compound across the setup experience. A confusing moment may be manageable; repeated confusion can leave someone frustrated enough to call support, give up, or return the product.
Watching people use the product helps you see what’s causing the confusion. After making iterative changes, you can see if more people finish setup and if fewer need help.
The value of improving the experience may show up as fewer mistakes, fewer support calls, and fewer people giving up. But justifying the time and money can be difficult when the work looks like “changing a few words” or “slightly moving an image.”
Someone may argue that users already have what they need to get through setup. However, having the information somewhere on the screen doesn’t mean people can find it, understand it, and use it without struggling.
How to show invisible changes are worth the $$$
To help stakeholders see why the work matters, start with what people experienced.
Show what confused them, what you changed, and whether that helped. Then connect those findings to the business decisions stakeholders need to make.
Show where people struggled.
Show a recording of someone getting stuck: trying to swipe the progress bar, rereading an instruction, or looking for a step we left out. Watching that struggle can help someone understand the frustration behind a change that looks small on screen.
“We redesigned the progress bar” describes the work. “People mistook it for a carousel and tried to swipe it, so we removed that cue” explains what confused them and why you changed it.
Give the recording some context, too. Did other participants have the same problem? Your case shouldn’t draw conclusions from a single experience.
Show what improved.
Then show people attempting the same task with the revised design. Can more people finish setup without help? Do they make fewer mistakes? Does successful setup take less time?
Get Jocelyn Wright Powell’s stories in your inbox
Join Medium for free to get updates from this writer.
Explain what improved and what still caused confusion. Look at completion time alongside mistakes and unfinished attempts; getting through a task faster doesn’t mean much if more people get it wrong or give up.
Be clear about what the testing supports. Seeing people complete a revised task can help you explain the change. It doesn’t yet tell you whether support calls or returns will drop.
Connect that improvement to the business.
If people can’t get through setup, they may need help, leave the product unused, or return it. Those are reasons for stakeholders to care about an instruction or image that seemed too small to spend time on.
Connect the problem you observed to the business information you have. If support records show customers calling about that same step, bring that into the conversation. If you haven’t measured the effect on support calls or returns, describe it as an expected benefit to check after launch.
That gives stakeholders a clearer basis for deciding whether to fund the work: what people struggled with, what improved in testing, and what you still need to learn.
Invisible doesn’t mean there’s nothing you can see
Someone using the product for the first time won’t know you rewrote an instruction. What matters to them is having clear instructions so they know what to do without having to question each step.
Dan Saffer talks about this in “The Myth of Invisible Design.” Good design doesn’t always have to go unnoticed.
If someone is pairing a device, how do they know it’s ready? Once they start, can they tell whether it’s still connecting or something went wrong?
Don’t leave your users guessing. Show which button to press. Tell them when the connection worked, or what to do if it didn’t.
Sometimes that means adding an image or a few words. If that information helps someone complete the task, it should be there.
The challenge is how to present it visually so it’s easy to find and understand. Adding information and improving clarity aren’t mutually exclusive.
Validation shouldn’t stop with prototype testing
A prototype can help confirm whether people understand the instructions and know what to do next.
Before the design review, test with people who would use your product and give them a task without walking them through it. For example, ask them to connect a new device to the app. Watch whether they plug it in, recognize when it’s ready to pair, and know what to do next.
If you’re comparing first-time setup, use different participants for the current and revised designs. Someone who tries both may do better the second time because they’ve already learned the steps. If participants do try both versions, vary the order and account for what they’ve learned when interpreting the results.
A small study can reveal problems. A claim about how much success rates improved needs enough participants and a suitable statistical comparison. Plan the test around the question you need it to answer.
Then test setup with the actual product. When people use it in their own homes, they’re dealing with the space, interruptions, and conditions around them. Your prototype may not account for all of that.
After launch, check whether people are still getting stuck and whether setup-related support calls have changed. Compare equally long periods and account for how many people started setup in each one. Fewer calls could simply mean fewer users. Look at other changes in the release, too, before attributing the result to your design.
If possible, randomly give some users the current flow and others the updated one so you can compare the results. If you can’t make that comparison, be clear about what you know and what you think the design contributed.
Keep the review focused on the user’s experience
If someone says we’re “just changing a few words,” we need to explain what those words help the user do.
Maybe they explain a step we assumed was obvious. Maybe changing an image means someone no longer has to turn the device around to understand the instructions. Those are reasons to do the work, even when the screens look almost identical.
People want to start using their product ASAP. If our changes help them do that with less confusion and less effort, that’s the improvement we need to show the stakeholders deciding whether to fund the work.
Recommended reads and sourced materials:
- End of Web Design
- 10 Usability Heuristics for User Interface Design
- Don’t Make Me Think
- Quantitative vs. Qualitative Usability Testing
- Between-Subjects vs. Within-Subjects Study Design
- A Dirty Dozen: Twelve Common Metric Interpretation Pitfalls in Online Controlled Experiments
- The Myth of Invisible Design
