Designing Interactive » User Experience

This blog has moved…

Josh Walsh — Fri, 17 Dec 2010 19:17:30 +0000

… but we love having you as one of our readers.

Since we’ve started this blog, it’s grown and grown. It’s grown to a spot where it deserves it’s own resources and domain. We’re working hard to create better content than ever before, and we hope you’ll continue to follow us over here:

Please update your feed-reader to use the new RSS feed:
http://feeds.feedburner.com/mfp

Join us at:
http://www.madeforpeople.net

Poor Internal UX Design Causes Zappos $1.6 Million

Josh Walsh — Wed, 02 Jun 2010 19:53:10 +0000

A great case study which proves why you should invest in the user experience of your internally facing applications, not simply the customer facing ones.

Zappos.com CEO Tony Hsieh

We have a pricing engine that runs and sets prices according to the rules it is given by business owners. Unfortunately, the way to input new rules into the current version of our pricing engine requires near-programmer skills to manipulate, and a few symbols were missed in the coding of a new rule, which resulted in items that were sold exclusively on 6pm.com to have a maximum price of $49.95.

This isn’t the first time this kind of thing has happened. Remember the 52″ flat-screen TV on sale at BestBuy.com for $9.99?

Forgiveness

Josh Walsh — Wed, 26 May 2010 18:04:33 +0000

By Joshua Brewer at 52 Weeks of UX

Humans are inherently prone to make mistakes. We do it all the time. Misreading some copy and clicking on the wrong link. Searching for something that doesn’t exist. Entering in a URL that we mistyped. Attempting to engage with an interface in a way it was not designed for. All of these examples (and thousands more) happen all the time with our products.

It is this moment in which we have a unique opportunity to engage our users in a genuinely human manner. We have just interrupted their workflow and they may or may not be able to accomplish the task that the software is supposed to help them perform. So often, when an error occurs users will often blame themselves and, unfortunately, because we give little to no help, they continue feeling like they have made the mistake.

[...]

We failed, not the user. After all, they are using our product. We are responsible for the experience and by admitting there was a problem and attempting to fix it as quickly as possible, we will engender the goodwill and hopefully, the return business of the user.

All the cool cats are “#UX Designers”

Josh Walsh — Thu, 29 Apr 2010 17:33:48 +0000

Designing the user experience is not a new idea. There have been people thinking about it since the invention of the wheel. The problem is that now it’s hip to be a “UX designer.” It’s marketable.

People ask me how to sell UX to their customers. You shouldn’t have to. People don’t come to you and say “design me something that’s hard to use.” Their request for design implies usability, just as your service implies usability work.

Now “UX” is exploited as a way to make more money. It’s another line item on an invoice. Deplorable.

Satisfy the Cat, a.k.a. User-Centered Design

Josh Walsh — Tue, 27 Apr 2010 00:18:04 +0000

As a designer of websites, I have to make jolly-well sure that I satisfy the cat first, remember that I’m not a cat, and find ways to play on the cat’s own motivations. Only then does everybody win.

By: John Boykin

Design For People

Josh Walsh — Tue, 20 Apr 2010 13:53:48 +0000

When brainstorming and researching ideas for your app, step back and consider the context in which the device will be used by real live people. How does the iPad fit into our lives? In what situations would we prefer this device to a laptop or iPod Touch?

Complexity and Simplicity are Perceptions

Josh Walsh — Tue, 13 Apr 2010 20:48:59 +0000

User interfaces should present the information needed to accomplish the task at hand. Nothing more, nothing less. Complexity and simplicity are our ways of perceiving how difficult or strenuous a task is going to be.

Compare this IRS form, to a similar TurboTax form:

It’s very difficult to make an IRS form feel inviting. That’s why TurboTax has considerable market share.

Tumblr Checkout UX pattern causing security confusion

Josh Walsh — Sat, 03 Apr 2010 03:18:11 +0000

Tumblr.com’s new Premium Theme checkout process is clever. A traditional checkout process would feel a bit clunky in their environment. They should be applauded for taking steps to break that mold. However, I have one major problem with it’s implementation.

Ecommerce is plagued by one UX hurdle that most other sites do not deal with in nearly as much detail: security. Since Tumblr’s checkout takes place completely inline, you’ll never see “https” in your browser. The browser never shows the standard lock icon, indicating that the site was confirmed secure. Rather, they do everything through asyncronous calls which mask the security from the user.

Security is an asset and shouldn’t be masked from people willing to enter their credit card information.

While Tumblr’s process is secure from a technical standpoint, they don’t instill buying confidence. My grandparents know not to enter a credit card into a site that doesn’t have the lock icon, and I wouldn’t use it without digging deeper.

What do you think about their checkout pattern? Does the security bother you like it bothers me? Leave a comment below.

iPad Application Design

Josh Walsh — Tue, 09 Mar 2010 21:18:54 +0000

The iPad is not just “a big iPhone.”

Technologically speaking, it is very similar. The way you interact with it, however, is different. The applications don’t feel like mobile apps. They are robust, full featured and intuitive.

Make Your User Interface Intuitive By Encouraging Experimentation

Josh Walsh — Wed, 17 Feb 2010 20:21:57 +0000

The design industry is plagued with the misconception that product manuals are evil. These designers believe that your product should be intuitive enough to use without a manual.

While there is a certain truth to this, there are many viable reasons for product manuals to be used. There needs to be a certain level of competency that can be achieved without the manual.

A manual is never an excuse for poor design.

Your product should be designed to encourage people to experiment. That’s how people learn how your product works, and it is also how they discover advanced functionality.

For example, Google SketchUp encourages you to grab the basic 3D modeling tools and start playing around. The manual becomes necessary when you need to do something more advanced.

You cannot make every feature equally intuitive.

As software products grow, they typically become less usable. Complexity breeds usability problems. It’s impossible to add features to an application without making the interface more complex. We can mitigate this in a couple of ways:

1. Don’t build any features which aren’t absolutely necessary
2. Don’t give all interface elements equal weight.

The first item is what makes people love or hate 37 Signals applications. They are simple and intuitive, but lack advanced features. For that reason, they are able to have maximum control over their UI designs, and thus, have some of the most intuitive applications on the web.

The second item is what Microsoft fought against with the new release of MS Office. For years the number of buttons on our toolbars grew. Our menus were stuffed full of items we never used. Yet, they were given equal weight to those that we do use.

Microsoft had a number of innovations to solve this problem:

Customizable Toolbars
It learned which items you never used, and hid them.
Eventually, the Ribbon Bar replaced the old toolbar paradigm.

Even with these problems, Microsoft Office was a success because their interface encouraged people to experiment and play.

When you first start Microsoft Word, you are given a blank document with a cursor. You can type, format text, insert images and more, all without reading the manual. When you get into more advanced options, like embedding documents or mail merge, you look up what you need in the manual.

Overwhelmingly Scary Interfaces

Sometimes we come across applications which do encourage us to play, but still frighten us. Photoshop is the classic example. They encourage us to play, but not in a real world context. You can easily start a new document and draw all over it, but when you need to really do something specific, you get scared.

Simple tasks, like changing text size, changing font colors, and image cropping can be scary to a new user. Let alone advanced image slicing tools and warping utilities.

Photoshop failed in making a sandbox to play in. Instead, they scare you with a blank slate.

The O’Reilly Publishing company has capitalized on this fear with their “Missing Manual” book series, which has become very popular.

Discover new features as you go

Music publishing software is dominated by two products: Finale, and Sibelius. Both encourage you to start composing by giving you an empty music staff, and simple tools to drop notes onto the staff. It keeps the spacing clean for you, encouraging you to continue playing.

Over time, you discover new ways to enter notes using a MIDI keyboard. While these features are much more efficient, the products encourage you to play the easy way until you discover them.

I encourage you to take a look at your interfaces and discover new ways for people to harmlessly experiment with them.

How to analyze a usability study

Josh Walsh — Fri, 29 Jan 2010 20:42:32 +0000

Most of the value you gain from a usability testing session comes from the analysis after the session is complete. I have been involved in a few sessions recently where no formal analysis has been conducted. I believe this is a mistake.

Traditionally, the analysis portion of a usability session takes quite a long time. The end results is usually what I call a “Dead Document.”

“Dead Documents” are reports that have value, but negatively impact productivity. This is usually because it takes too long to create the document, or there isn’t enough time to consume it.

I have developed a quick and dirty system for analyzing the data. It requires only a few hours to create and only a few minutes to consume.

Conduct a quality study

The quality of the results directly depends on the quality of your study. For the purposes of this post, I’m going to assume that your study was conducted properly. (Quality questions, good prototypes, people in your target demographic, etc…).

Use your brain

Even though you were the administrator of the study, you were also a participant. Your brain already has a good idea of the results. Take a few moments to write down your hunches. I like to mindmap, but you may prefer to doodle or freewrite. You should not worry about structuring or organizing your thoughts, just let them flow out of your head and onto paper.

Here are a few examples:

“A few people had a hard time understanding how the dropdown navigation works. I think it’s because they were distracted by the dancing Santa Claus on the opposite side of the screen.”

“It was obvious that people weren’t seeing the ‘logout’ link, even though I thought it was fairly obvious.”

In the next steps, we will try to prove or disprove your theories using the real data you collected.

Prepare to Review

Write down the questions or use cases that you asked your participants to discuss. We are going to grade each response with one of the following values.

1 – Indicates that the user was able to complete the test without assistance.
0 – Indicates that the user was able to complete the test after some help.
-1 – Indicates a complete failure. Could not complete the test even with assistance.

In the end, we will sum up the results to come up with a pass/fail score. Before we can do that, we need a baseline score to compare against. Before you review the tapes and notes you need to decide what you think a “passing” score should be.

For example: You were testing a login form with 5 participants. Since this is a crucial feature to get correct, a score of 5 (all participants passed without assistance) is your baseline.

Another example: You were testing the ability to rename a bank account inside an online banking application with the same 5 participants. This is not critical, so a passing grade of 3 may be acceptable to you.

Another example: You asked the 5 participants to explain how they would contact support if they were having problems. A score of 4 would be acceptable here.

I setup a simple spreadsheet to keep myself organized. This easily translates into a deliverable document once completed.

Analyze the Results

Start reviewing your tapes and notes to extract the results of the tests, and plug them into your document. Write down any observations that you think are important. Keep track of things that were said that may be important later.

Sum up the total results across the participants and compare that with your baseline. I like to notate passing and failing tests in red and green.

Write a short paragraph for each test indicating the level of success, and a note about what was done right or what could be done better. Note anything interesting that your participants may have told you.

Write an overview paragraph at the top of the document explaining the results of the test overall. Which areas of the system need the most improvement, and which are working well.

The finished document is usually 3-5 pages of information which can be quickly scanned and understood.

Timeless Interfaces, and how to Replace Them

Josh Walsh — Fri, 25 Sep 2009 18:22:35 +0000

Since the invention of the modern calculator, one particular product has dominated the business market. The HP 12C financial calculator. Many manufacturers, notably Texas Instruments, have tried to innovate on this model and modernize it without tremendous success.

The HP 12C has gone through several design iterations without adding additional features. It’s functionality was scoped well in the beginning, and it’s designers held firm against the inclusion of new features. The interface is timeless.

Eventually though, technology catches up with us. The same business people who swear by this calculator are now pushing hard for alternatives.

Today T-I announced their newest product. In collaboration with HP, they have developed an astounding business calculator iPhone application. The interface is pristine. It looks and feels (except without the clunky, stiff buttons of the original) just like the real-mccoy.

Why is Apple discouraging interface consistency?

Josh Walsh — Mon, 21 Sep 2009 02:39:27 +0000

If you haven’t heard by now, there is quite a battle going on between Google and Apple. Apple has refused to include the Google Voice application in the App Store, along with similar apps by other parties. The FCC is now investigating.

Apple claims that Google’s application would negatively impact the users experience with the iPhone’s native telephony and sms applications.

This is interesting. Google’s application is visually & behaviorally consistent with the native applications. It makes sense that Google’s application would be easier to use because of this consistency. Google’s application has some pretty basic functionality…

To make phone calls by dialing numbers or choosing a contact from the address book
To send/receive SMS messages
To check voicemail

These features overlap entirely with Apple’s native interfaces. In my opinion, Google’s application would be most usable by making it feel consistent. To make it feel seamless.

Other applications have been removed from the store for being visually consistent with Apple’s interface elements. If your chat bubble is glossy, forget about being included. So, to me it sounds like Apple’s real problem is with people copying their style.

Apple’s designers are intelligent people. They understand the benefits of user interface consistency. Heck, they have been evangelizing it to OSX developers for years. Google get’s it too. Apple should be encouraging applications which seamlessly fit the iPhone’s style. They should be pushing back on the applications which break their user interface guidelines. A consistent look and feel would only serve to make things more usable.

It’s clear that there is a deeper issue here. What do you think is really going on? iPhone vs. Android? AT&T vs. Google Voice? Involving Eric Schmidt (Google CEO) leaving Apple’s board?

Comment your theories.

37signals new announcement panel is too intrusive

Josh Walsh — Fri, 18 Sep 2009 14:01:35 +0000

I’m a bit perplexed with the way 37signals has implemented their new announcement feature inside of Basecamp. As developers it is important that we communicate changes to our applications with our users. It shows that we are attentive and dedicated to fixing problems.

While it is important that the people using our software read these announcements, we should realize that it’s not the most important part of their experience. The new announcement system in Basecamp is intrusive. It’s popped-up in your face as the first thing you see. You are forced to address it before you can continue.

Intrusive interface elements can be a powerful tool in the UI designers toolbox. However, they need to be used responsibly. Some announcements may warrant this intrusive behavior, but the one I saw today certainly did not.

September 17, 2009 – Fixed an issue with switching out of the image grid view on the files tab.

37Signals Announcement

In my opinion, there was nothing wrong with the way it worked previously. It was positioned prominently at the top of the Dashboard, but wasn’t intruding.

I speculate this decision was made to ensure announcements are seen on all pages. We don’t always see the dashboard, and an important announcement could be missed. In that case, I think they should just show an announcement indicator which links to the announcement.

I’m probably making a mountain out of a molehill here, but I think it demonstrates a key problem with many web interfaces.

The difference between User Research and Usability Testing?

Josh Walsh — Wed, 09 Sep 2009 21:10:50 +0000

User research studies and usability testing are two fundamental phases of an interaction design process. When I’m out at conferences or meetup groups talking about my process, I often hear people confusing the two terms. So, what are these phases?

Simply put, the biggest difference is when they are used in the process.

User Research

User research is done at the beginning of an iteration, before you design or build anything. The data you collect during this period is used to drive your design and development. We often interview key people, do card sorting exercises, develop personas, assemble mental models and create use cases.

In an ideal situation, the user research will help define the scope of the project you are building. It will confirm that the features you think are necessary actually are, or it will prove that they really aren’t necessary after all.

Usability Testing

Usability testing is conducted at the end of an iteration. The purpose of usability testing is to make sure that the work completed in the current iteration can be easily consumed by the user. You will be collecting feedback from users which will help you determine what you should accomplish during the next iteration.

The Iteration

Each iteration begins with user research and ends with usability testing. That is why we call it User-Centered Design.