Empower Users When Things Go Wrong
In an ideal world, applications would never have errors or those errors would be handled gracefully by the application so the user would be none-the-wiser. Unfortunately, that isn’t realistic. Many applications rely on data from external sources which cannot be guaranteed. Additionally, there are times when the user needs to make a choice of how to handle the error.
Here is an example of a situation where Chrome is detecting a problem with a website.
Chrome smartly prevents the trouble application from freezing up the browser and even goes a step further. Users are told what the problem is, and how to correct it. This is great; it prevents that feeling of helplessness that can occur when you are told there is a problem you don’t understand without any clue as to how to correct it.
One way this particular example could be improved even more is by immediately giving users the tools to take those actions. The suggestion given is “Clearing your cookies for this site or allowing third-party cookies may fix the problem”. If there were buttons/links to do just that, then you’ve saved the user the time to hunt around for how to perform the action you’ve just suggested.
Blaming your users when your product doesn’t work right is like blaming physics when you fall on your ass.”
Emphasize The Product, Not the Process
Zynga recently added a new feature to their popular Words With Friends game: the “Words With Friends Store”. It is not a store for buying Zynga merchandise or Words With Friends apparel; rather, it is somewhere to make in-app purchases of additional content for the game. The content currently consists of a couple features to help people improve their gameplay: a Word-o-meter that tells you how strong your words are, and something they call “Tile Pile” that tells players how many of each letter is remaining.
I applaud Zynga for making a great business move. Based on the number of “cheats” apps out there, we might assume there is some demand for help winning the game. They are opening a new source of revenue among their huge existing user base.
One suggestion I would like to offer is to rename the “Store” so that it aligns more closely with the users’ goals, and less with the company’s. While Zynga is clearly selling something, users are not thinking to themselves “Wow, I’d like to buy something today”. What they are thinking is “I wish I could keep track of how many tiles are left” or “I wish there was a way I could win more games”. They may even be thinking “I wish this game had more features”. Based on that, I would suggest calling it “Words with Friends Add-ons” or something similar. People will still be spending money, but then they will be thinking about what they are getting, rather than what they are spending.
Persuasive Design. Signs for the trash receptacles at Ipsento Coffee Roasters give a subtle reminder of where the trash is going.
Redesigning the Ticket Purchase Experience
The process of buying a ticket to a concert has only marginally improved in the last decade. I certainly have fond memories of being a teenager standing in line at a Ticketmaster outlet in the 90s, waiting to see who the lottery would place at the front of the line. However I am grateful that nowadays I can just go online to make that purchase and avoid wasting an hour sitting around. Unfortunately, nowadays I still may have to waste an hour or more re-trying my ticket purchase or waiting in an online waiting room. An online waiting room in the days of Tivo! We aren’t supposed to have to wait on anything.
I’d like to propose a paradigm-shift in the process of buying tickets online. To start, don’t force anyone to log in to a web site when tickets “go on sale”. There is no reason to require anyone’s physical (or online) presence at that specific time. All the decisions that need to be made can be made ahead of time. Once a show is booked, people should be able to login, set their payment information, and select the tickets they’d like. Then, when tickets “go on sale” just shuffle the hundreds, or thousands, of potential purchases and place them in that random order. After all of these pre-orders have been filled, then allow spot purchases from people.
It is possible that some complications could arise. For example, the section chosen by a purchaser may sell out although they would be willing to buy from a different section. It should be trivial to assign some simple rules for the purchase. “I need 4 tickets. They must be in section X, Y, or Z. Total cost must be under $XX.” These are the thoughts people have as they are buying anyways, but instead of planning it all out ahead of time they must constantly refresh the screen and modify their query. It’s nonsense. The computer is acting only as a communication tool when instead it should be a facilitator.
Not only would allowing potential preorders make it less of a hassle for people, but it would open access to these tickets to people who formerly could not be available at the on-sale time. Additionally, because priority is now assigned randomly, a greater variety of people will be able to attend the show. Finally, it would reduce the need for technology to handle the huge surge in connections that occurs when a show goes on sale.
Remove this hassle to buying tickets and you will sell more tickets. I guarantee it. (And Ticketmaster, this may even stop the next generation from hating you as much as the last.)
Customers will be unable to sync their music over the air for 90 days if they accidentally set up iCloud with the wrong Apple ID and need to change it later. This seems like a harsh penalty for doing something that was extremely unclear. Apple could have done a better job preparing people to move over to iCloud from MobileMe.
Inverted Monthly Calendar
Would an inverted calendar, in which the rows are the days of the week and the columns are the weeks, be rejected by users? Why or why not? Does anyone have any examples of this usage in the wild?
I don’t think everyone has the capability of responding to this on tumblr, so I copied the question to StackExchange.
Facebook Modal Dialogs
In Facebook’s “App Settings” page, there is a three-step process that we could redesign down to a single step using some interaction design principles. The goal of our user in this case is to remove an application. This is the current process:
1. Click the “X” in the row of the application.
2. A modal dialog appears asking if the user is “sure” he or she wants to delete it. The User must click “Remove” to confirm.
3. Several seconds later, another modal dialog appears. Now the user must click “Okay”. The action has already been performed at this point, so the only point in clicking “Okay” is to dismiss the dialog. It is possible to interact with the main page while the unmovable dialog is present, but until it is dismissed, the application that was removed remains in the list of applications.
When designing interactions, we should be aware of which tasks directly contribute to the goal, and which are extraneous, and remove those that are extraneous (what Alan Cooper calls “excise”). In this particular process, the only task that is absolutely necessary in order to accomplish the user’s goal is clicking the “X” to remove the application.
Asking for confirmation is unnecessary. Users are not stupid. We do not need to ask them to confirm everything they’ve asked us to do. It is a rare case that a user clicks the delete button unintentionally, but that can be accounted for in an unobtrusive manner. Simply implement “undo” functionality. Google calendars does this very elegantly when a user deletes an event.
In a single notification, Google Calendar has notified the user that the action was successful, and give the user the capability of reversing the action in case it was an error. Nothing is required of the user. No dialogs need to be dismissed.
My recommendation for Facebook is to remove both the confirmation dialog and the “success” dialog, reducing the process to just clicking the “X”. Then remove the application from the list and display a non-obstrusive alert that the action was successful with the option to undo.
Facebook Privacy Bug
Today, as I occasionally do, I went into my Facebook privacy settings to make sure nothing had been changed recently and to make sure I am aware of what information of mine might currently be shared. One thing I hadn’t noticed before is that there were dozens of applications and websites authorized to access my Facebook information. Some of these are websites that I do currently use, like Foursquare, but some I had never even heard of. I decided to just delete them all for now and I could reauthorize them as I use them. That is where I ran into a problem.
There are actually two problems here. The first is what I can only assume is an implementation bug. As you can see in the screenshot, the “Turn Off Platform” button is disabled. After selecting one or all of the applications to de-authorize, it remains disabled, and there is no clear instruction on how to enable it.
That brings me to the second problem. Whenever there is something a user needs to do as a prerequisite to what they are trying to accomplish, that must be made clear to the user. There should be instruction on how to get this thing to work. Additionally, it would be helpful to have a message displayed when I try to click the disabled button that explains why I cannot proceed. Without that, we just end up with a confused, unhappy user. This is even more important in this case with all of the controversy surrounding Facebook’s privacy policies. The last thing they need is a user thinking that they are intentionally preventing them from removing the apps and websites with access to their information.
Garmin’s Birth Date Selection
On Garmin’s Connect website, a calendar widget is shown to select my birthdate. Considering the amount of clicks it takes to get to the year, a simple text box would be a better choice on this finely crafted website.