This article is for software builders, particularly those who work on UI/UX for large user bases! It explores the concept of UI/UX thrash, its negative impacts on users, and how to build empathetically and intentionally to decrease thrash.
It’s about a 15-20 minute read; thanks for reading. 🙂
Imagine that it’s Sunday, and you’re going to a diner you’ve been a regular at for years. You order your usual burger, and then it shows up…with mayonnaise…an ingredient you detest that wasn’t there before. The menu’s totally changed! Now you realize you need to pay more attention to the menu changes, and your relaxing Sunday routine now requires some extra mental energy.
Then, the tables get rearranged and your favorite spot with the right lighting is no longer there. They redecorate the place, and you’re not so in love with the vibe anymore, and the music feels just a little bit too loud for your liking.
Over time, as you encounter more and more these changes, your love of the restaurant slowly withers. These changes might not even be negative for other people, and the Yelp reviews from new customers might even be getting better, but your trust and love has degraded. You stop recommending people to the diner, as it’s no longer the place you once loved.
Meanwhile, the restaurant owners might be thinking, “Ooh, we’re doing so well with our new changes! We’re even getting more customers lately! Maybe we should change even more things!”
(This hypothetical is purely fictional, but I truly do not like mayo 😛.)
Modern software products change a lot more than at restaurants, especially in early stages. Restaurants, like software, also have user interfaces (UI) and experiences (UX).
If we’re lackadaisical about making these changes all the time, it’s like re-arranging the restaurant floor and the menu every single month. Many people might not notice or comment on it. But over time, if small, poor experiences are had repeatedly, it contributes to a cumulative negative experience that doesn’t bode well for our products or our restaurants.
This doesn’t mean you, the developer, should fully cater towards a conservative part of your user base who may not want any change, but we can build software in a way that massively reduces negative experiences for all kinds of users involved, and often even helps us build faster and more reliably.
Being a good UI/UX developer means being an empathetic builder, being able to predict and measure how users will respond to the changes in your product, and to sequence and design changes in a way that reduces the overall UI/UX thrash.
What is UI/UX thrash?
How I define UI/UX thrash (or disruption) is when new changes we build into the product disrupt users, because their expectations do not align with how the product behaves.
This could be because of:
- Behavior changes: We change product behaviors, business logic, or move things around without users being able to easily discover or learn these changes.
- Bugs: We introduce bugs that prevent users from reliably completing flows they expect and we hurt the product’s overall reliability.
- Performance: The software degrades and slows down users from going through flows as quickly as they used to be able to.
- Friction: We’re otherwise adding friction to the user experience or user interface in a negative way.
Commonly thrashed UI/UX includes: content (any text), keyboard behavior (shortcuts, tabs, navigation), accessibility behavior, i18n (internationalization) and l10n (localization), help content, and developer APIs.
We as developers might be:
- Building what we believe to be new, better products and features.
- Fixing behaviors we believe to be incorrect or inconsistent.
- Testing out different experiences to decide which would be the best one to finalize.
From our point of view, we might think the user behavior before was wrong, and therefore users are wrong for liking it. That doesn’t at all change the fact that we introduced UI/UX thrash and a negative experience that adds up.
Examples of thrash
Previously, I worked for a startup company that focused on organizing event processes. I created a mini program that had a decent interface at the beginning, but as I gradually stacked it, it became a bit flashy and bloated. Below are some examples, which are not from our company. Let me take Facebook, which I have been using frequently recently, as an example
At …
Negativity adds up faster than positivity does.
One may ask, “so what? it’s just a few minor bugs and they’re not that big of a deal!”
Unfortunately, humans notice negativity and change far more than positivity and consistency.
Once someone notices one flaw, they’ll often start to notice many more. Over time, all these little bugs, performance issues, and behavior changes accumulate and take a toll on user sentiment towards the product. Many will begin to ask, “Is [X] getting worse, or is it just me?”
Negativity begins to spread like wildfire, in the form of public reviews or private word-of-mouth. The 1-star reviews are paid far more attention to by prospective users than the good reviews. This occurs in every industry, from service, to commerce, to software. Reputation sticks.
Your mistakes often cost you more than your shiny new features win back.
When you introduce thrash, you’re introducing negative experiences, multiplied by the number of people who encounter them.
- New feature rollout moves buttons around for an existing task x 10,000 people confused to where the old flow is x 1 minute figuring it out = 166 hours of wasted time & lots of confusion
- Bug where a task is slowed down for 5 seconds x 10,000 people encountering that bug x 5 times per week = 69 hours of wasted time, every single week & lots of annoyance
Facebook was thrashing daily users in the tens to hundred of millions in its product development cycle, which significantly hurt its love and trust over time. 💔
It’s extremely hard to measure the impact of thrash by data analysis, since they accumulate from many different changes and have long-term, deferred impacts.
As a proxy, we can measure fixes to thrash (which should be done rarely, as this hurts product quality for the sake of measurement).
At Facebook, a bundle of reliability, quality, or performance improvements that took hours or days to build would often have more statistically significant wins in top-line metrics than features that took months to build.
Why didn’t people work on these improvements more?
My answer: Incentives and culture. Bug fixes, polish, performance improvements, and reliability, are perceived as less impactful and valuable than new feature development for one’s career. PMs have to keep proposing new features and projects, and the product development engine needs to keep going. New features are easier to quantify and sell to leadership.
Finding the right improvements to tackle and tackling them also takes a lot of practice! It’s different than feature development, and folks didn’t practice it. Roles like Product Specialists existed just to help find the low-hanging-fruit reliability & quality problems but many major problems were often unaddressed.
Thrash affects people differently.
Throughout using a product, every single user builds expectations and knowledge over time. They come to know where certain buttons are, how to navigate through menus, or what specific icons mean. But thrash affects every user differently.
Types of people whom thrash affects less:
- Technically literate users (correlates with younger age)
- Casual users who don’t use the product much
Many users fall into this category! Most small-to-medium-sized UI/UX changes will go completely unnoticed, and users might not have any notable negative sentiment towards them.
Types of people whom thrash affects more:
- Less technically literate users (correlates with older age)
- Expert users and new, learning users
- International users who aren’t in the product’s primary locale
- Users who rely on reference content (videos, tutorials, books), much of which are made by external creators
- Neurodivergent users (e.g. with ADHD, dyslexia, autism)
- as someone with ADHD, UI/UX changes can be extremely jarring 😔
- Users with disabilities, perhaps relying on screen readers or keyboard / mouse-only navigation, or taking much more time to do tasks (e.g. Parkinson’s)
When you’re a daily user of a product, you’ve likely developed strong habits and reliance around the product behaving the way you understand it behaves. Any major behavior change, performance slowdown, or bug massively hurts your productivity.
Imagine if Windows suddenly changed Ctrl+C/Ctrl+V to no longer copy/paste or if loading any app took an extra 200ms!
Additionally, expert users disproportionally drive new users to the platform, by creating content or reviewing the product for others. If you erode their trust and love, you’ve lost the largest promoters of your product. These same users are often technical enough to migrate their entire workflow to another product, bringing along others with them.
At Facebook, thrash would occur to important creators all the time — whether it was the massive changes like the view count definition — or just day-to-day confusion as to where important flows were moved. I watched Harry Mack, a rapper who with billions of video views, struggle finding very basic flows on FB Live due to UI/UX thrash. Facebook struggled to retain creators all the time on their platform (for many other reasons too).
If your primary creators and power users leave the platform, the community and the value to regular users also gets hurt drastically. The long-term impact by user thrash is not captured by short-term metrics.
Build an exceptional product, and keep it great, and you’ll win the fruits of your labor over time.
Great products disappear into the background.
Guitarist Cory Wong at a post-concert “press conference” at the Warfield in San Francisco, CA.
Audience member: “Do you have any advice for artists who want to be more productive?”
Cory Wong: “…I try to relieve as many barriers as possible on the logistics side and the technical side. So I am very proficient in Pro Tools, Logic, engineering, and mixing. So that way, when I sit down to do something, I’m not worrying about “what’s that hotkey to do this?” and all of a sudden, my mind has diverted my attention and creativity from the artistic idea to this technical thing. That all needs to be 100% in the back of my brain, so anything that I need to do in the programs, is completely second nature, and the software is a part of me, so it just disappears into the background and I can focus only on the art.”
When software behaves as we expect it to, due to a combination of:
- Discovery: Features and changes are discoverable and learnable.
- Design: UI/UX behaves in an intuitive, well-designed, expected way.
- Knowledge: Time learning how the software works can be applied fully.
- Reliability & Performance: Software is dependable and meets our expectations of speed.
The software disappears into the background, and users can get into flow states and just focus on their task at hand.
“Good design is actually a lot harder to notice than poor design, in part because good designs fit our needs so well that the design is invisible” — Don Norman, The Design of Everyday Things
Every occurrence of UI/UX thrash or lack of user ↔️ software expectations alignment brings the software to the forefront again.
Imagine if while Cory Wong was using Pro Tools, and the keyboard shortcuts he was using suddenly changed after an update, or settings he was looking for moved to different places, or a key workflow suddenly became super slow. That thrash would certainly hurt his productivity, and he’d probably like the software a bit less each time he hit one of these experiences.
How do we reduce UI/UX thrash?
Ok, let’s not overcorrect and spend all our time bogged down in testing and worrying about thrash that we don’t get anything done. Features are important!
But there are some huge opportunities here, with investments in time and education, for a much more reliable, consistent, loved product. With the right balance, we can be both short-term and long-term minded here, and win in both fronts.
💡
All this advice is contextual — it depends on where you’re at as a company, what the state of your software and design systems are, and who your audience is.
Building high quality UI/UX takes craft and lots of practice! Trade-off management is key.
The ideas below are all toggle-able. I recommend you toggle through the first two.
#1. Slow down product development and decision making in the short-term. Build systems and principles instead of one-off decisions and short-term architectures.
#2. Test via dogfooding, automated testing, and/or betas before a full scale release.
#3. Run more thoughtful, empathetic experiments.
#4. Consider bundling multiple changes.
#5. Consider onboarding, education, or communications for UI/UX deltas introduced.
ㅤ | ㅤ | ㅤ |
ㅤ | ㅤ | ㅤ |
ㅤ | ㅤ | ㅤ |
ㅤ | ㅤ | ㅤ |
None of these five points are fool-proof, but they can be generalized to two directives:
- iterate on the meta of product development: answering the question, “What are the tradeoffs of our current product development cycle & how can we build better?” and raising the product quality bar.
- practice user empathy: answering the question, “How can I put myself into the shoes of users at scale and predict, understand, and measure the impact we’re making?”
In this quest, we’ll often try new things that don’t work out or feel like we took one step forward and two steps backward. That’s okay — c’est la vie. 😊
Some thrash is inevitable.
None of us have a crystal ball with a perfect roadmap, with optimal designs and systems with every detail perfect. Decisions, designs, and visions change over time, and it’s great that we are able to evolve products in response to new information like changing user requirements.
Some thrash is inevitable for us to evolve products and not have to work around massive design constraints. People don’t always love change, and we can’t overly cater to that.
But all users do care about consistency and usability, and helping align their expectations with our product outcomes is massive for love and trust.
With more intentional decision making and development, we can do thrash users less and building products that are loved and trusted by users.
I hope this article helped you in your journey to do so! 😊
Thanks for reading!
If this topic interests you a lot, I’d recommend checking out 📖 The Design of Everyday Things by Don Norman.
Much of this article is inspired from this book, my love for design, and my experiences as a full-stack engineer.
Further reading:
- Unchecked AB Testing Destroys Everything it Touches by Derek Zumsteg
- 📖 The Pragmatic Programmer by David Thomas & Andrew Hunt
