Performance Perception in Mobile Application Development

Mobile applications are one of the most popular forms of software on the market. At the start of 2018, there were 3.8 million apps available on Google Play, followed by 2 million on Apple. (This isn’t counting those exclusive to the Windows Store, Amazon Appstore or Blackberry World.) 

A good mobile application is now imperative for any company that wants to remain competitive. That doesn’t just mean one that performs the job, but one that’s attractive, easy to use and performs well. 

This is easier said than built. 

Even small snags in performance can provoke an inordinate amount of frustration. Often, it’s small, even imperceptible differences that make the difference between a smooth, responsive application and a disjointed, aggravating one.  

We can break UX/UI performance into two separate categories: actual performance  and  perceived performance. Both are important, but very different.

Take the example of weather services. Reports include a ‘feels like’ temperature alongside the actual quantitative degree measurement. Factors like the wind, humidity, proximity to the ocean or elevation level can make temperature feel hotter or colder than an objective reading indicates.

 

A similar concept applies to performance. Our application might operate at a given efficiency, but certain design elements can alter the user’s perception of how well it performs – for better or for worse.  

So, what is actual performance?

Actual performance refers to how quickly tasks are performed in an application, i.e. how fast visuals are loaded, how quickly it renders and displays frames to the user. 

The biggest factor affecting actual performance of an application is the browser rendering process. For developers, this means that we need to optimize our code so that browsers can run the application efficiently.  

This is particularly important when we’re dealing with more intricate layouts and animations, which designers often include to appeal to users. A poorly designed animation could have an adverse impact on performance, and any aesthetic appeal it may have added would be far outweighed by the frustration caused by a lagging or crashing application.

The importance of perceived performance

Perceived performance has less to do with the technical capabilities of the app, but rather, building in regular feedback mechanisms to keep in constant communication to the user. This could be through: 

• A loading indicator 
• A message on screen 
• An animation 
• A style change on a button 
• A vibration 

The general idea is to hold the user's hand through an interaction, from start to finish. At every step, we want to reassure the user that everything is working as intended and, if possible, provide an estimation of the time it will take to complete a task.

Before we get into the specifics of what this might look like in a mobile application, let's consider a real-life scenario.  

Imagine that you are ordering some fast food, but, for various reasons, your food is delayed. We’ll imagine this same scenario played out twice. In both circumstances you are left waiting for the same amount of time (i.e. the actual performance is the same), but the way this process is handled is different (i.e. the perceived performance).

Scenario 1:

• You place your order 
• You wait for 20 minutes 
• You receive your order 

Scenario 2:

• You place your order 
• You are given a device that informs you of the current status of your order 
• The status of the order is currently "Cooking!" 
• You get a message saying "Sorry, we have run out of fresh fries! A new batch is being cooked right now."
• You get a message saying "Your order is almost ready! Thanks for your patience."
• You receive your order 

In both of those scenarios, you get the food in the exact same amount of time.  

However, in the first, most customers would quickly become frustrated after the unexplained wait time. In scenario two, customers would be more likely to understand, and – despite the exact same wait time - they would leave feeling significantly less aggravated.

 

We could consider a similar situation in the context of a mobile application. Let's suppose that we were going through a login process that involved a brief delay as a call to a server is made.

Scenario 1:

• Click login
• Wait
• Arrive on home page 

Scenario 2:

• Click login 
• Display loading overlay during wait
• Arrive on home page 

The loading time in both scenarios could be the same. However, by adding in a loading overlay, we keep the user engaged and informed about the process.

In the first scenario, the following might be going through the user's mind:

After clicking log in, "Did I miss the button?"  

Tapping again, "Did it freeze?!"  

After it begins to load, "Oh - it worked."

Whereas in the second scenario, it is much more obvious what is happening in real time.  

Skeleton UI 

Although we can provide feedback to the user using simple methods like displaying a message or animating a button, we can also use some more advanced methods to provide feedback and increase perceived performance. 

A 2014 MIT study showed that humans can perceive discrete images in as little as 13 milliseconds. However, deciding where to focus takes between 100 and 140 milliseconds. In practical terms, this gives us around 200 milliseconds to present a user interface state change for it to appear instant.

This means that if we are attempting to load in some content and we can display it on the screen within 200ms, we don't need to worry about our user becoming distracted from their current task and perhaps even closing the mobile application. 

However, 200ms is not a lot of time to play with. If you were attempting to load in data from a server, chances are that it will take more than 200ms to load the content and display it on screen. 

This is where we can use the concept of skeleton screens, where we display some 'fake' content that mimics what the structure of the real content will look like. While we are waiting for the real content to load in, we can display something to the user while they wait. Wherever possible, we want to be able to display state change to the user within that 200ms. 

Facebook uses this concept when loading their news feed. Before the actual content appears, you will see something that looks like this:

 

This requires no new content, but it makes the user feel like something of significance is happening. This is even better than just displaying a loading overlay, because it gives the perception that we're not just waiting for something to load, but that we're already making progress.

Again, this is not the case. In no way is this making the content load any faster, it just makes it feel like it is. For a user, in many cases, that's almost as important.

Skeleton Splash Screen

We can extend this concept even further by incorporating the splash screen.

Rather than having a splash screen that is just a pretty picture with your logo overlaid, you should instead have a splash screen that resembles the shell of your application. This is actually what is recommended by Apple: "Apple have incorporated skeleton screens into their iOS Human Interface Guidelines under the name 'launch images'. Apple’s guidelines recommend showing an outline of the initial application screen excluding text and any elements that may change."

Carrying on with the Facebook example, the splash screen for the Facebook mobile application looks like this:

Their initial launch screen follows Apple’s guidelines:

 

Having met the goal of the initial guidelines, Facebook now populates more of the screen with the header, footer and placeholder images in the body. There is also a subtle animation on this screen in place of a spinner.

 

Above, the final UI is loaded.  

Balancing Speed and Quality

This is a simple but common example of how we can increase perceived performance by providing simple feedback to the user. 

This is especially important when there is no way around a wait time. Today’s users expect a response within 80 rapid milliseconds – anything longer, and the user experience begins to feel clunky.   

If increasing actual performance means a mammoth amount of work on the backend, there isn’t much we can do in a short space of time. However, we can always make small tweaks that will work wonders on perceived performance.  

Arguably, the actual performance of your mobile application is more important, but spending time on improving little details that contribute to perceived performance can make a huge difference to your user’s satisfaction, and your brand’s reputation.