Join the early bird Black Friday list

Black Friday is just around the corner, and we’re excited to offer early access to our best deals of the year at shop.learningloop.io. If you’re looking to elevate your brainstorming sessions and streamline your team’s workflow, our printed card decks are here to help.

Want to get in before everyone else?
Join our Black Friday Early Bird list to be the first to know when discounts go live! We’re launching the sale early this year, so you can grab your deck and start putting it to use before 2025 even begins.

Join the list

Since AJAX became popular in web design, web applications has started to look much like desktop applications and has as such begun to suffer from some of the same design flaws. What I especially want to rid the world for is load indicators and meaningless error messages.

Load indicators remind me of the spinning beach ball in OS X or the animated hourglass in windows. They each represent a static state where the system is frozen and I am locked out not able to do anything!

How do you measure speed? Buying the fastest servers available and optimizing the hell out of your application will certainly do much, but it will not change the fact that you want to change the speed of your application that your users perceive. Whether this speed is improved by throwing a gazillion GB og RAM and MHz at your servers or merely setting up a few rules for how you design your application is up to you.

A few such heuristics could be:

  • Ban load indicators! Get rid of unresponsiveness. Do not take the user as a hostage while he or she waits for an operation to finish. This could be expressed as getting rid of the wait cursors – they are a sign of bad design; Do something else instead. Even though 30 boxes use load indicators in their calendar, the application is far from unresponsive.
  • Eliminate extra steps. Go through your application and count clicks and screens needed to perform an action? How can they be minimized?
  • Let the user know how far they’ve gone. Your application will seem unresponsive if you do not provide your users with a clue of how long lengthy operations will take. Failing to let the user know how far they are in a process will create more problems for your in the long run: how are you supposed to do with the data a user has entered in a Wizard if he or she drops out in the middle?
  • Continue or abort. Your system should be able to recover from its own problems! Sure, the user cares about what went wrong, but it is not their problem. It’s yours! Do something proactive instead than asking them if they want to continue or abort because your system caused an error.
  • Perform client-side validation. Instead of letting the user take an extra roundtrip to your server and back to validate the date they’ve entered, perform client-side validation of their data and save them the trip.
  • Preload data. You create a Google AdSense ad by clicking through a 3-4 screen wizard. What most do not realize is that the entire form of all 4 pages is loaded at once. This means that clicking next merely releases a javascript action that hides the current screen and displays the next. A similar thing is seen in the Facebook picture gallery where preloading the next images makes the experience seem super smooth. On top of that, the <a name /> value is changed each time an image is clicked, so that the URL will always point to the image you’re viewing.

To sum things up: Design for responsiveness! The software should be able to keep up with its users and not let them wait. What really matters is the perceived speed and not the actual real (machine) speed.

Anders Toxboe Author

Based out of Copenhagen, Denmark, Anders Toxboe is a Product Discovery coach and trainer, helping both small and big clients get their product right. He also founded UI-Patterns.com and a series of other projects. Follow Anders at @uipatternscom.

1 comment

  • Home Page Redesign on Aug 28, 2009

    Great tips

Comments have been closed