Introduction
If you’ve opened YouTube on your phone recently and felt something was off, you’re not imagining it. The like, dislike, and share buttons moved. Text labels disappeared from icons. Channel names got replaced with usernames. Save and download got tucked into a three-dot menu you now have to go looking for.
Most users reacted the way people usually react to change. They complained. Muscle memory broke. Familiar taps led to nothing. Online threads filled up with people asking why a company with unlimited engineering resources keeps rearranging furniture that already worked.
But this isn’t YouTube being careless. It’s YouTube being deliberate about a problem almost every growing software product eventually runs into: features pile up, and nobody owns the job of taking any of them back out.
YouTube actually published the thinking behind this directly. In a post on its official blog, the VP of User Experience laid out five specific principles the design team uses to decide what stays visible and what gets tucked away. That post is worth reading in full, but the short version is useful for any founder building a product right now.
The Five Principles, And What They Actually Mean
YouTube’s stated approach breaks down into five rules. Stripped of the corporate framing, here’s what each one is really doing:
Make content the star. Anything that visually competes with the core thing a user came for gets moved out of the way. YouTube gave the example of moving product overlays off the video itself and onto a shelf below it.
Prioritize relevance ruthlessly. If a button isn’t what most people are doing in that moment, it gets hidden, not deleted, hidden. YouTube said this decision came from actually looking at which Shorts player actions got used most, not from a designer’s opinion.
Choose the simpler option. When two paths solve the same problem, pick the one with fewer steps. YouTube pointed to trimming steps out of the Shorts creation flow as a direct example.
Be a good neighbor. Consistency across the whole app matters more than making any single feature stand out. Same icons, same layout patterns, same logic, everywhere.
Build for the ecosystem. The experience should feel the same whether someone is on a phone, a TV, or a tablet. Shared components across surfaces, not one-off designs per device. Read as a set, these aren’t really design rules. They’re prioritization rules. Every one of them is a different way of answering the same question: when two things compete for the same pixel, which one wins, and who decides?
The Real Problem: Interfaces Rot
Every app starts clean. Then it grows. A team ships a feature, it tests well, so it stays. Six months later another team ships another feature. Nobody owns the job of removing anything, because removal doesn’t show up in a roadmap review the way shipping does.
This is how you end up with an interface that has fifteen things competing for attention on one screen, most of them used by a small fraction of your users, all of them still taking up space and attention for everyone else.
YouTube runs at a scale where this problem becomes unavoidable. When your product serves creators, casual viewers, Premium subscribers, advertisers, and Shorts-only users all inside the same shell, every one of those groups pulls the interface in a different direction. Left unchecked, the app becomes a compromise that serves nobody particularly well.
The fix isn’t more design. It’s less surface area, decided by evidence instead of habit.
Why This Matters More On Mobile Than Desktop
YouTube’s most aggressive simplification is happening on mobile first, and there’s a specific reason for that. Screen space is scarce, attention spans are shorter, and thumb reach dictates layout in a way a mouse cursor never did.
On mobile, every visible element taxes the next one. Add a fourth button next to the video player and the other three get smaller, or the row gets crowded. There’s no “just add another row” option the way there is on a desktop dashboard. Mobile forces prioritization that desktop lets you avoid.
This is also why less-used actions like download, save, and report went into an overflow menu instead of disappearing entirely. The team didn’t decide those actions don’t matter. They decided those actions don’t matter right now, on this screen, for most people looking at it. That distinction is the whole strategy.
The Tradeoff Nobody Talks About
Here’s the part product teams underplay when they talk about simplification: it always costs someone something.
When YouTube moved like, dislike, and share below the video and buried save, download, and report in a menu, power users- the ones who use those features constantly- got a worse experience. They now need an extra tap for something that used to be one tap away. Creators who rely on visible engagement signals also noticed those numbers became less prominent.
Simplification isn’t a free win. It’s a bet that removing friction for the majority is worth adding friction for a minority. That bet only pays off if you actually know, from real usage data, who that minority is and how much they matter to your business.
This is where a lot of companies get it wrong. They simplify based on internal opinion, what looks clean in a design file, rather than what the data says people actually touch. YouTube’s own explanation was specific about this: the team looked at real usage numbers on the Shorts player before deciding what to condense. That’s the difference between design by taste and design by evidence.
If you’re building software and about to hide or remove a feature, ask a harder question than whether it looks cleaner. Ask who’s going to be upset, and whether the business can live with that.
Why Companies Wait Too Long To Do This
Most teams don’t proactively prune their interface. They wait until support tickets pile up, until a competitor ships something visibly cleaner, or until a redesign becomes a leadership-level conversation because engagement metrics start slipping.
By then, the fix is expensive. Removing a feature that thousands of users depend on, even a small percentage of them, requires migration plans, deprecation notices, and a support team ready for backlash. It’s far cheaper to build the discipline into the roadmap from day one: every new feature gets reviewed against usage data on a set schedule, not just shipped and forgotten.
YouTube can run this as a continuous process because it has the user volume to test changes on a subset of people before rolling anything out globally. Smaller companies rarely have that luxury, which is exactly why the underlying habit, not the specific tactics, is what’s worth copying.
What This Looks Like In Practice For a Smaller Product
You don’t need YouTube’s scale to apply this thinking. You need three things:
- Usage instrumentation on every feature, not just headline metrics. If you can’t tell which buttons get tapped and which get ignored, you’re designing blind.
- A recurring audit, quarterly is reasonable, where someone is explicitly responsible for asking what can be removed, not just what should be added.
- A tolerance for short-term complaints. Any meaningful simplification annoys someone in the first two weeks. The real question is whether it improves the experience for the majority over the following months.
This is product strategy work, not just design work, and it’s often where internal teams struggle, because the incentives inside most companies reward shipping visible new things over quietly removing invisible clutter. It’s exactly the kind of decision an outside product and engineering partner can help with, especially when internal teams are too close to the roadmap to see what’s become dead weight.
The Non-Obvious Insight
Here’s what most coverage of YouTube’s redesign misses. The story isn’t that YouTube made its app simpler. The story is that YouTube built a repeatable, documented system for deciding what to remove, and that system is more valuable than any single redesign decision inside it.
Any company can simplify an app once. Few build the ongoing discipline to keep doing it as the product grows, which is exactly when it matters most, because complexity compounds. A cluttered screen today becomes a genuinely broken experience two years from now if nobody is actively fighting it.
The Takeaway
YouTube didn’t simplify its app because simple looks better in a screenshot. It simplified because an interface serving billions of people across wildly different use cases needs a mechanism for saying no to features that no longer earn their place on screen.
That’s the lesson worth taking further than the button that moved. If your product has been shipping for a year or more without anyone asking what should come out, you’re not building a lean product. You’re building the next version of the app YouTube just had to fix.
If you’re weighing whether your product’s complexity is helping users or quietly working against them, that’s worth a real conversation before it turns into a redesign crisis.
