Users don’t read; they scan. When they analyze a web page, users search for some fixed points or anchors that can guide them through the content on the rest of the page.

Web users are impatient and insist on instant gratification. A very simple principle: if a website doesn’t meet users expectations, then the designer has failed to perform his or her job properly, and the company will lose money. The higher the cognitive load needed by users to process the website and the less intuitive the navigation, the more likely users will leave the website and search of alternatives.

Users don’t always make the best choices. They don’t look for the quickest way to find the information they want. Nor do they scan web pages in a linear fashion going sequentially from one section to another. Instead, users choose whatever “satisfices” (satisfy + suffice). They choose the first reasonable option that presents itself. As soon as they find a link that might possible lead to their goal, users will very likely click on it immediately. Optimizing is hard, and it takes a long time. Satisficing is more efficient.

Users follow their intuition. In most cases, users muddle through on their own rather than read the information a designer has provided. According to Steve Krug, the basic reason for this is that users don’t care. “If we find something that works, we stick to it. It doesn’t matter to us if we understand how things work, as long as we can use them. If we are audience is going to act you’re designing billboards, then design great billboards.”

Users want to have control. Users want to be able to control their browser and rely on consistently presented data throughout the website. For example, they don’t want new windows popping-out unexpectedly, and they want to be able to use the “Back” button to return to a website they had just visited.

From the Smashing Book, page 123.

Related posts:

1. The conspiracy against user-friendly software How to design a user-friendly software: Test the design Identify the problems Modify the design Repeat step 1 Sounds easy, right? That is until time pressure, individual preference, market forces...
2. Don’t forget to help your visitors All newspapers, magazines, and catalogs work the same way – you start at the front cover and keep turning the pages. That is not the case with websites. When visitors...
3. 10 guidelines for building the credibility of a website Here are 10 guidelines for building the credibility of a web site based on research in Stanford University: Make it easy to verify the accuracy of the information on your...

No related posts.

via BusinessWeek

Related posts:

1. Business and design trends for 2009 Top Small Business Marketing Trends for 2009 from Small Business Trends “Marketing in 2008 became decidedly social — and 2009 will see the social elements of marketing accelerate. Social media...
2. Outsourcing: The Philippines vs. China and India Filipino software execs say their infrastructure and ties to the U.S. give them an edge over their bigger rivals, but a seasoned talent pool is lacking. … the numbers are...
3. Tips from 10 design experts Don Norman: The three ways that good design makes you happy Philippe Starck: Why design? Jacek Utko: Can design save the newspaper? Paul Bennett: Design is in the details David...

When visitors arrive at a new website, they pause, look around, and figure out how to proceed. There are a lot of question marks in their head and as soon as your website answers them the better. Otherwise, your visitor will leave and may never come back.

Websites are difficult to use

All visitors suffer a moment of difficulty in a website. Some find it a simple annoyance while others become frustrated. Recognizing that websites are still not as easy to use like a newspaper is the right attitude when designing webpages.

Who does not want a visitor-friendly website? I’m sure you do but your actions do not say so. Too often your websites serve the needs of your company, or sometimes, even your egos. You cannot accept the truth that your visitor are finding it difficult to move around your website. This has to change.

When building the pages of your website how often do you ask yourself this question: “Am I helping my visitor with this webpage?”

We understand the pressure. Different people in an organization have different and often conflicting goals for the website. You throw up your arms and give up. Helping visitors requires fighting some fights. You may need to fight with the sales guy, the programmer, your boss, and yourself.

Yes, including yourself.

You thrust your own views upon your visitors. You want him to accept your website, your design, your creation. You want your visitor to change to satisfy you. When she does not, you call her stupid.

It is not just layout and colors

You have spent a lot of time designing the layout and choosing the right color combinations that you believe would appeal to your visitors but you forgot how to talk to them. Just like any human being on the planet we use words, not colors nor diagrams.

If you want to help your visitors, then talk to them in a language they understand. Use words and terms that are relevant to your visitors — not words only you and your friends understand. Craft your messages the way you would talk to a person face-to-face. The online world is a lonely place — your visitors need company.

Does it matter?

At one point, you have also visited a website that is inconsiderate of you. How does it feel? Don’t forget that you are a visitor, too.

Related posts:

1. Words are part of the interface The use of words is a critical component of a website’s design. Just like layout and colors, it can enhance the usability of your website and provide a pleasant online...
2. How do users think? Users appreciate quality and credibility. If they see high-quality content, they are usually willing to tolerate advertisements and a poor design. This is why websites with mediocre designs but high...

1. Make it easy to verify the accuracy of the information on your site.
2. Show that there’s a real organization behind your site.
3. Highlight the expertise in your organization and in the content and services you provide.
4. Show that honest and trustworthy people stand behind your site.
5. Make it easy to contact you.
6. Design your site so it looks professional (or is appropriate for your purpose).
7. Make your site easy to use — and useful.
8. Update your site’s content often (at least show it’s been reviewed recently).
9. Use restraint with any promotional content (e.g., ads, offers).
10. Avoid errors of all types, no matter how small they seem.

Related posts:

1. The Inconvenient Truth on website performance When we looked at the actual download speeds of the sites we tested, we found that there was no correlation between these and the perceived speeds reported by our users....
2. Starting a Q&A website: Canada Work Visa Last week I created a Q&A website for things related to Canada work visa. (This is actually a project of my wife’s cousins and I’m just helping them out sort...

Philippe Starck: Why design?

Jacek Utko: Can design save the newspaper?

Paul Bennett: Design is in the details

David Kelley: The future of design is human-centered

Stefan Sagmeister: Yes, design can make you happy

Janine Benyus: 12 sustainable design ideas from nature

Jared Spool: Journey to the Center of Design

Bonnie John: Usability and Software Architecture: The Forgotten Problems

Bill Scott: Bringing Design to Life: What Every Designer Should Know about Interface Engineering

Related posts:

1. Business and design trends for 2009 Top Small Business Marketing Trends for 2009 from Small Business Trends “Marketing in 2008 became decidedly social — and 2009 will see the social elements of marketing accelerate. Social media...
2. The 10 Commandments of Web Design Thou shalt not abuse Flash. Thou shalt not hide content. Thou shalt not clutter. Thou shalt not overuse glassy reflections. Thou shalt not name your Web 2.0 company with an...
3. Beware of the usability Stockholm syndrome The only way they to know if an application works well for users is to conduct usability testing. A usability test does not need to be expensive like having a...

A usability test can be as simple as grabbing the next person that passes by the hallway. You don’t even need a hundred people; five people is enough.

We conduct usability tests because we know that someone with a set of fresh eyes will find more problems in the application than someone who has been looking at the user interface everyday for the past 189 days. When we ask people to participate in our usability tests, we expect them to be super-critical of our software. We tell them we’re evaluating the software, not the person. It is absolutely OK if they tell us that the “interface sucks” or “I felt dizzy after looking at this page. I think I’m gonna puke.”

But as experienced by Jensen Harris, a Microsoft programmer working on the Office software, people tend to become less critical during usability testing as if they are suffering the Stockholm syndrome — a case where the hostage becomes sympathetic with its captors. Why does it happen?

It’s human nature

If someone invited you over dinner and asked you what do you think of the food you won’t say it tastes bad. You will most likely say, “I love it” or “you should start a restaurant business.” It is our human nature not to say bad things of a person especially if we are in her house. Probably after the usability tests, you would tell your friends that the new software Greg is working is a mess, but not infront of him.

We think we’re computer illiterate

When we were kids at school, if we’re the only person who got the division wrong, we feel very bad. Can’t blame you. The other kids would probably be laughing and by now you think you’re stupid. Add the look in your teacher’s face as if telling you to pack your things, go home, and sell banana. Growing up, we were conditioned that if you don’t get it, it is your fault. Every time we can’t figure out how a software works, we tend to blame ourselves, rather than the software, because we think we are “computer illiterate.” If only we could adapt to this software, then there wouldn’t be any problems.

So what can you do?

• Be friendly. It’s difficult to tell the truth if someone would kill you by doing so.
• Reassure the participant that this is not about her, this about the software.
• Be always on the lookout. If the participant appears hesitant to comment, help her speak out like asking questions such as “Do you find the text confusing?”

No related posts.

When we looked at the actual download speeds of the sites we tested, we found that there was no correlation between these and the perceived speeds reported by our users. About.com, rated slowest by our users, was actually the fastest site (average: 8 seconds). Amazon.com, rated as one of the fastest sites by users, was really the slowest (average: 36 seconds).
— The Truth About Download Time

Was Jakob Nielsen, the usability guru, wrong when he concluded that to avoid annoying users, pages should load in less than 10 seconds? I think he’s still right because it is no fun staring at the hourglass for 5 minutes. But when we tell our friends that Flickr is faster than Picasa, we don’t say uploading a 1MB JPEG takes 2.35 seconds in Flickr while it takes 4.86 seconds in Picasa. We just say Flickr is faster.

What is missing from Nielsen’s conclusion is that when users say a website is slow, they talk about their feelings and not what they see in the stopwatch. This does not mean that programmers should abandon measuring website performance. We still need to make that slow function run faster and there is no way to tell if we are progressing or not if we don’t know the score.

Browsers follow a fetch-parse-flow-paint process to load web pages. Given a URL, the fetch engine finds it and stores the page into a cache. The parse engine discovers the various HTML elements and produces a tree that represents the internal structure of the page. The flow engine handles the layout while the paint engine’s job is to display the web page on the screen. Nothing unusual except that when the parse engine sees an image, it would stop and ask the fetch engine to read the image. The parse engine continues only after it has determined the image’s size. The end result is that the browser will wait until all the elements of the page has been processed before it shows the page. During this processing, all the user sees is a blank page. This is how things work with the 1st widely-used web browser, Mosaic.

Netscape Navigator 1.0 took a different approach. When the parse engine sees an image, it still asks the fetch engine to load the image. The difference is that the parse engine will put a placeholder in the internal structure of the page to mark where the image is and let the flow and paint engines do their job. When the image is loaded and analyzed, the paint engine does a repaint on the screen. This can happen several times if the page has a lot of images. If you measure the overall time it takes to finalize the page display, Mosaic is faster than Netscape. But, users would say otherwise. Mosaic lacks a sign of progress while the appearance of text, then an image, then another image makes users think that Netscape is faster.

My first encounter with the world wide web was in April 1996 while working as a student assistant at the Advanced Science Technology Institute. Back then, web pages consist mostly of text. Nowadays, it is not uncommon for a page to contain lots of big images, embedded videos, references to several CSS and JavaScript files. So while computing power and bandwidth has improved over the years, content has also bloated making performance issues still a problem.

The common opinion is that if you want to improve a website’s performance, you focus on the database, web server, and other back-end stuff. But, Yahoo! engineers found out that most optimization opportunities are present after the web server has responded with the page. When a URL is entered into the browser, 62% to 95% of the time is spent fetching the images, CSS, JavaScript contained in the page. It is clear that reducing the number of HTTP requests will also reduce response time.

The Yahoo! Exceptional Performance Group has identified 13 rules for making fast-loading web pages. The group’s lead, Steve Souders, has also written a book on website performance.

Another cool product from the team is YSlow (nice name). It analyzes a web page and tells you why it is slow based on the 13 rules. YSlow is a Firefox plugin and works alongside another web developer’s indispensable tool, Firebug. When I first used YSlow with SchoolPad, my initial grade was F (58). I first set out to address Rule #10 – Minify JavaScript. Since SchoolPad is written on Ruby on Rails, the asset_packager plugin came in handly in merging all my CSS files and JavaScript files. Using the plugin, CSS and JavaScript files can be used in a single reference.The asset_packager is also smart. During development mode where CSS and JavaScripts files are often updated, the plugin references the original script files but in production mode it uses the minified versions of your CSS and JS files. A few changes in your Capistrano file, then you can make the minification (is that a word?) process automatic every time you deploy your application. After a few more tweaks, my overall grade is now C (78) with an F on rules #2 (Use a CDN) and #3 (Add an expires header). I can’t address rule #2 because that requires money and #3 has to wait because it requires more Googling.

It might happen that you have an A in YSlow yet users complain that your website is slow. Talk about an unlucky day. Don’t despair. Maybe, it is time to focus on managing expectations instead of performance.

I wrote my first GUI-based program using Visual Basic on Windows 3.1. (I’m sure Evan would argue that Basic is not a programming language). Any Visual Basic book would tell you to change the mouse pointer to an hourglass before a lengthy operation such as a database query, and change it back to the default pointer afterwards.


Screen.MousePointer = vbHourglass
‘Do lots of stuff…….
Screen.MousePointer = vbNormal


I think many people got addicted to the mouse pointer that along with the release of Windows 95 was a variety of themes that replace the default mouse pointer icon with a rocketship, a barking dog, or a wiggling clownfish.

Anyway, back to the web. Wait! The reason the hourglass is widely used in desktop applications is because it tells the user that the application has accepted the action, and it is now working on it. In your web apps, you should do the same.

Traditionally, when you click a link in a website, the browser sends a request to the server, receives a page, and repaints the content. Feedback in most browsers is in the form of a spinning logo at the top right part or an expanding strip at the bottom or at the status bar.

Here comes Ajax. With Ajax you can do away with refreshing everything and update only a portion of your page. Unlike the page-based model, the browser cannot give feedback that something is going on after an Ajax-based action. No more spinning logo. No more expanding strip bar. We went backward in interface design.

Fortunately, there is a way to give feedback that requires writing code using JavaScript. It could be as simple as writing a message “Loading…” on the page or using an animated GIF file. One implementation would be just to show a previously hidden text or image or create an ‘img’ element and append it to where you want to display (usually a ‘div’ element). Many web applications nowadays use various style of animation but the key idea is the same — a smoothly looping animation to indicate an activity.

Animated activity indicators are useful for tasks that will incur short delays. If the delay takes too long, the user may think the application is going on circles or has become a zombie. For longer delays, it is best to show how much progress has been made, an estimate of time remaining, or a sequence of messages telling the user what’s happening at the present. This is very useful but tricky to implement because HTTP requests don’t give tracking information at regular intervals. If you are making a sequence of 4 requests, you can guesstimate that progress is 25% done when the 1st call has completed. Flickr uses the best activity indicator I’ve seen so far when uploading images. Image files are usually big and Flickr does a great job of giving progress feedback to its users — an overall progress and a per-file progress indicator.

During the modem days, it is acceptable that many sites are slow given the hardware limitation. But now in the broadband era, amplified by tons of marketing, users expect websites to be lightning fast.

Nobody wants a slow website. But when the user say it is slow, oftentimes, it is because nothing is happening on the screen.

Related posts:

1. How do users think? Users appreciate quality and credibility. If they see high-quality content, they are usually willing to tolerate advertisements and a poor design. This is why websites with mediocre designs but high...
2. 10 guidelines for building the credibility of a website Here are 10 guidelines for building the credibility of a web site based on research in Stanford University: Make it easy to verify the accuracy of the information on your...
3. How to share code between Javascript and Rails Rails’ validations is great because it allows you to quickly implement the valid states of your models and at the same time have a ready-made way of displaying the errors...

About last year.

• Top 6 Marketing Lessons Learned in 2008 from Practical Ecommerce
  “We’ve all heard the old adage: Those who don’t learn from history are doomed to repeat it. What recent 2008 history has taught marketers is the value of online marketing in tough economic times. Consumer purse strings presumably won’t loosen much in 2009, which means marketers have to create smarter online marketing strategies…”
• America’s Biggest Billionaire Losers Of 2008 from Forbes
  Combined, the tycoons on our ranking lost $167 billion in 11 months, while shares of the companies in which they own stakes fell an average 59%.

Related posts:

1. Top 20 Innovative Companies in Canada 2009 …from the Canadian Innovation Exchange: Aeryon Labs Inc. Builds military-like devices for imaging CognoVision Solutions Inc. Analytics for digital signage using face detection and tracking Darwin Dimensions Build your own...
2. The 10 Commandments of Web Design Thou shalt not abuse Flash. Thou shalt not hide content. Thou shalt not clutter. Thou shalt not overuse glassy reflections. Thou shalt not name your Web 2.0 company with an...
3. 10 Recession-proof IT sectors Virtualisation Good news for VMware. Open source Is open source dead? Green IT I guess, any business that you can align with Al Gore is a good business. Cloud computing...

1. Test the design
2. Identify the problems
3. Modify the design
4. Repeat step 1

Sounds easy, right? That is until time pressure, individual preference, market forces and other factors come in and conspire against the design.

The most common business model for software is to regulary release versions of a product, where each release contains more features than the previous. The new features give customers reason to open their wallets and upgrade their software. Ideally, the new version keeps the good features and adds more good features.

Ideally.

When a new version is released, the design of the next version has already started. From a business perspective, this is a good strategy because the company can keep releasing new features. From a design perspective, gathering and understanding feedback from actual users seldom happens, which is a necessary step to improve the product. Without feedback, the designers would not know that users are having problems printing in landscape or they can’t find the spell checking tool anymore. What used to be a simple thing to do now becomes a source of confusion.

Making features available, it seems, is not a difficult thing to do. There is no physical limit in how many items a menu group can contain or how deeply nested your menus are, or how many buttons you use. If your designing a web application, you can include a hundred links in a page and Firefox won’t complain.

The difficult part is deciding what goes where. What menu group should this be included with? Would this be part of the standard toolbar? Should it be introduced in a flash screen? Should this be at the top, middle, or at the bottom of the list? Even though there is unlimited space for every feature, every feature competes with each other for user’s attention. An item on top of a menu list is more accessible than the items at the bottom. It is not uncommon for users to suggest or complain that the feature they often use should be at the top of the menu list.

More features also mean more options for the users. If the additional features are for accomplishing different tasks, it does not present a problem to the users, for example, saving a document and printing it. But if you give the users many options to accomplish a single task, it would require extra brain processing. In the case of printing, possible options include page size, number of pages in a sheet, print range, orientation, and color. Every time you give users a choice, they have to think about something and make a decision.

Features not only affect design but also the integrity of the software. As developers add more features, they also put in new code. The new code not only has the responsibility to implement the new features but also not to damage existing ones. As the code grows, complexity rises exponentially thus making it difficult to add new code and preserve the integrity at the same time.

Business strategy is not the only factor that can work against a user-friendly software. Sometimes, the designers also work against good design. Making things better is a noble goal but sometimes it gets confused with simply making things different. A designer involved in several iterations of a product has the innate pressure to make things different from the previous. When you hear designers suggest a redesign, it should only be done if it is aligned with making things better like improving navigation, decreasing task completion time, or improving quality of search results.

Design is often confused with aesthetics. If you survey the job requirements from companies looking for web designers, the primary requirement is often an expertise in Adobe Photoshop. Aesthetics will make the design pleasing to the eye but may make it less comfortable to use. Usability can make the interface comfortable to use but can be uglier. New technology, like Ajax, can make the software more responsive but could be at the expense of aesthetics and usability.

Making aesthetics a priority is not confined to interface design. It is everywhere. We buy alarm clocks that looks beautiful but has unreadable numbers, or phones with vibrant colors but with a small keypad. When we moved to our new office, an admin staff asked what I think about our work area. I said the work area is too crowded and our developers would always hit the guy behind him when he stretches his arm. Puzzled, she was actually asking if I like the colors of the wall. Because if not, they will change it. But the alloted space for each developer would remain.

This is not to say that decoration is unimportant. Used properly, decoration can guide the users to help them achieve their goal. Aesthetics can help increase the probability of software or website being used, whether or not it is actually easier to use. A more accessible and usable product may suffer lack of acceptance making a noble goal, e.g. accessibility, useless in the absence of an effective visual presentation.

It is our nature to be biased towards attractive things — Nokia cellphones, iPod, BMW, and Paris Hilton. It is no secret that movie actors and actresses receive more attention and that, all other variables being equal, attractive people are preferred in hiring decisions. Attractive things also foster positive attitudes like affection, loyalty, and patience making people more tolerant of design problems. Even though an attractive software is not user-friendly, it can still become successful because once we liked something, our natural talent to adapt kicks in. When we are hook, forcibly or by choice, we find ways to adjust with the unusable interface. Over time, the interface becomes natural to us even though a 5-step task can be redesigned to become 2.

When users are already conditioned to do things in a certain way, design improvements can have negative results if not managed properly. In the case of web applications, the ability to make quick updates immediately available to users is a double-edge sword. Adding inline validation in the order-entry form will improve user experience but reorganizing the flow of the pages will present problems to users even though the change, as the designers see it, is an improvement.

The problem is designers often think of themselves as typical users. Even though design discussions revolved around “what if the user wants to…” and “i think the user will be confused if…”, it is our nature to project our own beliefs onto others. What designers think as improvement to the user’s experience is often just a result of his own biases. While the designer may be correct, designs that are product of internal discussions should be done if it matches the results of study with actual users. The are ways to involve the users as early as possible like releasing prototypes or chunking the interface into several iterations.

There is always the desire to make users happy. Still, designs can go wrong. One reason designs go wrong is the people involve have become so proficient in what they are building that they can no longer perceive the areas that can cause trouble to the user. Designers know too much and are accustomed to the software that no matter how hard they try, they can no longer put themselves in the role of a viewer. Predicting all the problem users will have, or the errors that will get made is an impossible task. The only way to know these problems and errors is to observe users and learn what they do. While designers are expert in the software they are working on, users are expert in the task they are trying to perform with the software.

Sometimes, teams are not allowed to talk to end users. The most common reason is fear of the designers telling the users too much. Sometimes, teams work for clients who may be concern about price and schedule but not on usability. Often, designers depend only on requirements that have been filtered by the people from marketing, support, and from the office of the CTO and CEO who all believe they have a better understanding of what the users want. Sometimes, they also have an opinion on how things should be designed which aggravates the situation the designers are into.

Design failures also happen when it is done not by designers but by programmers (sometimes by managers). Programmers know the value of simplicity in implementation and all things being equal, they would rather do the simplest solution that would work. This is a sound principle because as code grows, complexity rises exponentially. By implementing simple solutions, code becomes less costly to maintain. When one design option requires more code than the other, it is just natural for programmers to choose the design that requires less code to implement.

The factors working against good design are not hurdles that can be solved by a technical solution. Designing user-friendly software starts with the right mindset. It is very common for technical people to call users stupid every time they receive a complain for what is seemingly a trivial task. In this kind environment, no user-friendly software will ever get produced.

Some think good design is just common sense. While it is true that knowledge of quantum mechanics is not a prerequisite to good design, thinking that design is just common sense leads us to believe that we know what users want. We can guess and try as hard as we can but only by asking and observing users we will know what they want and the problems they are facing.

The right mindset knows that users are different and exactly opposite of you. What is easy for you, is hard for them. What is trivial for you, takes a lot of time for them. Users don’t think the same, don’t act the same, and don’t have the same experience as you do.

Related posts:

1. How to create Google-friendly URLs in Rails If you are building content-management systems or any applications with pages that you want to appear in a Google search, it is very important that you employ search engine optimization...
2. I hope the software works Do you tell this to yourself every time your team releases a version of your software to your customers? Are your customers spending more time filing bug complains than actually...
3. Beware of the usability Stockholm syndrome The only way they to know if an application works well for users is to conduct usability testing. A usability test does not need to be expensive like having a...