Your Best UX Instinct Is Wrong Half the Time

Your team has one reflex baked in deep: remove friction, hide complexity, make it smooth. It's the safe answer in every review. Nobody gets fired for shipping easy. But a run of recent writing makes a sharper case: that reflex is a default, not a law, and it fails in ways you won't catch until the thing is live. Let me catch you up.

Smooth can make it forgettable

Start with the idea that friction is always the enemy. Designer Ida Persson takes it apart in a piece on friction and meaning. Her friend Molly says it plain on a hike: "We spend so much time making things frictionless, but by making it frictionless we make it forgettable."

The research backs this up. There's the effort heuristic, where people value what they worked for. IKEA lives on it. People love furniture more when they built it themselves, screws and all. There's desirable difficulty, where harder-to-process information sticks better. Remove all the effort and you also remove the reason anyone remembers you.

This is not permission to make your product a chore. It's a reminder that some struggle is the point, not a defect to sand off.

The pause that builds trust

Here's proof that a little friction earns its keep. Think about clicking submit on a bank transfer and getting an instant confirmation, no delay at all. A lot of people don't trust it. As one breakdown of loading screens puts it, instant feels too easy, almost like an error.

So a spinner for a second actually helps. The wait signals that real work happened. How you wait matters more than how long you wait. That's a design lever, not an accident.

Same logic runs the other way in e-commerce. Buy-now buttons strip out the pause on purpose, so people buy on impulse instead of thinking. When you cut friction there, you're not helping the user. You're helping the cart.

Clean interface, hard experience

Now the trap. Smooth and simple are not the same thing, and confusing them is where good teams go wrong. A polished dashboard with slick animations can still be miserable to use. As one look at UX complexity argues, a user booking a flight or filing taxes does not care about your component library. They want the task done.

The damage builds up quietly, one reasonable call at a time. Another setting. Another confirmation screen. Another workflow. Each one felt like flexibility in the room. Stacked together they become a wall. Word 2003 hit 30 toolbars before the 2007 ribbon pulled it back.

The fix is not fewer features. It's showing advanced options only when someone needs them. Complexity you can't delete, you can still hide until it's asked for.

The user you never met

Here's the biggest blind spot, and it's not about friction at all. It's who your defaults assume. Nandini Mediratta lays it out in why UX advice fails in rural India: the imagined user behind your playbook has years of app experience, stable internet, a personal device, spare storage, and enough confidence that a mistake is a minor annoyance.

For India's next 400 million users coming online, none of that holds. Different constraints, different mental models, a different relationship with technology. Your Silicon Valley heuristics still work in parts, but they stop being the full story.

This is not a translation job. Swapping the copy to Hindi does not fix an interface built for someone who has never been nervous about breaking an app.

The deep cut

The thread across all of this is that your defaults carry hidden assumptions, and the assumptions are invisible until they break. Frictionless assumes friction is always bad. Simple assumes your user thinks like you. Both feel neutral in a review, so nobody challenges them.

So challenge them on purpose. Before you strip out a step, ask what that step was doing. Trust? Memory? A moment to reflect before a purchase? Before you call a flow simple, watch someone unlike your team try it, ideally on a cheap phone with bad signal. Alan Dix's point about designing for peak experience fits here: a design that's good enough for everyone is loved by no one. Pick who you're building for, then defend the friction that serves them.

Three questions for your team

1. Pick one flow you made frictionless this year. What was the removed step actually doing, and did losing it cost us trust, memory, or a moment to reflect?
2. When we call a screen simple, whose device and connection are we picturing? Have we watched our real edge-case user try it, or just our own team?
3. Where are we stacking options because each one felt reasonable in the moment? Which of those could we hide until a user actually asks for it?