[tags]design,usability[/tags]
How many times have you been minding your business, assuming you have total and complete privacy and BAM the privacy is broken for a split second as someone bursts into your private haven that you’ve made of the public rest room.
Those locks never seem to work. I don’t like blindly trusting a lock. If I push a button, how do I know it works? I don’t. What I do like is big heavy dead bolts that I know work. I turn the device and if I can’t see it, I can at least feel that it’s preventing the door to open.
Even better are the bolts that actually mark a room as being occupied (like the lavatories on airplanes).
Then there are the latches and levers that make a vain attempt at locking, but really just don’t do what they say they’re going to do.
I thought about this, and it makes for a great design analogy…
- We need to make features that people don’t need to blindly trust.
- We need to make features that are trustworthy.
When I hit save, or I hit modify in a web app, I want to know that the save occurred or the modification took place. I shouldn’t have to glue my eyes to the screen and just look for that flash that occurs when a browser refreshes. With Ajax, things like notification are generally planned out in advance (indicators, etc). At the same time, they are absolutely necessary. Features need some sort of feedback to tell you, yes, I did exactly what you wanted.
We also need things that are trustworthy. If a feature is enabled or activated and there’s a notice, let us know. But don’t lie. Do whatever sanity checks that need to get done to make sure this really occurred. Don’t be the bathroom stall lock that says it’s locked but gets easily unlocked with a gentle nudge.