Katie reads so you don't have to! (Inmates are Running the Asylum)

In a new occasional series, I'll be covering some of the content of the books I read on usability and design principles. Why? Well, to start off, these are awesome books. You read them, and you start to rethink how you do your project plans and interfaces. They're full of gems that can be applied immediately.

They're also, well, books. How many of us have books on our bookshelf that we swear we're going to read when we have the time? How many of us have picked up a book, gotten a chapter or two in, then gotten distracted by the nearest shiny object like a new video game, a pesky deadline, or the need to eat?

These are not book reviews. There are reviews out there on these books. This is a post covering a particular gem in a book and my take on it.

Today, I want to talk about The Inmates are Running the Asylum by Alan Cooper. This is a book that is both very useful, and that many developers will likely hate. That's not because it's boring, full of manager-speak, or tries to be too cute. Developers, you would not like it because it has one pretense:

Don't let developers design your interface.

Once drilling that home, they talk about how to do interface design, and the tricks their company uses. My favorite so far? The Personna.

When you read through use cases, you often catch mentions of 'the user.' Exactly who that user is stretches infinitely. In one use case, the user is a rather savvy power user who doesn't mind five or ten steps to properly encrypt, upload, and check a file. Sometimes, the user is your gran, who finds computers terrifying and needs everything one click away. Sometimes, it's a designer wants every feature to have a clever icon rather than a text label.

This will not do.

Cooper, in his consulting business, constructs concrete personnas that will use their application. They have names. They like certain kinds of foods over others. They like to dress in certain ways. They have physical ailments. They have specific experiences with computers. They're stereotypes, but they're supposed to be. If you can make that personna happy, you can satisfy a huge chunk of your market.

Let's say I'm going to make a new application. I could just assume that everyone that will be using the software will be as snazzy as me, willing to learn interfaces in order to get software to do what I want it to do. I'm tricky enough to just make shortcuts to the parts of the application I really want, and ignore most of the keen navigation.

If only this software was just for me.

Realistically, this software is going to be used by people who are not computer geeks who can keep the interfaces of their favorite programs in their head. It will be used by secretaries or lit majors or computer haters. There may be some geeks, but you want to go after the lowest common denominator. Make them happy, make a LOT of people happy.

So you make a personna, and get into their head.

I get a request to make a new file sharing site (something I'm actually doing at the moment). All sorts of people are going to use this site, but I'm going to make a personna who is my lowest common denominator. If I can make him happy with my system, then I can make anyone happy with it.

Let's call him Bill, if only because I don't know any Bills personally at NASA.

Let's make Bill an Earth scientist. His job is to review proposals for new satellites from everywhere: companies, other sections of NASA, universities, think tanks. Two decades ago, when he started doing this, it was in the form of dead tree sent by post to HQ. He'd lock them in a cabinet, and when he wanted help reviewing them, he'd call a meeting and they'd all review them together. One copy. No one else saw them unless they could get in the building, find his office, find the filing cabinet in the mess of his office, and procure a key.

It was simple, and it was secure. There was no ambiguity.

Then came the damn internet.

Now, everyone wants to share things online. He tried email, but they couldn't keep the versions straight. Sometimes the files were too large. Sometimes, they were full of sensitive data that wasn't to go through unsecured lines. He's used the shared drive, but he can never tell who can see the files, and those outside of NASA certainly can't get to the shared drive.

We're making this app for him.

The first idea we had, to have lots of customization available, went out the window. Would Bill want to take tons of time to tweak folders at every level? Not likely. It would just frustrate him and have him using us at every turn to tweak and recheck the configurations.

So we went from having tons of customization to having a few stock options that could cover 90% of all requests. The last ten percent could be covered by experts.

The old system had admins making all the boxes. Would Bill want to wait? No. He never needed someone to set up his locked filing cabinet. He'd just make a new folder and put everything there. So we'd have to make it simple enough so that he could make the box on his own.

And as for who could access them, that had been easy. Whoever he gave a key to, or whoever he invited to his meetings could see the files. He knew who could add files (whoever had a key). So, we want to make this information readily apparent to him every time he uploads a file. Who can see the file, and what else they can do, is everywhere.

As a mental trick, I find that it's helping us streamline our designs. It takes some practice, but it keeps your apps from being a bucket of functions with nothing to hold them together, a thing that could only satisfy an elastic user.