Your browser doesn't seem to support CSS, which this page uses for all styling. Don't be surprised if it looks kinda boring.

[Jump to nav]

Easy to use

Ease of learning is important, to be sure. But, for something you use more than passingly, you use it a lot. It took me about 10 minutes to learn how to use a hammer. I don't do much hammer-work, but I'd still say I've spent many hours of my life using a hammer. If it took me an extra, say, 5 minutes, to learn to use a hammer, but that increase in complexity/flexibility saved me 5 seconds every time I used it, I'd call that a good deal. You spent more time doing than learning.

Now, the obvious rebuttal is that you learn constantly. In fact, I even said that the best systems are the ones you learn more about forever. But there's a basic level of proficiency that is the 'minimum' you have to learn before you can use something. Beyond that, you're into use. Learning is just the beginning, where you learn the basics.

Easy to use, in the same way, means exactly what it says. It doesn't mean anything more, though. It doesn't include easy to learn, or easy to use without learning. Just ease of use once you know it.

Now, that seems almost like a meaningless qualification. After all, once you know how to use something, it's easy for you to use, isn't it?


Not so, my boy! There's plenty of things in the world that aren't easy to use, even when you know how to use them. I have a decent knowledge of how to use the Windows UI. How it sets up different windows, how to switch between them, etc. But it's not "easy" for me. Some of that, to be sure, is about habit; I habitually use a much different interface.

But I think the concept goes beyond that...


Intuitiveness is an important aspect of learnability. I think it's an important aspect, in a different way, of usability as well. The most usable interface is, of course, the one that is the most natural to you; the one that works exactly the way you do. Of course, that's very subject to individual taste, so it's difficult to really approach.

When it happens, it's often coincidence. Everybody on the planet thinks and acts a little differently from everybody else. There are broad classifications that fit, of course, and there are some that are more common than others. But really, trying to design for the user's intuitivity is like trying to blow a sailboat up the Hudson. Rather, look to more general techniques for improving usability.

Play the board, not the player

That's a common platitude in playing chess. But it's sound theory, and it's applicable to system design.

There's a lot you don't (or can't) know about your user. But you do know one thing: he's going to be using your program. And if he's using your program, it basically means he's going to be doing the thing that you designed your program to do.

It must be inserted here that you may not be designing a program. It may be an operating system. It may be a webpage. Regardless, it's something that is used. I'll be talking from the perspective of a program here, because that's the most general form I can think of to talk from.

A program is based on 2 things. The first is a set of data. The second is a set of operations performed on that data. By knowing those 2 things, you have automatically gained an enormous amount of information about the user. You know, in a general sense, what he'll be doing, and what he'll be doing it to. That gives you a lot of latitude to figure out what the user will expect to do at given stages, and so you already have a handle on what is likely to be 'intuitive' specific to your program at various stages.


But let's move out of specifics. The specifics of your situation are known best to you, and vary from situation to situations. There are some general usability concerns, the first of which is consistency.

If you do a certain thing, it will have a certain result. If you do that same thing again, it should have the same result. If you do that same thing in a different "place", it should have a comparable result. There's a number of descriptions of this concept. POLA is a term used in software development. Raph Koster's Laws of Online World Design is a set of general rules and observations relative to designing online games, like MUD's. It includes something called "J. C. Lawrence's 'do it everywhere' law", which states:

If you do it one place, you have to do it everywhere. Players like clever things and will search them out. Once they find a clever thing they will search for other similar or related clever things that seem to be implied by what they found and will get pissed off if they don't find them.

It all boils down to about the same thing. Invent a (or, more likely, just use an existing) technique. Use it. And then keep using it everywhere it fits. Don't do things differently in different places.


No matter how well you design a system, sooner or later someone will want to do something you didn't plan for. And no matter how good you are, you're unlikely to come across the absolute best way of doing something. The more flexibility you allow, the more efficiency, and the longer lifetime, of usability you allow.

And, don't forget that the same applies to your development! The more flexible your design, independent of the user interface, the easier it is to add things later. If you have to fight what you already wrote, it will be tough on you, and it will show through in the finished product. And if something looks like a last-minute pin-the-tail-on-the-donkey addition, it becomes harder to use, as well.


Let's wrap it up with some lessons learned and applications.

  1. User Friendly? What's that?
  2. What User Friendly Really Means
  3. Learnability
  4. Usability
  5. Application