Disabling Inactive Menu Items

Joel Spolsky thinks that we should not disable inactive menu items because it’s confusing users who may not know why a menu item is disabled. In reality, disabling menu items is rarely a problem because it’s usually obvious why menu items are disabled (for example, if there’s no selection, you obviously can’t copy anything). ¹

He is right though that there are some cases where disabling menu items can be confusing (and Gruber’s solution to just let the user figure it out isn’t an acceptable solution at all). It’s not only menu items, by the way; all UI elements which can be disabled can confuse users.

Mac OS 7 had a solution to this problem: Balloon Help allowed users to mouse over disabled UI elements, getting information explaining why they were disabled (If I remember correctly, I used this feature in Interarchy - née Anarchie - more than once). Wikipedia writes:

Developers were encouraged to include help text with a certain grammar, and not only name the object being looked at, but also explain to the user any state it might have

What a great idea! Apple already thought of this issue in 1991! ²

In its infinite wisdom, Microsoft does not display tooltips on disabled interface elements (or at least did not show them the last time I wrote Windows software, two or three years ago). People, this is the only time users actually want to see these damned yellow thingies! What were you thinking?

Fortunately, Mac OS X does allow tooltips on disabled menu items. So just do the right thing and show an explanation telling the user why a menu item (or any other UI widget) is disabled.

Here’s a disabled menu with a tooltip:

And here’s a disabled checkbox with a tooltip:

Take some time to think of a good explanation telling the user why these items are disabled and how they can enable them, too.

Please don’t just assume that people will figure it out, and don’t confuse people by enabling menu items which should be disabled. Use tooltips instead.

Addendum: Daniel Jalkut has an additional solution to this issue: “If the problem is especially grievous, it could warrant a dedicated reference page in the documentation, where users could easily look up the cause of their frustration.”

While documentation should not replace usable interfaces, documenting such things is a great idea because some people will consult the documentation if they can’t figure out why something is disabled.

July 1st, 2008 / Tags: Gruber, Spolsky, usability, Interachy, disabled menu items, balloon help, tooltips / Trackback

Consistency Killed the Cat

When people talk about an application’s usability, they’ll often discuss the application’s “consistency.”¹ The more consistent an application, the more usable it is, it seems. But what exactly is consistency, and is it really always a good thing?

The relevant definition from Merriam-Webster is probably the one which says that consistency is

agreement or harmony of parts or features to one another or a whole

When people say that an application is “consistent” with its host system, they usually mean that the application “agrees” with its host system by being “similar” to other applications on that system. This is good because knowing how to use other applications helps users of the new application understand this new application.

However, not all forms of consistency are good, and not all forms of consistency are important. Let’s have a look at what consistency is and when it’s important.

Visual Consistency

Applications are often said to be inconsistent with their host system if they look different from other applications on that system. However, look alone doesn’t really matter. As long as users are capable of easily identifying the different UI elements, applications don’t have to look like their host system.

Here are a number of different buttons from different Mac OS X applications:

While some of these buttons may be downright ugly, they’re all immediately identifiable as buttons. The fact that they don’t look exactly like each other does not harm usability.

People see all kinds of different user interfaces while surfing the web. A different look doesn’t harm usability, as long as the individual widgets are easily recognizable, and as long as they behave the way the user expects them to.

Behavioral Consistency

From a usability standpoint, behavioral consistency is a more meaningful type of consistency than visual consistency. Being behaviorally consistent means that an application behaves in the same way as other applications, and thus in the way the user would typically expect.

The more consistent the look, the more important behavioral consistency becomes. Visual consistency can hurt usability if it gives a false sense of behavioral consistency, telling the user that a given widget will behave like something he already knows when it does not.

If an UI component looks exactly like a standard UI component, every little behavioral issue can confuse the user tremendously, essentially killing his suspension of disbelief and thus his trust in your application. This is the uncanny valley of UI design, and it is probably one of the issues people have with Firefox: because it gets the Mac OS X UI almost right, the remaining issues seem all the more jarring.

Some Examples — Combo boxes combine the features of a text box and a dropdown menu. Here’s what combo boxes look like in Mac OS X:

Clicking once on the blue arrow will open a menu from which the user can select a predefined value:

This is a combo box from OmniFocus:

Even though it looks different from normal combo boxes, it is immediately recognizable as a combo box. Unfortunately, it doesn’t quite behave like a normal combo box. For example, if the focus is on the text box, clicking on the little arrow will open and immediately close the menu. If the text inside the combo box is not selected, the menu will remain open (as it always does for the normal combo box).²

Here’s another example. This is a window from a Fireworks beta,³ sporting Adobe’s new CS4 user interface:

This looks pretty much like a normal Mac OS X window with a bunch of color changes. It doesn’t behave quite like a normal Mac OS X window, though. For example, clicking on the “zoom to fit” button will maximize the window. In most cases, Mac applications should not maximize windows when this button is clicked. Instead, the window should be resized to fit the exact size of its content.

Another discrepancy to “normal” windows is the fact that you can’t resize this window by dragging the bottom-right corner. Or, more specifically, you have to hit the actual border of the window with your mouse, instead of the empty area inside the corner.

Finally, the CS4 windows don’t show the “this document has unsaved changes” dot in the close button, which can be confusing if you make changes to the document and don’t see these changes acknowledged by the application.

Details such as these are incredibly frustrating to your users. It’s okay to introduce new concepts that don’t already exist on a platform. It’s not okay, however, to ignore the things your users have already learned while using other applications, or to actively go against the things your users already know by mimicking user interface elements they recognize while making them behave slightly different.

An extreme example of this are applications which abuse existing UI components for something else than what all other applications use them for.

False Friends — Before I explain this next and final example, I want to say that I’m not actually sure VectorDesigner is doing anything wrong as per Apple’s HIG. I do, however, find what they’re doing quite confusing.

Mac OS X supports something called a “toolbar.” This is the list of icons many applications show at the top of their windows. Here’s how they look in Apple’s Keynote:

Clicking on some these icons will start an action. The “Play” icon starts the presentation, the “Text Box” icon adds a text box to your active slide. Clicking on others will open a dropdown menu, and clicking on one of the entries will, again, start an action. These toolbar icons have no active state; clicking on them will not activate the icons.

However, Toolbars can have icons with active states. Apple calls them “Selectable Toolbar Items” and writes:

This is often used in conjunction with an NSTabView that is configured to have no visible tabs.

Apple writes that this is “often” used in conjunction with an NSTabView, but in fact, tabs is almost the only use of selectable toolbar items I’ve ever seen. Here’s an example for selectable toolbar icons used as tabs; it’s Safari’s preferences window:

In fact, I have never seen this look described as anything other than “tabs.” For all intents and purposes, users don’t see these “selectable toolbar items” as toolbar items at all, but as tabs. Clicking on them does not select tools, but changes the windows contents in almost all applications which use them.

Vector Designer is probably my favourite vector drawing application. I’m using it every day. Yet its toolbar still regularly throws me off.

Admirably, Vector Designer goes for an iWork type of user interface. It has a toolbar similar to Apple applications like Keynote. However, while Keynote’s toolbar icons start actions, Vector Designer’s toolbar icons are selectable tools. Clicking on them changes the tool you’re currently working with. This means that Vector Designer uses Apple’s “Selectable Toolbar Icons,” which look like tabs in Leopard:

Clicking on the icons with the small triangles opens a dropdown menu:

The fact that I’m clicking on something that looks like a tab to select a tool or open a dropdown menu seems terribly strange.

In Vector Designer’s defense, selectable toolbar icons used to look different in earlier versions of OS X, but it seems since most developers use selectable toolbar icons only for tabs, Apple abandoned the “button” look and went with a tab look pioneered by Panic’s Coda.

Perhaps it was a bad idea to mix the concept of selectable toolbar icons and tabs in the first place, but now that these things look like tabs, and most devs use them as tabs, using them as selectable tools is starting to feel terribly inconsistent. People are used to seeing selectable toolbar icons as tabs, and that’s what applications should use them for.

If anyone knows other applications which use selectable toolbar icons to select actual tools, please drop me a line.

Internal Consistency

So far, we have discussed consistency with the host operating system. However, there is a second kind of consistency: Consistency within the application itself. This is especially important if you decide to forego consistency with the host system for certain aspects of your application. Think about the rules and conventions that should apply, then apply them everywhere. Also consider the mental model your user will build of your application. Are the rules at work in this mental model always consistent?

Conclusion

You don’t need to make an application that looks like every other application. But you do need to make sure your application behaves the way the user expects. If you can’t use or mimic existing widgets, it’s better to look entirely inconsistent with the host OS, hence influencing the user’s expectations. Inconsistency can be a good thing: If your widget’s behaviour is inconsistent, make sure its look is inconsistent, too.

Don’t be visually consistent for consistency’s sake. Be consistent when it helps usability.

June 29th, 2008 / Tags: consistency, usability / Trackback

You really, really need to do Usability Tests

I often write articles where I complain about specific user interfaces. You should not believe anything I say in those articles. User interface design is nothing that can be reduced to a bunch of rules which create a good user interface if followed¹. User interface issues can’t be found by staring at an user interface and picking out the mistakes.

User interface issues can only really be found by doing usability tests.

Okay, admittedly there are some issues you can pick out by just thinking about an UI or trying it out yourself. It’s easy to see when an UI for a touch-based phone has buttons which are too small for a human finger. It’s easy to see that CS4’s MDI doesn’t work well with Exposé. However, fixing these obvious issues doesn’t give you a usable interface. It just gives you an interface without some of the most obvious issues.

Unless you find a bunch of “naïve” users (as in: people who don’t know your application) and put them through a usability test, your UI probably sucks.² Because you really, really need to do usability tests to find the issues in your user interface.

Why you need to do UI tests

So why can’t you just test the application yourself? Because you’ve either designed the user interface, or used the application extensively. That means you got used to its flaws. You won’t even notice things which will become insurmountable stumbling blocks³ for your users.

Here’s an example. This is a prototype for a (now defunct) social networking site. I did usability tests for this site about four years ago; we tested with German-speaking users, so the on-screen text is in German. I’ve removed parts of the image which are unimportant for the eventual usability error many users encountered.

A lot of thought was put into designing this page. Since people who wanted to log in typically had seen the site before and thus know how it worked, the site’s homepage was designed to be easily understandable for first-time visitors. It starts out with a short “About Us” section explaining what the site is all about, then it encourages the user to register. Finally, for returning (and hence experienced) visitors, there is the login form.

And yes, when we tested the site, first-time visitors could easily figure out what the site was all about and how to register. Unfortunately, they couldn’t figure out how to log in. The login form ended up being just below the bottom border of the screen, below the fold, and a lot of user never tried scrolling down. The designers actually anticipated this and put a “login” link at the top of the screen, but the text was too small and too low-contrast, so users never saw the link.

Even though these users were returning visitors, they had not yet learned how to use the site and could not figure out how to log in.

This simple redesign fixed the issue; after the color of the header was changed to be more prominent and provide more contrast, and the text size was increased slightly, all test subjects were able to log in:

As you can see, the designers of the site’s homepage actually anticipated most of what could go wrong and tried to fix it even before any tests were done. Yet they still got it wrong.

How to do usability tests

Hopefully I have now convinced you that you should do usability tests with your application. If so, surely you’re wondering how to do that.

First of all, this blog entry assumes that you can’t afford to hire an actual usability expert, and have no usability expert on your staff. If this is not the case, consult with them instead of reading this.

If you ask ten usability experts how to run a valid usability test, you’ll get about twenty different answers. The truth is, it really doesn’t matter too much, as long as you get users to use your application, get out of their way, and record all issues they encounter.

It’s great to have a usability lab with two-way mirrors and recording equipment. These things help a lot, and you can rent such labs in most larger cities. But you don’t have to! You can just sit somebody down in front of your computer, tell them which app to use, be quiet and look over their shoulders while they give it a shot.

Eventually, your guinea pig will make mistakes, become confused, or even get stuck. And if he does, don’t chalk it up to his stupidity. It’s always your fault.

How many users do you need to test?

If you’re going to rent a usability lab, it makes sense to test a few people each round - five seems to be the sweet spot, but in my experience you will find plenty of issues even when testing with only three users. An advantage of having more test subjects is that you can test different versions of the same user interface to see which one works best.

If you’re not going to rent an UI lab, it’s enough to test one person at a time. Even when testing with only one person, you’ll probably find a ton of things to fix.

Just don’t stop after the first round; keep going with new people until you’ve eradicated at least the most atrocious issues (and use different test subjects each round, of course - otherwise they will learn your UI).

How to choose testers

In my experience, it really doesn’t matter too much. While expert users are more confident with new interfaces and will be more likely to try different things, eventually figuring out how your UI works, they are actually quite likely to become confused by the same things as inexperienced users.

Even so, it’s a good idea to try your UI with a wide variety of users. There are some things which confuse certain types of users, but may not confuse others.

How to prep users

It’s extremely important that users don’t think they are being tested. Make sure to tell them that you’re not testing them, you’re testing your application’s user interface. Every mistake they make helps you improve the application.

It’s okay to explain what the application is all about. You should not, however, actually show them your application. At most, launch the application for them, but then, hand them the mouse and get out of their way.

Should I encourage users to talk?

Some users are more comfortable when they don’t have to talk. You should probably tell them that it’s okay to talk about what they’re doing, but don’t imply that they’re required to talk. You don’t want the user’s opinion of your application or its user interface. Instead, you want to know why he’s confused so you can more easily figure out what’s wrong with your application.

Task-based or freeform?

Typically, usability tests are based on a set of tasks testers want users to complete. While this is a valid way of testing applications, sometimes just letting the users figure out what to do by themselves can offer interesting insight, as well. You could also start out by not telling users what to do, and then guide them into doing specific tasks if they don’t do it themselves. It depends on the application you’re testing, and on what you want to get out of the usability test.⁴

How to observe users

First of all, shut up. It’s very tempting to guide your test subjects to the proper solution every time they hesitate. Don’t. After your application ships and is in your user’s hands, you won’t be there to guide them, so test subjects must be able to figure out how to use the application without your help. You should probably only help your subjects if they themselves announce that they have given up and require your help. Typically, you should only interact with test subjects if they request it or if they’re obviously stuck in a way they can’t get out again.

The key to good listening lab moderation is to stay quiet, except in those moments where intervention is necessary (Mark Hurst)

Second, your test subjects are not stupid. Yes, they will struggle with the easiest tasks. No, it’s not their fault, it’s yours. Keep telling yourself that: It’s your fault, and it’s your job to fix these issues. If one person doesn’t get something in a usability test, thousands of your users won’t get it after you’ve shipped your application! Think of the support cost you can save by fixing this issue once instead of answering all those support calls. Never assume mistakes are the user’s fault!

Third, if you can, you should record the session - the screen itself, what is spoken, and - if possible - the test subject as well. It’s useful to record the test subject because his facial expression and gestures will help figure out what exactly he was doing.

You will miss a lot of issues while the test actually happens. It’s important to keep track of what happened so you can go back and check out what issues the user encountered and what specifically triggered the user’s confusion. Also, modern usability labs may be able to do eye tracking so you can see what the user was actually looking at; this is tremendously helpful.

Sometimes, watching the recorded session together with the test subject can provide further insight on why something confused him (although users will often be confused as to why they were confused - if this is the case, it’s your job to figure out what confused them and how to fix it).

If you can’t record the test, at least make extensive notes while it is running. If you don’t, you simply won’t remember all the issues the user encountered during the test. In most cases, even if you don’t have any external way of recording a usability test, it should at least be possible to keep some kind of screen capture application running which can also record input from the computer’s microphone. Keep minute track of what happens during the test.

After the test

Sometimes, we give little questionaires after tests, asking users what they liked or disliked about the application, what features they expect from such an application, whether they would use such an application and if not, why not. These often make for interesting statistics, and sometimes provide additional insight into why users behaved the way they did during the test. If you’re doing a one-on-one test, you can do this in person. However, always leave this for after the test, never ask questions like these during the test; you will only confuse your users and distract them from actually using your application.

What to do with the results

Fix them, then test again. Most likely, your fix won’t be much better than the original UI. This is an iterative task. Find an issue, try to fix it, test the fix, repeat.

When to test

Simple answer: Whenever you change something which affects the application’s users, even if it doesn’t change the application’s user interface. It’s important to remember that users build a mental model of how your applications work, what rules apply inside the black box. Even if you “only” change something in the back end of the application, that change may break the user’s mental model, creating confusion and doubt.

What about existing users?

In certain cases, it may be a good idea to test new versions of your application with existing users of your application. These users will behave differently from naïve users; changes which are easy to understand for users new to your application may confuse existing users because these changes don’t match their mental model of your application.

Conclusion

The main thing I want you to take from this is that you have to test. You can’t do flawless user interfaces without testing. Even just sitting somebody in front of your application and observing how they interact with it can be tremendously helpful, bringing many potential issues with your application to light. Just don’t forget that it’s always your fault. Never blame the user.

June 22nd, 2008 / Tags: usability, use tests, usability lab / Trackback

MDIs on the Mac

Way back when the first graphical user interfaces were created, Apple and Microsoft went similar ways. Both used the desktop metaphor with files and folders, both had overlapping windows which showed documents and folder contents. However, they also took different paths for a few fundamental UI concepts. Apple had the “always on top” menu bar, while Microsoft put the menu bar inside windows. Apple went with an application-centric model, where each application could only be launched once but have many windows, while Microsoft went with a document-centric approach, where applications would sometimes launch multiple times.

The Multiple Document Interface — Apple very strongly went with the idea that each document corresponds to exactly one window, while Microsoft introduced a concept called the “Multiple Document Interface” (MDI), which allowed applications to have hierarchical windows: document windows reside under a parent application window.

MDIs have some advantages; they naturally help reduce clutter by grouping windows. They make it easy to hide all windows for a given application. If you tend to use applications in full-screen mode, having a MDI makes sure you really only see the active application and no other application.

Either way, Mac applications never had MDIs.

The times, they are a-changing

Mac applications used to have many windows. Recently, this has started to change, mainly due to Apple’s influence. Mac applications such as iPhoto, iTunes, iMovie, Aperture or iDVD tend to only have one window.

However, these applications do not have MDIs. Neither of these applications are multi-document applications. They are either media managers (iPhoto, iTunes, Aperture), or they are typically used to open only one document at a time (iMovie, iDVD).

MDIs on the Mac — Unfortunately, some companies have taken Apple’s new one-window-approach to UI design as a hint that they should introduce MDIs (or an MDI-like approach to UI design) on the Mac. Nolobe’s Iris, otherwise a very capable program, is such an application: Note the list of open images in the bottom row of the single window.

Adobe’s CS4 applications will also use MDI on the Mac (albeit only optionally - one can only hope that it will not be the default choice): Note the tabs above the image.

MDIs on the Mac are generally a very bad idea.

So why are MDIs on the Mac a bad idea?

Glad you asked. There are many reasons why MDIs are a bad idea; some of them generic, some of them due to how the Mac normally works.

Why MDIs are bad in general —

Please note that these lists are not exhaustive; also, not all of these points apply to all MDI applications. To name one example, Adobe has gone to great lengths to make sure their MDI would work around almost all of the issues in this list.

• Most modern computers support multiple screens, and a lot of people make use of this feature. MDIs don’t support multiple screens; since all of your documents are inside one window, you can’t put one document on one screen, and another document on another screen. Note that in the CS4 UI, it’s possible to pull document windows out of the main window, so this criticism does not apply.
• MDIs often make it hard to compare several documents belonging to the same application, or to view them side-by-side. CS4 supports tiled views to allow for this.
• MDIs make it hard to drag from one document to another inside the same application. In Photoshop, dragging layers between applications is something I do daily. MDIs make this hard (or even impossible, depending on the implementation), and force the user to copy-and-paste instead. Adobe’s CS4 UI supports spring-loaded tabs, which isn’t quite as good as direct drag-and-drop, but should be a workable solution.
• Some implementations of MDI make it hard to remove palettes from the main window. This is bad because in a multi-screen environment, a typical setup is to move all palettes to one screen, while keeping documents on the other screen. Again, the CS4 UI allows for this, so no complaints here
• MDI takes away space on larger screens. After your screen reaches a certain size, it doesn’t make much sense to maximize windows anymore. Having an MDI means you always waste space with a ton of application chrome around your documents - space which could be used by other applications running at the same time. Again, CS4 has a solution for this; hitting tab removes the application chrome (although I wasn’t able to get it back easily - hitting tab again did nothing at all). Unfortunately, the application chrome is not hidden if the application is put in the background while in MDI mode.

Why MDIs are especially bad on Macs —

As if these reasons were not enough, there are a few additional reasons unique to Macs:

• MDIs break Spaces. You can’t have one document in one space and another document in another space if all documents must reside inside the same window.
• MDIs (including tabbed browsers) break Exposé. This is what happens when you activate Exposé in Fireworks when the MDI is active:

Obviously, it’s entirely useless. This is what happens with the MDI turned off:

Much better.

By the way, Adobe, “zoom to fit” is currently broken and maximizes windows instead of zooming to fit their content - yet another Windows behaviour that has no place on the Mac. Also, the little “this document contains unsaved changes” dot in the close button does not work, which is probably another result of the MDI; UI elements don’t need to look the same in all apps, but if they look similar, they need to behave the same so as not to confuse users.

What Adobe did right, and what they did wrong — Adobe actually implemented workarounds for most issues I list. However, they are often non-obvious. Furthermore, if other applications with MDIs try to fix these same issues, they will most likely find different solutions, creating an inconsistent user experience.

Since there is no history of MDI applications on the Mac, and since Apple doesn’t have anything similar to these applications, there are no established UI guidelines. Hence, MDI-based applications confuse users since they behave inconsistently with each other.

Replacing an obvious, consistent solution to a problem with a non-obvious, inconsistent solution is generally a bad idea, unless the new solution is shown to be considerably better than the old solution (as an example for this, check out the Ribbon UI in new versions of Word for Windows - it’s non-obvious and inconsistent with other Windows apps, but it’s so much better than earlier versions of Word that the change is worth the issues it causes).

In this case, consistency with the host OS and its applications seems a lot more important than consistency with different versions of the same application.¹ In my opinion, the Mac version of Photoshop should look and (especially) behave like a Mac application, rather than like the Windows version of Photoshop.²

I should point out that I don’t have access to Adobe’s UI test results. One would hope that they did usability tests and found that the new UI is much more usable for Mac users than the old one before deciding to go with the MDI UI on all platforms. If so, changing to the new UI is the right thing to do.

Apple is to blame, too

Apple itself has at least one document-centric MDI application, too: Safari. The fact that Apple has an application which uses tabs to switch between several documents inside one window is probably partially to blame for the recent third-party enthusiasm for MDI apps on the Mac.

Originally, tabs were not meant to switch between documents. They were meant to organize “things” (such as settings) into groups of similar “things”, or - at most - to switch between different views of the same document. Not so switch between different documents.

It is kind of unfair to blame Apple for introducing tabs in Safari - after all, users demanded the feature, and Safari’s tabs are turned off by default (something other developers should copy if they insist on bringing MDIs to the Mac). It’s just very unfortunate Apple’s choice helped usher in a new era of MDIs on the Mac.

Conclusion

MDIs are bad news on the Mac because they break a lot of behaviours Mac users are used to. They should be avoided.

Addendum: John Nack replies to my blog post (scroll down to the comment linking to this post). He points out that most of my criticism of MDIs doesn’t apply to the CS4 UI since it’s possible to have (tabbed or single) windows outside the main window (Admittedly, I noticed this while trying the Fireworks prerelease, but actually thought it was due to a bug because I wasn’t exactly sure how I ended up in this state).

He furthermore thinks that it’s Apple’s fault for not giving developers a way of supporting Exposé for tabbed windows, with which I agree; still, Apple doesn’t force anyone to create interfaces which don’t support Exposé :-)

I’ve updated this post to reflect the fact that CS4 provides solutions for most issues MDIs normally cause.

Addendum 2: I mistakenly claimed that Final Cut Pro was a one-window application. This is false: I have not used FCP in a while and misremembered how its UI works. While FCP looks like a one-window application, the different areas of the UI are actually individual non-standard windows. Thanks to Ben De Rydt for pointing this out to me.

Addendum 3: Mike Lee, the world’s toughest programmer, disagrees with much of what I write, essentially saying that the concept of an MDI is not in itself flawed, but that it’s a question of context (how is the application in question used?) and implementation. He makes some good points, and furthermore calls me “chef,” so I recommend that you read his post. Also, who wants beef with the world’s toughest programmer? Not me!

I do have to take exception with two things he says, though.

He claims that it is false to differentiate between media managers and document-based applications. He does not, however, explain why this is false, except for pointing out that both Photoshop and iPhoto work with “media.” However, iPhoto is not a media manager due to the fact that “the documents in question are media.” iPhoto is a media manager because its main use is in managing your data. Faulting a media manager for having multiple documents in one window would be akin to faulting the Finder for allowing more than one file in a folder: In the application’s model, you are typically working with representations of your documents, not with the documents themselves.

Then, just after writing that “nobody likes Adobe,” Mike claims that I did not use Photoshop as an example “because people like Photoshop.” This is not why I used Fireworks. I went with Fireworks instead of Photoshop because I do not have access to a Photoshop beta, only to a Fireworks beta. The two share the same user interface, so any criticism I have made applies to both applications equally.

June 7th, 2008 / Tags: MDI, UI, usability, HIG, Apple, Iris, Nolobe, Adobe, Photoshop, Fireworks / Trackback

There Are No Stupid Users, Only Stupid User Interface Designers

If you’ve ever participated in a classic task-based usability test, you’re familiar with this. You’ve set everything up, given the user a task, and he’s started trying to figure out your user interface to get the given task done.

And invariably, one of your test users gets stuck and can’t continue. No matter what the tries, he just can’t figure out how to go on.

You stare through the two-way mirror while little beads of sweat start forming on your forehead. Is your interface really that crappy? First, the other users made all kinds of mistakes and took ages to finish their tasks, and now this one is genuinely stuck?

Eventually, you’re forced to lean forward, push the button next to the microphone, and tell the user “just click on the button with the ‘doohickey’ label. It’s at the bottom of the screen. No… further down… Yeah, that’s it. Click that.”

The user will look at the button dumbfounded for a second or two, but suddenly he’ll get it and announce that “ah, I should have seen that, I guess I was just being stupid!”

Ah, sweet relief. That must be it. Your interface is okay after all, it’s just the user being stupid.

No!

It’s a trap! Slowly step away from your keyboard and consider this:

Your users are never stupid. Sure, there are many users who may not be experts in using your application (or web site, or remote control, or door knob) - in fact, most users of your interface won’t be experts at using your interface. Even if your product is Photoshop and your users spend half their day inside your app, that means they spend half their day inside another app where they are taught all kinds of unsavoury habits.

It’s never your user’s fault. If one user gets stuck somewhere, you can bet your farm that others will face the same problem. Never accept “I’ve just been stupid” as an explanation for user failure. There’s always something you can do to fix usability issues.

May 30th, 2008 / Tags: usability, dumb, ui test, two-way mirror / Trackback