5) Test, Test, Test
There are lots of arguments to be had about testing. Who should do it? When it should be done? What’s the best methodology for doing it? What’s not up for discussion is whether you should be doing massive, iterative testing to begin with. The answer, in case you were wondering, is “yes.”
It is a shame that users have become accustomed to acting as beta testers for every new app. Break the pattern. Make sure your app is solid and reliable before releasing it to your users. Test functionality, test performance, test security, and test everything else you can think of. And don’t stop testing just because the app has been released. Platforms, networks, and user patterns change. Keep testing.
Back when I said that you should know your users I mentioned the importance of listening. Well, it’s so important that I’m giving “listen” its own spot on the list. Ask your users for feedback, give them a mechanism to make talking to you easy, and then really listen to what they have to say. It’s not easy, but if you can get this one right you’ll create much, much better apps.
It’s easy to become defensive when people are telling us about shortcomings in our work. Don’t do that. Stay open to what the users are telling you and listen hard for the meaning behind the words.
Users will use confusing terms and the “wrong” words to describe what’s happening, but really hear them and you’ll find cases you didn’t test, assumptions you made in error, and odd stuff that shouldn’t be happening but is. In all of those cases, if you really listen, your users will end up happier because you’ll end up creating a much more successful app experience for them.
7) Performance Matters
No one likes a slow app. Sure, we can all tell stories about how things were when we were getting started in IT, when we would leave our stack of punched cards to be read and come back a few hours later for the results. But no one wants to go back to that. Each and every user wants results right now — maybe a little sooner.
There are a lot of things that can have an impact on app performance. You should constantly monitor the app, the networks, and the server to make sure there aren’t problems. Set up alerts so you know about issues before they become problems that become angry phone calls to support.
Design performance in and make sure that performance stays within design parameters. Yes, I know that I’ve wandered squarely into DevOps territory, but if that’s what it takes, then you should embrace the discipline and make sure that no user has to wait on an app to get his or her job done.
8) Remember The Network
If we’re talking about a mobile app, then it’s a lead-pipe cinch that we’re also talking about a network app. It’s the rarest of enterprise apps that live on their own, so you need to decide early on what your app will do if it can’t find the network.
The answer will, of course, depend on exactly what the app is supposed to do. It might be that the app will locally store enough data to allow it to function for a short time away from the network. It’s possible that the app can go into store-and-forward mode until connectivity is restored.
It might be that you just need to come up with a really nice “waiting for the network” screen. In any case, you need to respond to network connectivity with the proper results.
You also need to take the network into account when it comes to performance and security. It can get complicated, especially when you’re talking about large user populations and apps that can hop from 4G to WiFi networks without missing a beat. Regardless of the complication, you must be willing to make the effort to get it right. You do remember all the testing we talked about a few moments ago, right?
Building a successful mobile enterprise app isn’t simple but it is do-able if you take the time to walk through the right process. These are some of my key steps in that process: Now that you’ve seen them, what do you think? As I said at the beginning, I’d love to know your top tips. I’ll listen if you tell me that mine need improvement. I’ll see you in the comments.