A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
Joel says that usability is the heart of good design and then goes on to define usability as "Something is usable if it behaves exactly as expected." But just because something behaves as expected doesn't mean that the behavior is good. What if the user expects something to behave in a predictable, yet laborious way: "I have to click these three buttons for it to do what I want. Yeesh, why couldn't they make it so I just had to click the one button!" So the user expects a certain behavior but that doesn't tell you if that's the optimal behavior to get the job done. Great design provides an efficient way for a user to accomplish their task while at the same time making its use obvious to the user. I think Donald Norman refers to these things as "affordances" -- the design itself sort of hints to the user how it should be used.
So in a sense, yeah, you could argue that these "affordances" equate to "behaves exactly as expected." But Joel makes it sound like you can fix a bad design by just asking the user what it should have done and then changing your design to match. What if there is an even better design that the user hasn't thought of?
Joel's rule is really more useful for sniffing out bad design: "If something doesn't behave exactly as expected then it isn't useable, and that's obviously bad design." You need other criteria for comparing one design against another. The example of Windows vs. Mac window resizing are two designs that behave as expected, depending on the users pre-conditioning. But it doesn't tell you which pre-conditioning is a better pre-conditioning to have.
Indeed. To use an over-used example which we're all sick of, look at the iPod. For simplicity's sake, look at the first generation, 5 GB iPod.
It has a wheel and five buttons. Four of the buttons surround the wheel, and the fifth is in the middle of it, sort of obscured and not really announing its button-hood.
Now, out of the box it isn't on, so at first you might look for an on switch, then quickly realize there isn't one. But there are those inviting buttons, and you feel the need to play with them, even though it's off.
Instantly it turns on, and you see some menus on the screen. That was neat. So you want to play more - that wheely thing looks kinda fun. You play around with it, and figure that it makes menu selections go up and down. You want to make one of those menu items do something, but none of the buttons surrounding the wheel do anything.
You futz around a bit and then notice there's a space in the centre of the wheel that doesn't move when you spin it. Hm - click. Yep, it's a button, and it just selected whatever menu item was highlighted.
Pretty quickly you're playing a song and figuring out how the thing does other wonderful stuff.
You might be able to look at a picture of an iPod and discern how it works, but I wouldn't be able to. There was no expected behaviour - other than that it would play music.
For me, it was the fact that its buttons and wheel get you to play with it. It's fun to experiment, and the interface is consistent enough (at least on the original iPod) that it quickly becomes predictable.
Until it freezes up and you have to reboot it.
"Behaving as expected" is different from "behaving as the user has gotten used to". The question is, what would someone expect who's never worked with your app before? This is why usability tests try to use people who've never seen the app or web site before; the question is "How intuitive is it?" Which is the question your hypothetical user is answering.
There's no reason to suppose that there's one, grand, supremely usable design. You could have several different designs that are all usable, but just happen to be used in different ways. Whether my stove puts the burner dials in a square corresponding to the burners, or puts diagrams next to each one highlighting which burner it goes to, or simply prints words like "FRONT LEFT" or "BACK RIGHT", I don't think there's a major difference in usability. Any of these would be far more usable than a stove that just puts the dials in a line with no markings.
On the other hand, I'd find the first two far preferable to the third when my mother-in-law's visiting, as she doesn't speak much English! Which is why it's important to identify your target audience and test with them.
Now I'm curious what my stove has.
It has diagrams. So my mother-in-law can use it too. :)
I think Kyralessa said it nicely, but I thought I could add my two cents to it. I think part of what Joel was going for (and what I agree with him on) was reducing/eliminating the entrance/exit cost.
The point was that if the existing products in the market do a certain operation in a certain way (well designed or not), and 99% of your customers will be migrating from one of the products, then it's easier for them to use your product if the same operations are invoked in the same manner.
The iPod was rather unique in that most people didn't have an expectation going in, so Apple could invent their own UI. Now that we have it, if any other music player had a wheel on it (yeah, I know it's patented, but "what if"), we would expect it to work in the same way. If it didn't, even if it was more efficient, we'd probably be less efficient at using it because it's not behaving as we expected.
Is it better design to have one button do something that it used to take 3 to do? I think so. Is it a better design if a user can figure out how to do things in 3 sec instead of 3 min? Yes. Even at the expense of good design? I would still say yes. I think this latter point is more important and what Joel was saying.
Wednesday, March 08, 2006
> puts diagrams next to each one highlighting which burner it goes to, or simply prints words like "FRONT LEFT" or "BACK RIGHT",
You have obviously never used a stove with little pictures, and of course worst of all, a stove with the controls in back so you have to REACH OVER POTS AND PANS AND POSSIBLY RED HOT BURNERS to adjust the heat. G-D help you if you have loose sleeves or even a stray thread hanging down.
dot for this one
Thursday, March 09, 2006
There was a formulation in Joel's first edition of his UI book (which may also be in this one). Something like: Software is usable if the program model is the same as the user model. I like this better because I think about the user having an idea of how my software works as a unified thing. They have a whole model in their head of my software. I have a goal: to match that model.
Joel then goes on to say that the user model is very simple. I like this, too. It's hard to make a program respect a simple interaction model, but well worth it.
Saturday, March 11, 2006
The idea of matching the user model with the system model was introduced, as far as I know, in "Design of Everyday Things" by Donald Norman. Much of what Joel says regarding UI design finds roots in this book, Joel having reformatted it to be more easily digested by software developer types.
If you want a broader and more theoretical version of Joel's advice, I highly recommend the book.
Wednesday, March 15, 2006
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz