Band-Aids Only Hide Boo-boos
This post is part of a series about Designing the Obvious, a book about common sense Web application design. Learn more about this series.
When you cut your finger, you put a band-aid on. It doesn’t fix the cut, but it hides your wound from the world. In the face of an interface problem, the natural reaction is to place the equivalent of a band-aid over it. Too often, this doesn’t do much to change the underlying problem.
For example, here is my least favorite thing about MySpace:
Whenever a user clicks something that requires a login, MySpace redirects to the home page for authentication. This probably confused some users, naturally, because nothing was guiding them along. So, MySpace’s solution is to include a big red box with an exclamatory message that feels like a hand slap.
The red box is a band-aid for a broken login process. The login itself may be another band-aid for a broken privacy plan. Who knows the series of decisions that ended up at this point, but something is damaged, and the band-aids aren’t helping.
Designing the Obvious says:
“I don’t like band-aids. Instead of putting band-aids on problems, I perform surgery on them. Interface surgery.”
The book has several examples of interface surgery, where the author solves a problem by improving it a bit at a time. You may not agree with all the steps, but it is a joy to watch something become less broken.
But I have a problem, one I hope you can help me solve. Band-aids are often the simplest solution to a problem. As someone who loves simplicity, how can I advocate the additional time to get a better solution? Is it that extra work on my part makes it simpler for everyone else?
Let me know what you think below. There may be one of three autographed copies of Designing the Obvious in it for you. I’ll randomly select from the commenters on all of my Designing the Obvious posts once the series is complete.
[…] Band-Aids Only Hide Boo-boos […]
True, perhaps the Band-Aid is the simple solution for you as a designer.
But for most situations, it’s what’s simpler for the end user that matters.
Well put.
Like user interfaces, I deal with the same issue inside client companies with their employee-facing processes. From getting transactions authorized to on-boarding a new employee or the annual budgeting processes - setting a repeatable processes of any type in motion usually has a series of ludicrious steps (a likely result of excessive navel-gazing).
The answer is rarely another form to supplement the stack, or requiring your employees (users) to learn every nuance of your process. Inspiring is that rare company that is as concerned about employee user experience as much as they are about customer service.
I just had a crazy experience at UrbanDictionary.com and had to come right to this post and leave a comment!
I tried to add a new word to the popular urban dictionary (wantrepreneur) and after 4 attempts, I left the site.
They asked for my name and location. However, they said my name was all ready being used. So I used my middle name, no luck. I used a nick name, still no luck. I made up a name, no luck!
If they wanted me to create a unique user ID, why not just say so? And if I am being asked to do that, make it easy for me to know if the username is available (like real time checking or suggestions of available names).
Perfect example of a site not doing things right.