Stop Treating Your Users Like Children

I spent about 15 minutes yesterday bulk deleting photos from Google+. Each time I clicked delete on a photo the computer so kindly asked me “Are you sure you want to do this?” I dutifully clicked “Yes”, as I’ve done thousands of times over the last 20+ years. Then, it hit me. Why am I still doing this? It’s 2013. If my computer were a sentient being and asked me to confirm every time I took some slightly dangerous action I would respond with something very sarcastic. “No, I don’t really want to do this. I just love clicking buttons.” Actually, I don’t. It made me feel a little like this guy. Why do we continue to think that we know our users better than they do? Why are we treating our users like children that we must protect because they aren’t able to protect themselves? Actually, that’s really not what’s going on. I’ve designed enough product to know that we’re not all sitting around thinking “Poor users, they just don’t know any better.” I think there is a much simpler explanation. We are lazy. Why are we lazy? It’s just so much easier to specify that a developer throw up a confirmation box then think through the problem. The thing is, it really doesn’t need much thought at all. The pattern for dealing with safely managing destructive actions has existed for almost as long as the computer. It’s called Undo. Ah, the Undo. You have saved my butt more times than I can count. And that’s exactly what you are there for. You are like Lindsay Lohan’s personal assistant. Never seen but always there to clean up the mess she makes. Why doesn’t every application implement Undo? Well, building an Undo system isn’t easy. It’s actually kind of a pain and you must plan for it up front. Despite that, every destructive action should have an Undo function. Why? Because your users have conditioned themselves to just blindly click on dialog boxes without reading them. Especially if they need to click many of them in a single session. They may just end up doing this. Confirmation boxes are a way for the product team to wash their hands of any responsibility for the actions their users take. Undo however, puts the responsibility back in the hands of the computer, the software team and the product owners. It’s harder to implement but provides a much better experience for people like myself.

Exceptional design, not designing for exceptions.

In the example I mentioned at the beginning, I needed to bulk delete my files. I clicked, confirmed, clicked, confirmed until I deleted each file. That was normal usage. The exception is a click that accidentally deleted a file. Despite that, the developers thought that I would need hand holding because I would potentially shoot myself in the foot each time I deleted a file. Just let me delete the files! If I click on something by mistake I’m going to realize it. I can then just click the Undo button and poof, the file is back. It collapses 20 button clicks down to 10 + 1 undo. This is a much politer user experience. The Undo has been around a long time. If your application needs to do something destructive, consider implementing Undo before putting up a confirmation box. Doing so will go a long way toward treating your users like peers instead of children.

Stay Ahead in Product Management!

Ready to elevate your product management game? Join our community of passionate professionals and be the first to receive exclusive insights, tips, and strategies directly in your inbox. Subscribe now to our newsletter and ensure you're always in the loop with the latest product management trends and wisdom bombs!