When should design trump usability? Can a pretty site be a little less usable if it’s extra beautiful? Or is that always a no-no?

In traditional desktop applications, it’s a common rule of thumb to not hide functionality behind things such as right-click menus, but to expose them more generally through a top level menu or toolbar. Sometimes in web design, web sites themselves can have a learning curve. It may not be immediately apparent how a site works or what to click on. Its learnability may be a little lower in order to accommodate a slicker design. The web site simply becomes less intuitive. Hyperlinked images start looking like regular images and text hyperlinks start looking like regular text until the mouse rolls over it. That’s negative points in the world of user experience.

The actual level of usability needs to be considered too. Preferably your web site is not just usable, but competitively usable. Users should prefer to use your website rather than someone else’s. Since the iPhone has been out a while now, some people have come to realize that on-screen keyboards aren’t all they’re cracked up to be. Even though it is beautiful to behold…

you just can’t beat the tactile response of a hardware keyboard…

So when do you go with usability rather than a beautiful design? Or is beauty sometimes enough to compensate for a less than stellar user experience?

What’s the best way to balance innovation and convention? creativity and expectations? novelty and normality? When you have a good idea to improve the UX of your product when do you choose to use that rather than stick to what users are used to seeing? If you don’t have the option of doing user research and putting this in front of real users’ faces, what do you do?

I’ll start off with a story. A couple months ago, another developer and I came up with a fairly innovative way to improve how we do filtering in our product. This product hasn’t been released yet. We have other products that do similar things, but our product is completely new… unreleased… so this is time to improve it and try new things, right? So we bring our idea into one of the UI review meetings we have every week, and well… let’s say things didn’t go as planned. We heard comments ranging from "why is it changing?" to "what’s wrong with the old way?" to "this is completely unusable". Mind you, no one there had any real data either. They were just stating their opinion. We had several use cases where our method was superior and more powerful than what the product currently had, but that didn’t matter. They couldn’t see the value in the new paradigm we introduced.

In Observing the User Experience, Mike Kuniavsky talks about a company "Bengali" and their cutting edge, question all your assumptions, state of the art product "Typhoon". Typhoon was supposed to be the next generation web site. A revolution in the industry. The product that sets the standards in the coming age. The problem is that it didn’t follow any current conventions or standards or anything else that users of the day were used to. Worse yet, Bengali didn’t do any usability research until it was too late. Only then did they find out that users didn’t know what to do with it. It was too cutting edge… too revolutionary… too new.

In our UI review, it was pointed out that the filtering mechanism we have now works well and that people are used to it. And that’s a completely valid point. "If it ain’t broke, don’t fix it", right? But that just leads to uninspiring, stale products. Nothing really new ever gets created. So when do you innovate and when do you stick to conventions?

I conducted an initial test run of a card sort today for my Twitter client Bitter. A card sort is a usability technique in which you hold sessions with potential users of your application and you, well, have them sort cards. Each card will contain a label used in your application. In an open card sort, the users will create groupings of cards themselves and name each grouping. In a closed card sort, the users will group the cards into the group names you provide them.

If your application is a web site, a card sort could help you organize the pages and links that belong under each section for your site’s navigation. If your application is a traditional desktop app, a card sort could help you organize the menu items under a top level menu. For my card sort, I used the labels from my options dialog (and even some potential future labels I plan to add) and had the user sort them.

I expected to end the card sort session with several groupings and have a better idea of how others may view the labels. I did indeed end up with that, but discovered several other things in the process that I didn’t expect. There were a couple assumptions I had made about how the options were to be used with the currently logged in user and the card sort showed me that those assumptions may not necessarily be made by other users.

Another thing I found was that you need to carefully think about and decide what to put on your cards. You have the choice of simply putting the label on the card, or you can put the label and a description of the label on each card. If you put just the label, then you’ll likely have the same problem as me of context-sensitive labels. For example, I have some labels named “New Tweets”, “New Replies” and “Sent Direct Message” among others. By themselves, you aren’t quite sure what they refer to, but once you see them grouped under the “Sounds” section it becomes more obvious. So should the cards stay pure and say precisely what the label will say in the application or should you muck with your independent variables and change the cards to include context like “New Tweets Sound“? That’s something you need to weigh the pros and cons of and determine for yourself and also probably consider when analyzing the results of the card sort.

Also, let your participant talk during the session. Let them ask questions. All this is valuable information. You can then ask yourself why the participant said this or that or why they asked what a certain card meant. You may think the answer is obvious, but maybe it’s not. But if they do ask you what a specific card means, ask them what they think it means. That’s yet more valuable information.

It’s also a good idea to video record the whole thing. It’s impossible to take notes and get everything during the session. Also sometimes you’ll see things on the recording that you didn’t see during the session. Just make sure you get permission first.

Overall, even though this was just an initial test run of a card sort, I can already see the benefits. I did this run through to see what works and what doesn’t work and now have a pretty good idea. If you are writing an application whether in your own free time or professionally, a card sort is a good idea. It doesn’t even have to be formal. Asking a coworker to take a few minutes and come over to your office for a quick card sort would work fine. Often times we just get so close to our applications, that we lost perspective. We get tunnel vision on how it’ll be used and how things will be used and interpreted. A card sort is simply a tool to get other perspectives and to rid yourself of tunnel vision.

Scott has been receiving emails from Sprint for several months now. The emails are kind and courteous and they thank him for his payment. They’re in plain text, no links. It’s not spam. It’s a real email from Sprint. The problem is that it’s not for Scott’s account. The emails are intended for another Sprint customer, but are for some reason being sent to Scott. Scott emailed Sprint’s customer service about the situation, but armed with only Scott’s email address that they had been sending payment receipt emails to, they just couldn’t figure out who should actually be getting the emails.

So Scott and I decided to set out and see what we could find out from just the email address. First, we went on to Sprint’s site and saw the login area of the webpage:

The "forgot username" link looked inviting, so we clicked there. Now all we have to do is enter the email address:

Email address entered and sent. Shortly afterward we received an email with the username. Success! But wait, what’s this? The email conveniently contained a link to the forgot password page:

Ok, Sprint, now you’re just making this too easy. We entered the email address and username and then received another email with a customized link to set a new password. Yes, that’s all it took. We now have full access to this guy’s account and all because he put in the wrong email address. We’re nice guys and all, so we logged out and sent an email to Sprint with the username to see if they would finally rectify the situation.

So here’s the question of the day: Is Sprint’s site truly secure? Should an email address really be treated as the key to the kingdom and allow anyone with access to the email address access to everything else? Shouldn’t at least one security question (no matter how secure (or insecure) they actually are) have been asked somewhere in this process? The concept of security and usability being at odds has been floated around a lot. Making something more secure tends to make it less user friendly and vice versa and while everyone wants their web site and application and product to be as easy to use as possible, security simply shouldn’t take a back seat.

In a world where multi-factor authentication is readily available, something like this just shouldn’t happen. There are plenty of different one time security tokens (some with screens and some that act as virtual keyboards), finger print scanners, and many other solutions that are orders of magnitude more secure than a password (especially passwords with an email address backdoor).

So when you’re designing your next web site, or web application, or regular desktop application, stop and think through all the different avenues that deal with authentication and security. Think about what can be done if an attacker has only one authentication factor, or if an attacker gains control of the email address associated to a user’s account, or if an attacker figures out one or more answers to your security questions. Are you comfortable with what the attacker can or cannot access? Is a little loss in usability and ease of use worth the extra security to prevent these sorts of attacks?

What scares me is that had Scott and I been not so nice of guys, we could have signed this poor sap up for Sprint’s Family Locator service and tracked him and his family right on their web site:

Now tell me how secure that is…

I’ve been thinking about how to do this recently with Bitter. When you have an update for your application that you want your users to have, how should you push it down? I see four distinct levels of updating:

Manual Check and Web Page Download

You can require the user to manually go the web page, check for a new version, download it and copy it over the old application. This is obviously the worse way to go from a usability perspective, but also requires little to no work for the developer (other than packaging up the new version). This is probably ok for applications that are seldom used, not popular, or maybe only for a select group of users, but not ok for anything other than that.

Automatic Check and Web Page Download

In this scenario, the application would automatically check for updates and alert the user of such, but would still require the user to actively download and “reinstall” the application. This only requires the application to download a file stored on the file that contains the currently released version number and compare it against it own. The developer would also need to manage the version number file and update it accordingly. Not difficult to accomplish and it gives you a little more bang for your buck.

Automatic Check and Automatic Download

With this version, the application would both check and compare the versions and then would automatically download the new version of the application with the user’s approval. It may also even copy the application in place over itself and restart the application. This is what I’ve currently done with Bitter as I document in this post. This is still not that hard to accomplish. In .NET, I showed that doing this is only about 10 lines of code of any real meat (not counting exception handling, logging and message boxing).

Automatic Check and Automatic Install

Here the application automatically checks for updates and automatically installs updates. No user intervention required or possible.

So what’s the best way to go? With Automatic Check and Automatic Download, the user still has to tell the application to download and install the updates. It’s up to the user. In Automatic Check and Automatic Install, the user has no choice. He is going to get the update or he ain’t running the application.

One of my new favorite applications Digsby, uses the Automatic Check and Automatic Install approach. When you login, it will check for updates and automatically install them. You don’t have a choice. This is good because the user doesn’t have to do anything special. They will always be up to date. This is good for the developer too, since the developer knows that if you are running the application you will have the latest version (or at least the next time you start). But what if you don’t want the update? It’s not uncommon for developers to introduce new features as well as new bugs into an application in an update. If you know about the new bug introduced in the next version, but need to login, what are you going to do? You don’t have a choice but to accept the update, get the bug, and hope another update with the bug fixed will be coming soon (and hope that no other additional bugs will be introduced as well).

On the other hand, if you don’t force updates, your user base could become this heterogeneous mixture of versions that you have to support and that your website has to support. If version 1.0 is checking for updates in a certain path, but the current version is checking for updates in another path, you either need to support both paths for an indeterminate amount of time or just let v1.0 break. Not only that, but users running older versions might request features that are already fixed and they have no real obligation or motivation to move to the next version. They could stay there using v1.0 until our insect overlords come and take over. Is that ok (the versioning thing not the insect thing)?

One more facet to consider with support is that businesses typically want to test Windows updates before deploying them across their organization. This often means that organizations and the multitudes of computers behind them can be several versions behind the current one in whichever OS they are using. If this describes the situation of your application, then the decision is already made for you. No auto updating otherwise your application will be passed up for another that does allow less-automatic update installation. However, most of us (thankfully?) aren’t in that category.

Arguably one of the best if not the best free Photoshop-like applications out there, Paint.NET, does not force you to update. It shows you that an update is available when you start up the application and you can check for updates through the menu, but you aren’t forced to update. And you know where it’s gotten them? I’m running version 3.10 on both of my home computers even though the current version is 3.31. I’ve seen the update dialog for months now and still haven’t installed the update. I’ve not intentionally not installed the application, it’s just that the version I have seems to work fine and I really don’t know how much trouble it will be or how long it will take to install the new version even though I’ve never tried. I simply don’t want to be bothered with it.

Where does that leave us?

The Automatic Check and Automatic Download method gives the user more control and keeps the user in the loop, but… it keeps the user in the loop. Most users don’t care about versions, they always want the latest. That may mean that we should use the Automatic Check and Automatic Install method, right? But doing that will piss off the 1% of users that actually want to control their versions let alone the business users. And what’s worse is that this method is all or nothing. You can’t let most users automatically update and then let other users choose which version they want. If that’s the case, then you’re automatically back in the Automatic Check and Automatic Download way of things with the support troubles and versioning nightmare.

So what’s it going be? Should you just cater to the common case or do you want to attempt to make all your users happy?

In my quest to make my Twitter client Bitter as easy to use as possible, one upgrade I had considered was making it auto-updateable. You click a button, it updates. Done.

As most things in .NET, it turned out to be relatively simple. You download the file, you move it on top of the running app, you restart… all neat and tidy. So without further ado, here’s the code:

private void UpdateApplication(string applicationDownloadURL)
{
    string downloadedFilePath = System.IO.Path.Combine(System.IO.Path.GetTempPath(), “bitter.exe”);

    // download the exe
    bool shouldContinue = true;
    try
    {
        WebClient wc = new WebClient();
        wc.DownloadFile(applicationDownloadURL, downloadedFilePath);
    }
    catch (Exception ex)
    {
        shouldContinue = false;
    }

    if (shouldContinue)
    {
        // get running app path
        string appPath = Application.ExecutablePath;

        // copy over running app
        try
        {
            // create archive’s app path
            string archiveAppPath = appPath + “.old”;

            // delete any old archived apps, archive the current app
            // and move the downloaded app in place
            System.IO.File.Delete(archiveAppPath);
            System.IO.File.Move(appPath, archiveAppPath);
            System.IO.File.Move(downloadedFilePath, appPath);
        }
        catch (Exception ex)
        {
            shouldContinue = false;
        }

        // restart the app
        if (shouldContinue)
        {
            Application.Restart();
        }
    }
}

Of course you should add logging and user feedback where appropriate. This is just skeleton code that gets the job done. Enjoy!

I’ve developing my Twitter client Bitter for some time now. A small group of close friends have been alpha testing it for me for quite some time, reporting bugs and enhancements along the way. I’ve been tweaking things for quite a while now and feel like it’s time to go on to the next stage. Things eventually come to a point where enough is enough and you’ve got to release! Well, I’m not quite there yet…

Today begins the extended usability testing of Bitter in the form of user diaries. A user diary is basically a stream of thoughts that the user has as they are using the application. It’s a list of their real-time, unfiltered thoughts, impressions, suggestions, enhancements, weird experiences, bugs, and even feelings they have while using the application. The entries can be as big and descriptive or as short and small as the user wants. There’s no real format. Just a straight brain dump onto paper.

So what exactly is happening today? Today I sent out the release candidate of Bitter to my volunteer group of usability testers. I tried to get some old, some young, some experienced Twitter users, some noobs, some developers and some not-so-technical users. A wide variety of testers is best especially in usability testing. Not everyone has had the same experiences using software and so everyone comes in with a slightly different (or maybe even vastly different) viewpoints on how things should work. I’ve already seen a few issues while helping a less technical person sign up for Twitter and start using Bitter.

Anyway, I’ll post the outcome of all this in the near future and some lessons learned with my user diary process. Stay tuned…

I know you’ve probably heard this before, but it bears repeating: set the default options for your application how most users will want them. Do not expect your users to go into the options and tweak them. They won’t do it. And don’t think that normal users won’t care, but advanced users will go in there and change them. They probably won’t either. Just think of all the applications you use and think of how many times you’ve tweaked the options. I know I very rarely do. Just a couple in Firefox, one or two in Visual Studio. That may speak to how well their default options are, how I simply didn’t know that I could change that option or how I just don’t know where to look. In the sea of tabs, combo boxes, and check boxes, how are most users (let alone most users’ mothers) supposed to know where to look to make cookies work or change the default formatting when replying to emails or keep iTunes on top of all windows?

I experienced this first hand tonight. My brother-in-law recently bought a new Toshiba laptop, all nice and lightweight and filled with memory that’ll never get used. Since he bought it last week he hasn’t been able to login to various sites including eBay, his bank and some other sites. Interesting isn’t it? A new computer shouldn’t have any problems like that. So we went over to their house tonight and I take a look. We open it up, I bring up eBay and the homepage shows fine. “Wait til I login” he says. Name, password, submit…

Sounds simple enough, right? I need to mess with the cookie settings. Ok, cookies, cookies… where were those again?

Lucky for me, I know that the privacy tab configures how the browser handles cookies, but my brother-in-law didn’t. He’s a pretty average user: definitely not as ignorant as my grandma, but he’s no developer either. He very well might have known where to look, but in this case he didn’t. He’s never needed to before.

Would you have known? Have you ever customized your privacy options? I always tell myself I should, but I never have. What’s there works and I’ve never had any problems… famous last words, huh? His computer for whatever reason came with all cookies being blocked by default. Sure it’s more secure, but it’s by no means usable and would never be fully usable by him until he got it reconfigured.

So why did it come so locked down? Did the OEM fall into the trap of thinking that users always customize their apps? I don’t know. But you should know better than to think this. As Jeff Atwood said:

For most users, the default value is the only value.

So always install your applications thinking that the options will never be touched again… because they probably won’t.

Should you ever allow a "Miscellaneous" category or section or tab or page in your application? When dividing your data up into different sections, do you always have a place for everything or do you have a place for most things and then everything else goes into the catch all "Miscellaneous" section?

Some applications use "Configuration" or "Options" to try and solve this problem. Visual Studio 2008 uses a "General" section:

"General" is not quite miscellaneous, but almost. These options don’t really seem to fit in the other subcategories of "Edit and Continue", "Just In Time", "Native", or "Symbols". So that at least seems to mean that they need their own section.

Firefox uses the same pattern in their Advanced section:

These options are at least grouped into sections, but they still don’t seem to fit into any of the other categories.

Outlook 2007 on the other hand has an "Other" tab:

This may as well have been called "General" as well. There’s no rhyme or reason as far as I can tell for the sections inside of "Other".  Looks like another case of "Miscellaneous" to me.

In the fields of Information Architecture and Usability, a method known as card sorting is used to have potential users sort terms and labels according to how they would logically group them, in whatever order that might be.

In many cases, the users have a leftover category that they might simply label "Miscellaneous". Is this ok or is this just another usability issue to deal with and redesign later? Should "miscellaneous" never ever be allowed? Does inclusion of a miscellaneous category mean that your data isn’t organized in a intuitive way? Or will inclusion of a miscellaneous category just lead to users hunting around all the similarly titled sections until they finally check miscellaneous?

Or is that just too much of a Platonic ideal? Are there times where some fields simply don’t fit anywhere else? At some point do we need to throw up our hands and allow the wave of meaningless titles and labels flow?

When you sit down to design a user interface, where do you start? Do pull up Visual Studio and start creating forms and dragging controls onto them? Do you go talk to the server guys to see what they need and then just go for it? Or do you wait until the design phase is done and then create a dialog for each class in the system? Doesn’t sound pretty, does it? Well, have you ever pushed away the keyboard and pulled out a pencil and paper? Believe me, I’m no fan of the old school input methods (I can barely read my own handwriting), but there may be some use for that dead tree after all.

With paper prototyping, you can design user interfaces (graphical or even hardware) and get real life user input about the usability of that interface without ever touching the mouse. Basically, the drill is to draw the different states and dialogs that your UI contains on several pieces of paper and then observe as users interact with them. During the session, a person playing the role of the computer puts down the appropriate pieces of paper as the user physically touches and interacts with UI, so that the paper prototype acts as the real application would… just in ink or graphite. Nothing in the UI (layout, navigation, etc) is the explained to the user beforehand. The user is simply given a task and is asked to perform the task on the paper prototype.

Right now, you might be thinking “Well, what the heck can you learn from this? It’s only paper!” That’s true, but the fact that it’s paper is key to the whole operation. The prototype only takes as much time and effort to develop as it takes for you to draw the dialogs. On the paper, the user can physically touch the buttons, links and other clickable controls and can even write character input into the appropriate controls. Better yet, the paper prototype can be quickly refined to fix discovered problems with the interfaces… sometimes even during the session itself! “We saw you had problems finding the place to input the name. Would you try it again with *this* prototype.” How cool is that?

So what sorts of problems can you really find from some scraps of paper? Well, let me tell you, dear reader:

Confusing UI and concepts

There are times when you really don’t know how to express your interface so that the targeted users of your application will be able to easily grasp and use the interface. Or worse, you may think that you have the interface nailed down… except that you don’t.

Maybe you think that adding an object by choosing the type of object and then clicking the “Add” button followed by configuring the object is a perfectly reasonable set of steps for the task at hand. Well, your users may disagree. Heck, your users may not even be able to find the dialog to add the object in the first place. They may even be “clicking” the options link in the upper right corner over and over because they’re sure that’s where they need to go to add the object. Acting this all out with a paper prototype will find that out.

Important pieces and not so important pieces

Sometimes you may think that a certain feature is really important. You’re positive that the user will have to have this flashing red spinning textbox. The interface just won’t make sense without the flashing red spinning textbox. You get to the paper prototyping session and the user doesn’t even touch the flashing red spinning textbox, but they keep commenting on how great the dull boring toolbar is. Now you know where your spend your valuable time.

Weird words and wrong words

Are you using terminology appropriate to the domain as well as words that your users actually know? Have you ever put “VOIP” as a label in a dialog and your users thought that it meant the Teen Girl Squad sound effect instead of Internet Telephony? I know I have…

But do you know what the best part about paper prototyping is?

You get all the bugs out of the way before you write any code at all!

Well, ok, not all the bugs, but a fair amount of them. You’ll have confidence that can be backed up with real data that your interface will, at the very least, not suck. Any improvements that need to be made after releasing the application should be minor adjustments… assuming that you’ve paper prototyped all the new features that crept in along the way too.

To get your feet wet in paper prototyping, check out PaperPrototyping.com, A List Apart and of course Jakob Nielsen’s Alertbox. To get your feet soaking and all prune-like, buy the book.

UPDATE: To see paper prototyping in action, check this out.