Any user experience researcher who has been on the job for more than five nanoseconds is an expert in discoverability. You have to be. One of the problems that any large application (and most small ones, for that matter) have is that they’ve built in some really cool and useful functions, but they’re buried somewhere. All of the work that we’ve put into a cool new feature doesn’t do anything for our users if most of them can’t find it. In a Windows environment, it’s all too common to find functions that are only accessible by the contextual menu (the menu that pops up when you right-click). Thankfully, Mac developers are generally (although not always!) in the habit of assuming that a user only has a one-button mouse and doesn’t know how to control-click, so they tend to stay away from contextual-only features.
When I’m in a usability lab with a user, it’s easy to figure out discoverability issues. If I can’t determine what the problem is just by watching them, I can ask them questions. They might not be able to put their finger on the problem, but it’s my job to be able to identify it anyway.
My usability lab isn’t the only way that we get feedback about our products, of course. There’s the newsgroups and the product feedback page, there’s meeting someone on a plane, there’s informal conversations at the upcoming WWDC. Sometimes, when I see this feedback, it’s hard for me to discover the issue. You see, discoverability is a two-way street: if I can’t discover what the problem is, I can’t do anything to fix it. Anyone on our test team can tell you how frustrating it is to get a bug report that doesn’t include all of the relevant details and reproduction steps. This is true for what I do as well. It’s frustrating to know that you have a problem, but that I don’t have sufficient information about it to figure out what to do about it.
Oftentimes, we can figure it out anyway. One recurring piece of feedback that I have noticed from our product feedback website is about Remote Desktop Connection. In fact, here’s the complete text of one user’s feedback:
resizing the window is pretty much a necessary feature to be able to use this app.
The user is entirely right. If my memory serves, the default screen size for RDC is 800×600. The default behaviour for RDC is that the screen is not resizeable. But we knew that users often have larger screens than 800×600, so we did provide an option for changing it. Sadly, there’s a discoverability issue in our original implementation: finding the option to change your screen size is difficult. (If you don’t know how to do it, open RDC but don’t click on the Connect button. Then click on the disclosure arrow next to Options. Then click on the Display tab. Finally, select your preferences on that panel: the size of your remote desktop, whether you want the window to be resizeable, etc.)
Not all of our one-line feedback is this easy to figure out. I know exactly what you mean when you say ‘add webcams’ or even ‘why can’t I wink?’. But sometimes it is. Here’s some more RDC feedback:
Make an option to change the password
There’s two possibilities here. When the user first set up RDC, they could have entered a username and password for the remote system. Sometime after that, their password on the remote system changed or expired, but they can’t figure out how to change the setting in RDC so it’s now sending the new password. Alternately, they want to use RDC to change their password on the remote system, and don’t want to do it (or don’t know how to do it) on the remote system. If it’s the former issue, it’s the discoverability issue that we already know about. If it’s the latter, it’s a feature request for RDC.
So I’m asking you to make my job of discovering what you want a little easier. If you submit feedback to us, please make sure that someone on the other end can figure out what you mean. I’m not sitting next to you (unless you happen to sit next to me on the plane or buy me a drink at WWDC), so I might not know what you’re talking about. If you want a feature that’s just like your favourite part of another application, make sure you tell me what that other application is. If you think you’ve found a bug, include everything that you can possibly think of: OS version (don’t say Tiger, let us know if you’re using 10.4.7 or 10.4.2), application version, other important details (such as connecting to an Exchange server from Entourage), and what you did when you got the problem. If you want to say Nadyne rocks, you can give lots of details, but really, ‘Nadyne rocks’ is sufficient.