Inter-system user experience
(flickr tag: security)
In a recent Boxes and Arrows article Ease of Use Outside the Box, Mike Padilla presents a couple examples of user experience improvements external to our applications that can make a big difference to the users. It’s a good article to read, but there was one point in particular that reminded me of something I witnessed a few years ago. Mike Padilla writes:
Everyone logs into applications in the workplace. Whether you’re submitting an expense report, entering worked hours, or just logging into an intranet, you have to authenticate yourself as a valid user. The integrity of authentication lies primarily with password policies that govern password complexity and required frequency of change.
A good password is one that cannot be guessed. And there within lies the problem. What is difficult to guess is most likely difficult to remember. This problem is mulitplied when you have many applications that require authentication, each with its own password policy that dictates password complexity and mandatory resetting. So while a hacker may not be able to guess your passwords, you most likely will not be able to remember them either. So what do you do? Do what everyone else does (but knows they shouldn’t) – write your passwords down on the small piece of paper in your desk drawer. Not exactly the most secure practice.
The problem here is that the security folks design their password policies in a theoretical world where they only consider computers and hackers. Make the passwords very strong. But the primary end users, the people who actually log in appropriately, are not considered. The ultimate result is systems that are less secure. People are people. Defining password policies without considering the complete human context in which they are applied results in lower security.
When I was in college, I interned at a company that made electronic security systems (essentially, electronic locks). Naturally, the company had its own locks installed on all the doors in the building. The engineering department was blocked off by two doors and you needed a key fob to enter. The amusing thing was that on several occasions, I saw simple ways that people circumvented these security measures. My favorite was a screw driver stuck in the crack between the door hinges, but the most common one was a bunched-up rug that made the bottom of the door get stuck open. And this was at a company that actually made these security systems.
The sad truth is that when you throw people in the mix, they will find ways to circumvent any security measures, even if they’re there to protect them. The reason for this is simple — security is often an inconvenience, one that people see as unnecessary.
On a related note, Jason Fried of 37signals has an interesting perspective on control vs. communication:
When [customers] ask how to prevent people from doing this or that I usually reply with something like “Have you tried asking them not to do this or that? If you don’t want them to upload files just ask them not to. If you don’t want them to create to-do lists just ask them not to. Communicate with them as you would if you weren’t using software.”
And to my delight, their replies are usually “Great idea! I hadn’t thought of that. I’ll try that and see how it works.” Follow-up emails usually come back as success stories.
Simply communicating with people about your expectations of their behavior is often the simplest and most effective solution. It’s respectful, it’s kind, it’s fair. And if someone does something you didn’t want them to do just remind them politely that they weren’t supposed to do that. They’ll almost always get it the second time.
While Jason’s advice wouldn’t work for places where security is essential (legal compliance, for instance), it is good advice in many cases. Instead of putting up walls, software should be more friendly by removing restrictions.
