Mobile App Performance: Performance is a Feature
By Rachel Obstler | November 4, 2015
When I stop using an app, why is that? Sometimes it’s because it doesn’t have the functions I wanted or needed, but this is rare; I already knew what, for instance, Uber did before I downloaded it. It can happen with pure entertainment apps (e.g. that game wasn’t fun), but most apps I download because I already have a relationship with that brand (think of your airline, any stores you frequent, social media you use, work-related apps).
I sometimes stop using an app because it is hard to navigate or figure out. But as app design improves, this is also getting rarer.
Most of the time when I stop using an app (fall back to using the website, call the company, or just don’t use them altogether, because picking up the phone or being at a computer seems more and more inconvenient nowadays….) it’s because of performance.
You may be surprised that I say performance is the biggest cause of not using an app (or you may not.) In either case, think of it this way: when performance is good, no one notices it, but when performance is bad, when for instance it takes over 30 seconds to launch an application – then it becomes everything. The fact is, not many people will wait that long to use your app, so all the functionality and UI design in the world won’t matter – your customers will never see it. I tell my engineers this all the time; you don’t get partial credit for delivering a beautiful application with wonderful features if it’s so slow no one will use it.
With my customer hat on, poor performance means three things to me: 1) the app takes too long to launch, so I give up or 2) I’m in the app trying to do something, and it takes too long, so I give up or 3) I’m trying to do something and it takes too long and I wait for a response anyway and it doesn’t work. With my professional hat on, I know that these issues can have several underlying and sometimes overlapping causes. For instance, app launch time is often technically not the issue (from the OS’s point of view, the app is running), but the app is designed such that immediately upon launch it downloads a bunch of content and while that is happening, the user cannot do anything. Lengthy transactions or transactions that are long and ultimately fail can have several underlying causes. One common cause is heavier than expected load. Another is simply poor design.
So how do you ensure that your mobile applications don’t have these types of performance problems? There are a number of best practices I recommend, and this series of blog posts will cover them all. But we’ll start with the first: set performance targets.
I recently worked with a customer that had a mobile application. They developed their iOS version in house, but outsourced the Android app. The Android app was practically unusable, with common transactions like find a store taking over 20 seconds, and when the external company was asked to improve performance, they submitted a hefty price tag for the change request. It turned out the entire architecture of the app needed to be changed to support the new requirement and the customer was stuck, because they indeed had not provided a performance requirement to the agency building the Android app.
This also illustrates another point – just like any issue that needs to be fixed, the farther along you are in the application lifecycle, the more it costs. As a best practice, performance targets need to be set at the very beginning of the process, in the requirements phase.
If you think of performance as a feature, you’ll ensure that it gets considered at every phase of the development process.
Now, most of the readers of this blog are in the mobile application development or testing profession. Presumably the task of setting performance requirements belongs to the product team. So what, then is the development and QA teams’ responsibility to setting performance targets? It’s to demand them. I’ve been in the product management organization for many years, and I’m always pleased when my testing or development teams point out a hole in the requirements. Tell the person writing the requirements that they need to set performance targets and they will (or should) be happy to do so.
The obvious next question is “How do you set performance targets?” I’ll cover that in the next blog post in this series.