There's a widely held assumption in UX design that the goal is always to make things as simple and effortless as possible. Reduce friction. Minimise cognitive load. Make the happy path so smooth that the user barely has to think. And for a lot of software, that's absolutely right - nobody wants a clunky expense form or a laborious password reset. But I've spent the last decade designing safety software for high-risk industries like rail infrastructure and construction, and I've come to realise that sometimes, making something easy is the worst thing you can do.
Your brain on autopilot
The psychologist Daniel Kahneman described two modes of thinking in his book Thinking, Fast and Slow. System 1 is fast, automatic and instinctive - the part of your brain that lets you catch a ball or read a facial expression without really thinking about it. System 2 is slow, deliberate and rational - the part that kicks in when you're doing long division or weighing up a difficult decision.
You've almost certainly experienced System 1 in action without realising it. If you've ever driven home from work and arrived on the driveway with no recollection of the journey, that's System 1. Your brain has done the route so many times that it can handle it on autopilot, freeing up your conscious mind to wander off and think about what's for tea.
The neuroscience backs this up at a structural level. The brain's default mode network (DMN) is active when you're on autopilot - mind-wandering, daydreaming, running on habit. The executive control network (ECN) fires up when you need focused, goal-directed attention.
Most people assume that creative thinkers are dominated by one network or the other, but research by Roger Beaty and his colleagues at Harvard found the opposite - highly creative people are actually better at coupling both networks, switching fluidly between spontaneous imagination and deliberate, controlled thought. Creativity isn't about being a dreamer or being analytical - it's about toggling between the two.
But the point I'm making here isn't about creativity. It's about what happens when System 1 takes over in situations where System 2 should be in the driving seat.
When easy becomes dangerous
In software design, there are plenty of tasks you want to be effortless. Logging in. Navigating between pages. Updating a status. Mundane interactions that users perform dozens of times a day, and the less friction they encounter, the better. But not every task in every product should be like that.
In the industries I've worked in, a track possession on a live railway - where a section of track is formally taken out of service so maintenance teams can work on it safely - is not something you want anyone sleepwalking through. If the wrong section is specified, or the isolation isn't confirmed properly, people can end up working on a live line. That's not a bad user experience. That's a fatality.
The aviation industry has understood this for decades. Checklists in cockpits are deliberately designed to force conscious engagement - read and respond, rather than tick and forget. Research published by NASA attributed several aviation accidents directly to crews becoming complacent whilst monitoring automated systems, essentially leaving System 1 in the driving seat for a task that demanded System 2.
The same principle applies in software. If your permit-to-work form is so streamlined that a site supervisor can fly through it in thirty seconds without engaging their brain, you haven't built a great user experience - you've built a liability. The whole point of that form is to force the user to stop, think and consciously confirm that they've checked everything. Making it frictionless defeats the purpose.
Appropriate friction
This isn't just about life and death, though. The principle applies anywhere the consequences of getting something wrong are severe enough to warrant the user's full attention.
Take your banking app, for example. Transferring £20 to a mate for last night's takeaway should be two taps and done - System 1 all the way. But transferring a £50,000 deposit on a house - you absolutely want friction there. You want the user to slow down, double-check the sort code, confirm the recipient and consciously acknowledge that they're about to move a life-changing sum of money. The cost of getting it wrong might not be death, but it could be financial ruin - and the design should reflect that.
Even dating apps. Swiping through profiles with reckless abandon is the whole point of the interaction - fast, instinctive - System 1. Until you accidentally swipe left on someone who could well have been your lobster. Tinder actually introduced a paid "undo" feature specifically because the frictionless design of the core interaction created a level of error that actually matters to people. The ease is the product, but the ease is also the problem.
For me, the goal of UX design is not to make everything easy. It's to make things appropriately easy or difficult, calibrated to the severity of the consequences if someone gets it wrong. For low-stakes, high-frequency tasks - navigation, search, status updates - the goal is to remove friction aggressively. It should be fast, intuitive and forgettable.
For high-stakes tasks - whether that's an electrical isolation on a construction site, a six-figure bank transfer, or anything else where the cost of error is serious - you want to introduce friction deliberately. Force the user out of autopilot. Make them read, confirm and double-check. Design the interaction so that it demands conscious engagement, not muscle memory.
This isn't about making software annoying or difficult for the sake of it. It's about understanding that ease of use and fitness for purpose are not always the same thing. A brilliant, frictionless interface for approving a confined space entry permit is a badly designed one, because it's optimising for the wrong outcome. You're not trying to help someone get through the form quickly. You're trying to make sure someone doesn't die.
It's an uncomfortable position for a designer to hold, because it goes against years of training and instinct. But if you're designing for environments where the stakes are real - whether those stakes are measured in lives, money or missed connections - it's the only one that makes sense.
