When a redesign makes familiar work slower
On YouTube mobile, Subscriptions sat in the bottom navigation, and I didn't even need to look for it because my thumb already knew where it was.
Recently, YouTube moved it to the top of Home as a tab.
It's a tiny change and nothing is actually broken and I can still get to the same videos, but something I used without thinking now makes me stop and look for it. And it's not only that the button moved because Subscriptions used to be one of the main places in the app. YouTube has turned it from a primary destination into a way of filtering Home.
Products need to change, and I am not saying every button has to stay in the same place forever. But this is the sort of cost a redesign can completely miss because, on paper, the new version still works.
What made the old version feel so fast was knowing the product well enough to stop thinking about every step, and a redesign can take that away without actually breaking anything.
Passing the test can still make regular users slower
Atlassian ran into a much bigger version of this with Jira.
In 2025, it moved the Status control on Jira's work-item screen. The reason made sense: make an important action easier to find and clean up the screen. Early experiments showed positive results, giving the team enough confidence to roll the change out.
Then it met the people who use Jira all day.
Customers reported more scrolling, more difficulty finding Status and slower workflows, especially in larger organisations and on more complex work items. Atlassian admitted what it got wrong, reverted the change, and published a post-incident review.
There was no downtime, everything loaded, and the control was still there. But people who already knew how to do the work had been made slower, and I think it is useful that Atlassian treated that as an incident instead of writing it off as users not liking change.
The positive test results were not fake either, and the new location was probably clearer for some people. Atlassian later said the broader change had been tested, while the exact location of Status had not. The early experiments also did not fully represent enterprise usage patterns or complex work items.
So both things were true: some people found the new version easier, while regular users lost a bit of the product they no longer had to think about.
And that is something a normal completion test struggles to show.
Test the bit people do without thinking
Most usability tests are trying to answer whether someone can work out what to do. That is obviously useful when the person is new.
But if you are changing a screen people use every day, you also need to know what you are making them work out again. Put the redesign in front of someone who knows the current product well and give them the repeated task, not a guided tour of the new layout.
Watch for the wrong tap, the scroll back, the little pause while they scan the screen, or the explanation that starts with "I normally just..."
They might still complete the task. They might even tell you the screen looks cleaner. That does not mean you have preserved the way they used it.
Sometimes that cost is worth it. Old layouts get messy, hierarchies can be wrong and a familiar action might be sitting in a genuinely stupid place. The benefit has to be worth asking regular users to relearn that bit of the product though.
Atlassian's next Jira work-item redesign will begin as an admin-enabled beta, while individual users can return to the classic view. That gives the team a chance to see the damage its first tests missed, while people still have a way back.
If regular users keep clicking the old place, scrolling back or switching to the classic view, do not hide behind task completion. The screen might still work, but you might have made the work worse.