Last year, Sundar Pichai -- who heads up the Android and Chrome teams for Google -- announced that the Google Play store had over 1 million apps. Then, just a few months later, Tim Cook announced 1 million apps were available in the Apple App Store. These numbers get promoted because they demonstrate how big, strong and healthy these ecosystems have become. However, to anyone who is creating a mobile app these numbers are horrifying.
With more than 2 million apps available in public app stores competition for user engagement has become fierce. And because consumer app experiences are shaping enterprise app expectations even enterprise developers aren't immune. Apps that fail to meet those expectations can be (unofficially) replaced with employees' own personal services (Google Docs, Dropbox, ...).
To be successful in this competitive space, mobile apps must offer users an exceptional experience. However, creating exceptional mobile experiences is far easier said than done. Exceptional experiences are not the product of magical ideas, or hiring UX experts, or buying tools and services. Rather, they are the result of a continuous cycle of listening and adapting throughout the entire lifecycle of the project.
The following steps, when used within the context of a listen/adapt loop, can help teams deploy a successful mobile app. [This topic was also explored during a webinar which is available, on-demand, on our website]
At the beginning of your project you don't have facts...you have assumptions. Some of these assumptions are right, some are wrong. And the more time you spend acting on these assumptions, the less likely you'll be to abandon them, even if they cause you (or your users) harm. This is the result of a natural human inclination known as “loss aversion” and it causes us to prefer avoiding loss, even to acquiring gain.
To compensate we need to acknowledge this weakness and avoid over-committing to bad paths. We'll do that through disposable implementations of our mobile app. Disposability implies trivial to acquire and painless to lose. It's this quality, particularly in the beginning stages, that makes it easy for us to pivot in new directions. Pivots enable us to quickly hone in on the best experience for our mobile app.
Many developers will be compelled to immediately start writing code, but because code is time consuming to create it's difficult to casually dispose of and makes us less likely to pivot. So, in the beginning, avoid writing code and instead test your ideas by iterating through wireframes, mockups and prototypes. Consider starting with low-fidelity, non-interactive wireframes (sketches) and transitioning in steps towards high-fidelity, interactive prototypes. You'll do this by adding polish (design detail, interactivity) as you gain confidence in the direction you're heading.
What you're doing at this stage is scouting for the right thing to build and testing your assumptions along the way. Tools such as Balsamiq Mockups, UX Pin and Telerik AppPrototyper can help you rapidly construct (disposable) prototypes of your mobile app ideas using a drag-and drop-library of shapes.
There is a natural rhythm to coding: 1) Write some code 2) Run the code to see what it does. This represents a direct relationship between action and result; doing something and then experiencing the impact of what you've done. And during development, the faster this wheel spins, the more productive you'll be.
Consider the alternative, once upon a time software was encoded onto punch cards. Programmers would spends hours, maybe even days, inscribing their instructions onto these cards which they would then feed into a slot and, eventually, get a result. Maybe it would be the result they expected…maybe not. And if they didn't get the result they were expecting, they would go back to the drawing board and do it again.
Imagine how much time this workflow would add to any given project. As the distance between action and result grows … development ... slows ... down. And believe it or not, this is all very relevant to mobile programming. When developing for mobile we're potentially dealing with a lot of different devices and form factors: iOS, Android, [different versions of Android], Windows Phone, smartphones, tablets, etc. This makes it difficult for developers to readily experience the impact of the code they've just written.
In this way, mobile has resurrected an old problem by inserting distance between action and result. Your mobile development process needs to bridge this gap by making you immediately aware of your code's impact across all the devices you need to support. Create a development process that integrates your IDE, your build service and your mobile device simulators to provide immediate feedback.
As you're building your app it's important that you continue to listen and adapt. This requires staying focused on your users, their feedback and the problem you're solving. It also means you need to avoid becoming overly distracted by technical hurdles… not the least of which is the infrastructure that powers your app.
Sadly there are a lot of technical distractions: countless mobile frameworks, data services, web API's, push notification services and authentication services. In addition, the services that support your development processes come with there own associated API's and SDK's to learn.
It's really easy to fall down the rabbit hole and lose weeks of productivity. Thankfully, several cloud-based services (Parse, Kinvey, Telerik Backend Services, etc.) are available to confront these challenges. These services not only provide fast scalable infrastructure, but also API's and management tools enabling development teams to swiftly address project requirements.
As you progress, stay focused on the activities that have a clear and positive impact for your users and consider tools and cloud services that can help you maintain that focus.
It's inevitable that as software evolves things unintentionally break. It happens. We take 1 step forward then 3 steps back. And, as mentioned, in mobile development it can be extremely difficult to fully understand the impact of newly created code when it can behave differently on different devices.
Automated functional testing can help guard against accidentally breaking existing features by enabling you to "record" various activities, like logging in, and then continuously playing-back these tests on a variety of devices (Telerik Mobile Testing can help with that). If a test fails, you become immediately aware that you've negatively impacted an existing experience.
As a marketer I certainly understand the attraction of launching your mobile app with a grand spectacle. But this is not best place to be validating your ideas. Before committing the kind of resources it takes to create a grand spectacle, ensure your ideas work.
We're not burning our apps to CD's or disks anymore. So shipping doesn't need to happen in one place or time. Use this to your advantage by starting small; recruit a manageable group of early adopters. Then ship early and often to these early adopters through personal deployments, rather than public app stores.
Finding these early adopters and making them happy will teach you so much. This learning can later be funneled into your efforts to create a grand spectacle (if that's what you want to do). But to accommodate this, your development process needs to let you establish distinct groups of users and then push builds directly to their mobile devices.
Typing on tiny screens is difficult, frustrating and generally very error prone. Getting users to submit detailed feedback in this setting is likely not going to happen. This is why we're left with the kind of reviews we often see in public app stores.
It's infuriating to be on the receiving end of a comment like this. There is nothing constructive here; nothing that would even partially suggest why this person is unhappy or what we should do to fix their problem. But this is generally the kind of feedback you're going to get from public app stores.
To overcome this challenge, don't make yourself reliant on public app store reviews to know what your users are thinking. Give your users a way to provide feedback from inside your app. Keep in mind they aren't going to give you lots of details; look for ways to gather details automatically so the feedback you get…is actionable.
Whether or not they send feedback you need to know about the experiences your users have. Historically mobile apps have been a big black box in this regard, it's been very challenging, if not impossible, to find out what users are doing in your app…
Thankfully, there are now solutions to this problem that give you visibility into what your users are doing and the kind of experiences they're having. By using tools like Through analytics and by measuring their activity you'll gain insights that can be funneled into your next iteration.
Successful mobile apps offer users an exceptional experience and exceptional experiences are seldom the result of chance. Instead they are the result of listening and adapting, in a continuous loop, across the entire lifecycle of a project.
The 7 steps above, when used inside the listen/adapt loop, can help teams drive reliably towards a successful mobile app. I'd love to read about your own experiences. What steps do you employ within your own team to reliably drive towards successful mobile apps? Please post your tips below.