Originally published: Dec 04, 2007
Back in 2006, networking site Facebook.com introduced a new feature the designers thought users would love. Instead of forcing users to check up on every friend’s Facebook pages constantly to see any change in the friend’s status, they created a “mini feed” which instantly displayed all changes on their own Facebook page. The designers thought users would embrace the new feature, seeing it as a real strength of the site.
Instead, users rejected the mini feed. They didn’t like how it was propagating information they perceived to be personal across the entire user base, seeing the feature as an invasion of their online privacy. Within 24 hours of the feature’s introduction, more than 750,000 of the then eight million users had signed online petitions, putting Facebook’s new feature squarely on the front page of both the New York Times and the Wall Street Journal.
(It’s interesting to note Facebook users found out about the petition by seeing other people sign it in their own mini feed display. The feature itself contributed to the protest’s impressive speed and strength.)
Having 10% of your users reject and protest a new feature within 24 hours is an issue unique to web-based applications. If users don’t like a feature in their desktop word processor, they may complain and some may editorialize, but you wouldn’t see such an immediate and passionate response.
Web-based applications present usability challenges we don’t often see in other types of designs. These challenges need to be top-of-mind as the design team creates, updates, and maintains the application.
A contributor to Facebook’s mini-feed debacle was the scale of their design. Facebook, making any change to their site, instantly affects eight million people. If even one percent has issues with the change, that’s 80,000 affected users. (In 2010, that would affect 500,000 users.)
Being a social networking site compounded Facebook’s issue. Users connect to other users, some users having dozens or even hundreds of connections. Those users with many connections instantly saw a very populated mini feed and realized their previously subtle interactions on their page were now broadcast to each connection.
Scale issues show up in a myriad of ways. Netflix, the online movie store, allows users to place movies they want to see into their queues. Managing a queue with 10 movies is quite simple. However, some users have hundreds of movies in their queue. Do they chunk the display of the queue into groups of 10 or 20? Do they display them all at once? How do they effectively give users control over the movies arrival order?
Many e-commerce sites give users the option of storing their shipping and billing information. What happens when users have multiple payment methods (such as a work credit card and a home credit card) or have multiple shipping addresses? For some gift sites, such as Proflowers.com, users could have many people they wish to send flowers to on a regular basis. That implies building sophisticated address book functionality into their order processing application.
Designers need to take both the scale of the user base and the scale of the data into account when thinking about how to design their web-based applications effectively.
Web apps live in this strange world, half application, half web site. Something as theoretically simple as making a command look like a command becomes difficult quickly. Do you make it a button? Do you make it a link?
Take the common practice of supplying an “Advanced Search” capability alongside the standard search. A typical implementation will have a text box (for entering the query), a “Search” function (for the standard search), and an “Advanced Search” function. Should the designers make both functions into buttons? Will that confuse the user? If they make “Advanced Search” a link, will users understand it’s an alternative command (versus an explanation or some other site feature)?
Sometimes, in web application design, it feels like every pixel matters. This isn’t just a question about the application’s aesthetics. Visual design can have a huge impact on how the application communicates its use.
A user, doing their taxes or booking an airline reservation, doesn’t want to think about the mechanics of interpreting the application’s screen. They want to think about their deductions or their vacation destination.
Yet, if the visual design isn’t clear and concise, the design takes the user’s focus away from what they wish to think about and forces them to try to guess what the designers were trying to tell them.
At Lahey.org/appointments, patients can make new appointments or reschedule existing appointments with the Lahey Clinic’s hundreds of doctors. The application helps keep costs down by reducing the calls coming into the clinic’s offices. The app asks existing patients to enter their Lahey Clinic Number, an 8-digit number often starting with the letter “L” (such as “L1234567”).
Yet, the appointment scheduling application doesn’t want users to enter the “L”. They only want the seven numeric digits. In informal testing, we found patients, not realizing they needed to enter only the numeric digits, would receive an obscure error message and become flustered, often resulting in having to call the clinic’s offices for help.
The designers could choose one of several alternative visual treatments to solve this problem. For example, they could start the field with an “L” or they could provide an example for users to follow. Many visual design issues, like this one, are simple to fix with a little creativity and experimentation.
Visual design problems affect an application’s success in a variety of ways. In the mildest form, they slow users down and distract them from their task. In the worst cases, they confuse users to the point of giving up or needing assistance. If the application is in the organization’s revenue stream or helps reduce costs, we’ve seen visual design issues can dramatically affect the bottom line.
Potential investors use the MSN Money Stock Research Wizard to help determine if a stock or mutual fund is the right investment for them. Because MSN Money tailored the wizard to new investors, the application contains detailed explanations, not only about the stock the investor inquired about, but about the questions the investor should be asking.
Even if the application functions properly, it will fail the user if they don’t understand the information it’s trying to tell them. The investor needs to both use and comprehend the wizard for it to succeed.
Web-based applications often help people by doing things outside their expertise. They turn to the application to help guide them through a decision making process they couldn’t do on their own. Yet, if they make the wrong decision, it negatively affects their experience and their relationship with the organization.
One of the big differences between a web application and other types of web pages is the user is far more interactive. On a content-rich site, users mostly click links and occasionally search. Yet, in a web application, they enter data, sort it, rearrange it, and move back and forth through the screens.
Understanding how the user will manage their time becomes critical. Does the team put all the data entry on one long screen? Do they break it up across multiple screens? What is the logical order to enter the data?
Users don’t always follow the “happy path.” They enter data incorrectly. They decide they need to go back and change something they’ve already entered. They discover they need to learn more about what the application is asking of them and, thereby, need more detailed assistance.
Something as simple as always providing a mechanism to “undo” what’s already been done can create interesting usability dynamics. Handling how the application deals with browser controls, such as the back button, can make the designer’s life more challenging.
The designers at Facebook learned the hard way that quick changes to the application, even if the team thinks it’s an improvement, can have serious negative results if done incorrectly. We all know that users are resistant to change, yet designing how the change will happen is often overlooked, to serious detriment of the user experience.
While users are resistant to change, they are willing to do it when given enough support and structure. The problem with quick changes often happens when users frequently use an application and the old design conditioned them to things being a certain way. Even when the change is to their advantage, they often need warning and support to go from the old to the new.
We’re now seeing teams start to design the change process along with designing the changes themselves. Paying attention to how users make the transition can increase a change’s adoption and build long-term user loyalty.
At the highest level, building a usable web-based application isn’t any different from any other type of design: You place design ideas in front of users, look for where the idea doesn’t achieve the objective you’ve set out, and iterate until you get the results you’re seeking.
However, in design, the devil is always in the details. The above five usability challenges make web apps different from other types of design. Our research shows designers who are on the lookout and accommodate for them are more likely to create winning applications that delight users.
Part of the challenge in web applications is the visual design of a web application. David Rivers tackles this challenge in our next UIE Virtual Seminar: Visual Design for Web Applications, tomorrow, November 18. David shares real-world examples and insights that you won't want to miss. Learn more about the virtual seminar.
What challenges have you faced when developing web-based applications? How have you overcome these? We'd love to know. Leave your thoughts in the discussion at the UIE Brain Sparks Blog.
Read related articles: