We believe there is something unique at every business that will ignite the fuse of innovation.

Apps on Phone Many businesses have developed great-looking apps that perform poorly, causing users to abandon the apps and try again later or, worse, shift to competitors’ apps. That hurts the brand as well as the bottom line.

High-performance apps are key to delivering a positive user experience. This blog discusses key facets of application performance and how you can improve these in order to meet user expectations.

User expectations are high. Research by Kissmetrics indicates that 80% of users will abandon an app if it doesn’t respond within 20 seconds. After an app has crashed twice, only 16% of users will give it a third try, according to a study by Compuware.

Each time your users have a negative experience with your app, your value is diminished in the minds of these users. Most will give you one or two strikes before giving up; three strikes would be unusually generous.

To ensure that your app doesn’t fall short, you need to work on two key facets of application performance: the responsiveness of the user interface (UI) and the responsiveness of the servers from which the application retrieves data.

UI responsiveness

Among questions that merit consideration as you assess UI responsiveness:

How quickly does the app respond to the user’s touch? The rule of thumb is that as soon as the user lifts his or her finger from the screen, it should be evident that the app is doing something. If the user isn’t lifting the finger but is instead scrolling or doing a pinch-and-zoom movement, the app should provide visual indication that it is responding as soon as the finger moves.  

How smoothly does the UI scroll? If the user is looking at a list of information and flicks his or her finger up or down, the UI should scroll without lagging. Scrolling should take place at a minimum of 60 frames per second. Slower speeds will give the application a shoddy look and feel.

How quickly does the app start? The optimal start time is in the range of one to two seconds, measured from the instant the user taps the app icon on the home screen to the instant the app is ready for productive use. A start time of 20 seconds would feel like an eternity to your users.

There are many ways to optimize start time and ensure that your app is ready for productive use the instant the user opens it. One way to do this is by fetching information in the background, before the user starts the app. This can be done via push notifications.

You can send a push notification to the app and have it pre-fetch information that you think the user may need. To determine which users to send this information to and what information to send them, you need to understand user behavior, in some cases at the individual level.

Another method you can use to improve start time and responsiveness is to leverage the ample on-device storage provided by modern phones, which can store data between sessions. If your app stores transaction history, for example, it can store the history between sessions and retrieve only those changes that have occurred since the last session.

How quickly does the app move from screen to screen? If the user taps on a control in your app and wants to go to the next screen, it’s essential that the movement take place immediately. I’ve used many apps where each screen presents a wait spinner. When the user goes back to the prior screen, there’s another wait. Users will quickly abandon an app that forces them to wait from screen to screen.

A better approach: Pre-fetch the information that users will need for follow-on screens, just as you pre-fetch information that will minimize the app’s start time. Analytics will give you a good idea of the sequence that users follow as they move from screen to screen, so you can pre-load the appropriate data for upcoming screens.

How efficient are the workflows? Does your app require that users make numerous decisions and go to many screens in order to complete a single transaction? Are you forcing a web paradigm on a mobile app, requiring users to enter a lot of data and behave as if they were on a public web browser (i.e., not allowing the app to remember things from screen to screen)? In all likelihood, users of your app are using privately owned devices and are in a rush. The app should help them complete tasks as quickly as possible.

Data-driven, quantifiable usability testing is key to understanding how users interact with your app in the real world. Through quantifiable usability tests, you can uncover where users get confused by your workflow, what parts of the workflow take the most time, and where users abandon the workflow.

Are you using the information you already have? All too often, apps ask for information that is already known; for example, the user’s location. This not only slows transactions, but it also annoys users. It’s worth remembering that apps can learn. If you know that a given user conducts many different kinds of transactions, find out what that user does most often—for example, checking the balance of a 401(k) account and the price of a particular stock—and put that up front rather than burying it and forcing the user to repeat the same flow session after session.

Are you using UI paradigms that are not optimized for mobile? If you require that users type extensive information on the keyboard, that will be time-consuming and frustrating. Enabling users to select items from a list is much faster.

Server response time

Server response time manifests itself as UI response time but is managed very differently. Among questions you’ll need to consider in evaluating server response time:

How quickly do your APIs respond? You need to be aware of how long your API calls take, and how many of them you do for each kind of operation performed in the app. For example, if your app does 10 separate API calls each time it starts, that will greatly slow the app’s start time. With respect to the user experience, 10 separate API calls to your servers will increase slowness by a factor of 10. It also introduces 10 places where a network call may fail, preventing use of the app.

It’s important to understand how the APIs perform under real-world conditions. Use load-testing to place stress on your servers and identify performance degradation when the servers are used by many people at the same time. Load-testing can uncover problems that don’t appear when only one or two users access the app, but appear when dozens or hundreds of users eagerly access your servers. These problems can include excessive logging, contention on the database, and other choke-points in your code.

Do you really know how often your app calls your servers? Even if you built the app in-house, you may not understand exactly what’s going on. Using a tool such as Charles Proxy, which sits between the app and the services and captures all interactions between the two, will give you information that you can use in performance testing. The information will enable you to accurately replicate your app’s behavior during load testing or stress testing. It will also enable you to determine how many concurrent users the app accommodates at peak times, so that during testing you can determine what happens under peak loads. Understanding how the app really uses the services will give you insights necessary to reduce the realized load on the servers and make the app even more responsive to the user.

What’s the impact of push notifications? The impact of push notifications is a hidden “gotcha” in the world of mobile. Studies show that up to 40% of users may respond to push notifications, which can overwhelm your servers. A common flow for a system is to run a batch program that generates push notifications to a subset of your users; the users then receive the push notifications and—if you’ve done a good job targeting the notifications—many will open the notification at the same time. This generates a tsunami-like load on your servers. It’s like yelling “Free pizza!” in a college dorm. Expect a vigorous response.

It’s essential that you examine your target audience and the kinds of push notifications that you send. For performance testing, it’s also essential that you develop a load model that reflects these real-world factors.

You should investigate how to spread the load of push responses over a longer period of time. If you use the same servers to send out push notifications that you use to handle the responses, you’ll slow the servers significantly. Tools such as Urban Airship will allow you to generate notifications and schedule them for future delivery, spreading the load over a longer period of time.

Meeting user expectations

At CapTech, our consultants have the expertise to help you make your apps perform under the highest possible load of user expectations. We have developed a highly refined usability test process that gives us quantitative data regarding the efficiency of workflows and that indicates where users struggle with workflows and where they will abandon the app.

We also have tools that quantify app start time and other app performance characteristics. Our data-driven usability testing enables us to compare workflows quantitatively, indicating which workflow has the highest success rate.

Your users expect rapid responses. CapTech can help you deliver them.

About the Author

Jack CoxJack Cox has over a decade of experience helping Fortune 500 clients build mobile strategy through technology, security and cryptography. He is a software developer, systems architect, and a Fellow at CapTech where he is responsible for the firm’s mobile software practice. Jack’s love of software development and all things mobile has driven a career developing software for businesses of all sizes including large-scale transaction processing systems, embedded software, and smart-phone software. Jack co-authored the book ‘Professional iOS Network Programming’ (Wiley). He has been involved in several startups, holds multiple patents and frequently speaks nationally. Jack is based in CapTech’s Richmond, Virginia office and helps clients both locally and across the US.