Usability and Response Times in a Networked World

"Well, let's say you can shave 10 seconds off of the boot time. Multiply that by five million users and thats 50 million seconds, every single day. Over a year, that's probably dozens of lifetimes. So if you make it boot ten seconds faster, you've saved a dozen lives. That's really worth it, don't you think?"

- Steve Jobs

Clearly, there is a correlation between user interface response speed and the perceived usability of a site or app. But what does "response time" mean in a world of mobile applications, mash-ups, single page applications, and ajax?

For decades, the response times outlined by Jakob Nielsen (referencing a much earlier article) have been a baseline for how user experience professionals think about the response time of an application. These guidelines are a great starting point for thinking about usability, but applications have evolved and we need a new approach to thinking about response time.

Chrome TimelineIn Google Chrome, there is a developer tool called the Timeline (IE has an identical tool in their F12 Developer Tools under the Network tab) that shows details of what occurs when any page loads. Using profiling tools, we can see the web page and its dependent parts, such as images, styles, and ajax calls, all load at different times. Each request to the remote server has several parts:


  • Request start time
  • Time it takes for that request to be sent and received by the remote server
  • Time before the request gets an initial response from the server
  • Duration of time between the beginning of the response and the end of the response


If a page must load from a remote server, and that page contains ten images, then we see graphically that there is a period of time spent loading the initial HTML, then new requests back to the server (or perhaps a CDN), one request per image. The images each take more than 0 milliseconds to return from the server, and they load later.

When usability professionals or developers think about response time, we often think about the time it takes to render a screen. With dynamic pages, the concept of screen becomes completely fluid, and this frame of reference is no longer appropriate.

Take Google Image search for example. When you search for any word, you perceive a collection of results being loaded immediately. However, using the Chrome Timeline feature, we can see that the page's initial load time is not the whole story. The images and page results load in about 3 seconds, then some ajax scripts load later clocking in at almost 8 seconds. Since I'm searching for images, seeing those early is a good user experience. 

If I scroll down after everything loads in my image search, suddenly more network activity begins and more images are loaded into view. As I continue to scroll, the timeline and the list of items being loaded continues to grow in my Timeline. 

The way to design around response time in a networked application should not necessarily be related to the page load time. Instead, focus on specific user experience paths:


  • Relevance: Is this page relevant to me? Your response time should be oriented around answering this question quickly for a user. Other details of a page or screen can load later, but a user navigating to a new view of an application should be able to quickly see if what they are viewing is relevant. In the Google Image Search example, this means showing a small collection to the user quickly so the user can decide whether it is necessary to refine their search terms. In the case of a drop down menu, it means showing the contents of the menu quickly to allow the user to determine if this menu is the correct one to look inside. Think about times you have looked around in your computer for the correct Control Panel setting. Optimize for the scenario of at-a-glance decision about overall relevance.
  • Context: How can this view or screen support my goals as a user? Optimizing response time to provide the user quick orientation for the sections and structure of a view, page, or screen will help support the perception of speed. Give the user orienting cues about the structure of your page early so those first milliseconds can help guide them to discovering how best to achieve their goals.
  • Bailout: Optimize any loading page to allow the most clear bailout path in the event that this turns out not to be where the user should be.
  • Best Next Action: Optimize any loading page to direct the user to the next best action. This may be choosing from a list of links to navigate somewhere, or it might be three buttons that capture a decision. One aspect of this that is in the direct control of developers is setting the cursor focus, for example defaulting the cursor to be focused in a text box, or defaulting the "Enter" key to click a particular button.
  • Priority: For any given page, separate elements by user goal priority. The highest priority items should load first, the lowest last. 


As networked applications become the norm, it will become important for us to make more clear distinction about what we mean about response times. 


The USE Framework

The USE Framework by Steve LandThere have been a few projects recently where I have seen UX designers produce great designs that later turned out to be a poor fit for the project. Some designs required more custom development than necessary, introduced new requirements for support by the business, or simply blew the project scope out beyond what was desired by the client.

This led me to wonder if there might be a way to map the constraints of the project and the system on to the process of designing a user experience. 

Presenting: the User-System Experience (USE) Framework. A lot of great stuff has been written about designing for people, and the skills, knowledge, and intuitions of UX designers has evolved a lot through time. This framework is designed to give the big picture showing the entire context of forces that impact UX design.

The word "interface" literally means an interconnection point between two systems. In the case of a User Interface, the design always happens in context of a system, and always in context of a user. Personas, User Stories, and other tools give us visibility to user goals, but there is another side to consider: the system itself. We need to begin to have new ways to capture the goals of the system provider in a similar way that we now capture user goals, to make the interface itself fit perfectly.

Systems are provided to people by companies and individuals for a purpose. The system must be developed. The system must operate once it's deployed. 

Users are people with goals, knowledge, and competencies. Their experiences are shaped by their perceptions, and their ability to interact is limited by constraints.

This framework will be evolving a lot in the next few months. It's a first draft now. Please follow me on Twitter and let me know if the framework is interesting, useful, or if you can suggest any improvements.


E-Commerce, except when it's not

The Washington State Dept of Transportation set up automated tolls on the 520 bridge on December 29, 2011. The tolls are applied automatically through a system that recognizes your license plate. To avoid higher tolls, the DoT sells pre-paid passes called Good To Go!

To get a pass, you simply create an account online and make a payment using a credit card. 

On the Good To Go! site, you can view your account and see your current balance. 

All of this automation and e-commerce works fine, up to and until your account is charged past a $0 balance. Once your account goes negative, there is nothing you can do online to correct it. You are forced to call customer support.

The first time this happened to me, my account was negative $0.20. 

So, instead of going online, re-entering my credit card, and making my pre-paid account positive again, I am forced to find the customer service phone number, listen to all the language options in the phone system (there are more than two to choose from, no default), and then listen to the menu options before discovering how to get to customer support.

This is broken.

Once I get a human on the phone, I do exactly the same thing that I should be able to do online: give my current credit card, choose an amount to pre-pay, and authorize the transaction. 

"I think I should be able to do this online and not have to call to pay." I said to the operator.

"That is how the system works"

"What is the reasoning behind forcing us to call when it's negative?"

"It's set up that way"

Frustrated, I reply: "I understand that this is how it is currently set up, but don't you see that it makes no sense to work this way? I am doing the same thing here on the phone that I could have been doing online, if only you supported it."

This is just plain bad design, or worse, accidental design through lack of attention to detail. The scenario "What happens when someone's balance is negative" probably was not considered.  

The solution: allow balance payments regardless of current balance.