If that number surprises you, it should. The study took place in 1994.

The bar is exponentially higher now for people involved in website user experience design and development when it comes to load speed. Here’s a quick look at the state of affairs.

Slow speeds are a real usability challenge. According to software and monitoring experts at Gomez and Akamai, most users (up to 73%) have encountered a site that was too slow, crashed, froze or otherwise didn’t perform.

Your visitors’ expectations are high. A sizeable 47% of consumers expect a page to load in 2 seconds or less, and 40% of people will abandon a page that takes more than 3 seconds to load.

Slow load speed can be a costly challenge. These sources estimate that a 1-second delay can lead to a 7% drop in conversions, meaning that an e-commerce site doing $100k daily would experience a $2.5M loss in sales on an annual basis tied to 1 second in load speed.

If you’re curious about the impact of load speed on conversions, and want to learn about users’ expectations for mobile browsing vs. desktop browsing, KISSmetrics has built a stellar infographic on the topic.

Mozilla ran a study to test a similar concept: what happens if the development team combines files and rearranges the source to make the Firefox home page load 2.2 seconds faster? You guessed it. Conversions increased dramatically. Firefox saw a 15.4% lift in browser downloads.

If all of this weren’t compelling enough, you should also know that organic search results can be negatively affected by slow load times. If you run search engine advertising, you’re familiar with quality score—Google’s determination of how ‘relevant’ your ad is—and you know it impacts the per-click price of your ad. Landing page speed is part of the quality score determination, too.

You get the point. The need for speed is great, and there’s a lot at stake.

What can you do to improve load speed?

There are a lot of solutions for improving how quickly your site loads. Some are simple and quick to implement, and others are tougher to tackle. Here’s a strategy to start moving your site in the right direction.

Run speed tests. Use Google’s PageSpeed Insights tool. See what easy-to-implement suggestions it spits out and heed the recommendations.

Then run your site through the Pingdom speed tool. How many requests have to be done to load your site? Are there tracking scripts that might be outdated or aren’t needed anymore? Can you consolidate any of the other requests?

Knock out the low-hanging fruit changes. Some of the recommendations you might receive include things like:

● Minimize HTTP requests.
● Resize and optimize images.
● Optimize multimedia.
● Convert JavaScript behavior to CSS.
● Use server-side sniffing.
● Optimize JavaScript for execution speed and file size.
● Convert table layout to CSS layout.
● Replace inline style with CSS rules.
● Minimize initial display time.
● Load JavaScript wisely.
● Create a dedicated landing page for mobile.

Install plugins to simplify your process. Your content management system might have plugins available that’ll make your life easier. For example, here are a couple of popular WordPress plugins that help with load speed in various ways.

W3totalcache improves site performance by improving caching with respect to the browser, page, objects, database and more. To learn more about this, you can read up on configuring the W3 total cache plugin.

WP Smush.it—Especially if you’re a blogger, you probably use plenty of images, and images can take considerable time to load. This plugin reduces image file sizes and improves performance by compressing the files.

WP Optimize—This plugin allows you to clean up and optimize your database, especially if you’re a blogger with significant archives.

When in doubt, simplicity is key. Don’t be afraid to gut components that increase load time and A/B test simpler versions of the page against their predecessors. You may be surprised at the impact of a faster loading page, even if it suddenly has less of the stuff you once considered critical.

Toby Biddle is a seasoned website usability expert and CEO of Loop11, a tool for unmoderated online user testing.

Footnotes and sources

1 Nielsen, J. (1994). Usability engineering. London: Morgan Kaufmann.
2 You can learn about the Mozilla site speed case study here.

Anything that slows down customers or gets in their way after they download your app is a bad thing. That includes sign-up/sign-in forms that show up even before potential customers can figure out if the app is actually worth using.

It’s a simple UX equation

This antipattern seems to be going away more and more as companies are beginning to figure out the following simple UX equation:

Long sign-up form before you can use the app = Delete app

However, a fair number of apps still force customers to sign up, sign in, or perform some other useless action before they can use the app.

Example

The application SitOrSquat is a brilliant little piece of social engineering software that enables people to find bathrooms on the go, when they gotta go. Obviously, the basic use case implies a, shall we say, certain sense of urgency. This urgency is all but unfelt by the company that acquired the app, Procter and Gamble (P&G), as it would appear for the express purposes of marketing the Charmin brand of toilet paper. (It’s truly a match made in heaven—but I digress.)

Not content with the business of simply “Squeezing the Charmin” (that is, simple advertising), P&G executives decided for some unfathomable reason to force people to sign up for the app in multiple ways. First, as you can see in Figure 1, the app forces the customer (who is urgently looking for a place to relieve himself, let’s not forget) to use the awkward picker control to select his birthday to allegedly find out if he has been “potty trained.” This requirement would be torture on a normal day, but—I think you’ll agree—it’s excruciating when you really gotta go.

Figure 1: Registration Torture: Sign Up/Sign In antipattern in SitOrSquat app.

But the fun does not stop there—if (and only if) the customer manages to use the picker to select the month and year of his birth correctly (how exactly does the app know it’s correct?), he then sees the EULA (Figure 2), which, as discussed in the previous article, End User License Agreement (EULA) Presentation (Boxes and Arrows January 2nd, 2013), is an antipattern all to itself.

Figure 2: Reading the EULA while wanting to pee should be an Olympic sport.

SitOrSquat’s EULA is long, complex, and written in such tiny font that reading it while waiting to go to the bathroom should be considered an Olympic sport, to be performed only once every four years. Assuming the customer gets through the EULA, P&G presents yet another sign-up screen, offering the user the option to sign in with Facebook, as shown in Figure 3.

Figure 3: Finally! Sharing my bathroom habits on Facebook has never been easier!

I guess no one told the P&G execs that the Twitter message “pooping” is actually a prank. They must have legitimately thought that they could transfer some sort of social engineering information about the person’s bathroom habits to “achieve and maintain synergistic Facebook connectivity.” I would have to struggle hard to find monumental absurdities from social networking experiments that are equal to this. I can’t imagine that anyone thinks “Finally! Sharing my bathroom habits on Facebook has never been easier!”

Assuming that the user is a legitimate customer looking to use the bathroom for its intended purpose, and not a coprophiliac Facebook exhibitionist, we may hope that he will naturally dismiss the Facebook sign-in screen and come to the next jewel: the Tutorial, shown in Figure 4.

Figure 4: Tutorial is a sub-par Welcome experience pattern. Here it is another impediment to progress.

SitOrSquat tutorial is an extra screen that provides very little value, other than impeding the use of the app for its intended purpose. (If you need a tutorial, I recommend a much more effective contextual Watermark pattern, which I discuss in Chapter 5 of the Android Design Patterns book.)

50 Taps and 7 Screens of Antipatterns

Note that the entire app outside of registration consists of basically four screens (if you count the functionality to add bathrooms!). However, if you include all the sign-up antipattern screens (including my initial failure to prove that my potty training certificate is up to date, as referred to in Figure 1), it takes seven screens of the “preliminary” garbage before the content you are looking for finally shows up (refer to Figure 5). If you count the number of taps necessary to enter my birthday, that becomes almost 50 taps!

Figure 5: The Glory of 50 taps needed to get through the Sign Up/Sign In antipattern in SitOrSquat app.

One of my favorite UX people, Tamara Adlin (who coauthored The Persona Lifecycle: Keeping People in Mind During Product Design with John Pruitt) wrote brilliantly: “For Heaven’s Sakes, Let Them Pee.” I believe that never before has this line been so appropriate. In the absurd pursuit of social media “exposure” coupled with endless sign-up screens, with heavy-handed “lawyering up,” P&G executives completely lost sight of the primary use case: letting their customer SitOrSquat.

Long sign-up screens detract from the key mobile use case: quick, simple information access on the go. Overly invasive sign-up/sign-in screens presented up front and without due cause will cause your customers to delete the app.

There is no reason to force anyone to register for anything

When deciding whether to force the customer to perform an action, consider this: If this were a web app, would you force the customer to do this? If you have Internet connection, you can save everything the customer does and connect it back to his device using a simple session token and a guest account. And even if you don’t (for example, while riding in a subway, using airplane mode, and so on), today’s smartphones have plenty of on-board storage you can use for later syncing with your servers when the mobile network eventually becomes available.

This means there is simply no reason to force anyone to register for anything, other than if they want to share the data from their phone with other devices. As a general rule, rather than forcing registration upon download or at the first opportunity, it is much better to allow the customer to save a piece of information locally on the phone without requiring that he log in. Wait until the customer asks for something that requires registration, such as sharing the information with another device or accessing information already saved in his account; at that point completing the registration makes perfect sense.

For example, imagine how absurd the Amazon.com shopping experience would be if the app asked you for your home address, billing address, and credit card upfront—before allowing you to see a single item for sale! Yet entering the home address (where would you like to have the items shipped?) and credit card (how would you like to pay for this?) makes perfect sense during the checkout, after the customer selects a few items and indicates she would like to complete the purchase.

Finally, remember that “Forms suck,” as brilliantly quipped by Luke Wroblewski in his book Web Form Design (Rosenfeld Media, 2008). Only ask for what you strictly need to proceed to the next step and omit extraneous information. (Effective mobile data entry controls and forms is a huge topic to which I devote chapters 10-12 of my upcoming Android Design Patterns book (Wiley March 11, 2013), now available on Amazon.com).

A couple of years ago, I was asked to speak about “design thinking” at a web conference. The conference-speaking part was nothing new, but the topic certainly was. With the “design thinking” wave having just recently peaked, I had yet to even come up with a clear definition of the term. So I accepted the challenge and went about the business of putting a wrapper around the idea so I could map it to our work as strategists and designers.

What I found was a bit of a joke. The few snake-like definitions I was able to charm out of the depths of the interweb with magical flute-playing were no better, no worse, and no different than definitions of “interaction design,” which were in turn no different than definitions of “problem solving,” which we as a species have been doing since the dawn of humanity. So what was the big deal about design thinking? Well, the big deal was that some designer douchebag decided one day to rebrand “user experience,” presumably to bring his agency a few new dollars. Leader of IDEO or not (I’m talking to you, Tim), rebranding a profession for no good reason is not a noble nod to semantic precision, but an exercise in self-importance.

Besides this, it bothered me that those among us who spend our time fighting the good design fights were acting like we had nothing better to do, as if the world would solve its own problems while we were over in the corner deciding what to call our particular brand of ice cream. And it was at this point that I decided I no longer gave a fuck.

It doesn’t matter one bit what you name the band, it matters how good the music is. The reputation you build around the name will outlive even the stupidest, most drunkenly attempts at a moniker cool enough to guarantee future rock god glory.

And most importantly, while we were all busy debating syllables and word pairs, the world at large caught onto the moniker we’ve been using all along. On a near-constant basis these days, the term “user experience” is used by people whose expertise is in raising kids, or selling insurance, or milling sugar. It’s used by people who have no business even knowing what “user experience” means. It appears in dinner table conversations. It appears in write-ups about apps, devices, and gadgets galore. It’s in magazines, on television, and online.

“User experience,” as a term, is weak, ineffective, and inaccurate. But although I am among the many in our profession who believe this sad title we’ve assigned ourselves becomes less potent with each utterance, I happen to also believe we should guard it with our proverbial lives. “User experience,” like it or not, has become a household name. And the best chance any of us has at legitimizing a profession that invariably begs further explanation and qualification is to make it as easily recognized and banal as “carpenter” and “motorcycle mechanic.”

“User experience” either is or isn’t the best term to serve as the concrete beneath our careers. And we either give a fuck or we don’t. It’s our choice.

Let’s stop talking about what it’s called and start solidifying the world’s understanding of it. Some people build cabinets. Some fix motorcycles. We design sites and apps. It doesn’t matter how we do it. It matters how easy it is to accept that it’s real, it matters, and is a sound career path to describe when you meet your girlfriend’s parents over Thanksgiving dinner.

Fuck title debates. “User experience” has momentum. Let it roll, and get back to work.