10 Pitfalls to Avoid with Mobile Application Requirements

I have been involved in the design and development of multiple mobile applications in the last decade. If you are embarking upon your own mobile application, let me give you some advice to help you avoid some pitfalls that come with eliciting and analyzing requirements for mobile application development.

1. Don’t try to re-create every feature that’s on your website

This one seems like a total no-brainer to me, but believe it not, some people just don’t get that mobile devices are smaller and simply can’t perform all the same functions as a website. You should:

• Keep focus on key functionality – The point of having a mobile application is to identify the most used, most valuable, and most mobile-appropriate tasks that users may want to perform. Look at your website analytics to figure out what your customers do the most. Pick a handful of those activities and start there.
• Keep it simple – I always stick to the KISS principle (keep it simple, stupid). Users want to be able to accomplish their primary goals – help them do that, and they will thank you for it.

2. Don’t underestimate the combination of hardware/software (OS)

Do you have any idea how many possible combinations of hardware and software are available for mobile devices? I’m not sure what the number is, but I’m confident there’s almost an infinite number. When you develop for mobile, you can’t possibly account for all those combos, so again, look at your usage data, and:

• Decide what OS versions you are going to support – use the empirical evidence of what your customers use and target the OS versions of Android and iOS that are most recent and most popular. Target the current version and the last few major versions. Supporting older OS versions will have a diminishing return on investment, so you have to draw the line somewhere.
• Decide what Hardware versions you are going to support – do you remember a thing called a Microsoft phone? Or a Google phone? I’m not sure either of those products exist anymore. But once again, pull out your handy dandy metrics and see what your customers use. Go for the obvious big boys (Samsung and Apple) and narrow it down from there. There are many obscure brands out there, so watch out for any trending “hot” devices.
• Be sure to fully test all combinations; automation tools are best for this – while it’s not physically or economically possible to obtain every combination of OS and mobile device out there, you can at least run some automated tests using a simulator. This will help you head off potential problems at the pass. (Don’t bother with versions you don’t plan to support, though.)
• Use simulators, but remember nothing beats the real thing (actual devices and OS) – there’s nothing like the real thing, baby. Get your hands on a minimum of one phone and tablet for relatively new versions of Samsung and Apple devices. Use the most recent OS (or the lowest OS you plan to support). Then put these devices in the hands of your QA testers and make sure they know how to record videos and screen shots of any issues they discover.
• Don’t align by Channel (device); instead, align by features – seriously, though. One company I worked at literally had teams split up by Android, iOS, and mobile-optimized web. How ridiculous! This was a horrible approach, very costly, and totally inefficient. Instead, align by application features, and develop them to be consistent across the platforms.

3. Don’t ignore your user’s emotions or usage patterns

4. Don’t forget to include transitions

Have you ever pushed a button, and nothing happened, so you pushed it again (and again, and again…)? Yeah. That sucks. You can’t leave your users literally “hanging”. If you don’t let them know what is happening, they’re going to get impatient and do something they probably shouldn’t do (thereby compounding their already bad experience).

Here are a few things you can to do to address transitions:

• Ensure it’s not a jarring experience when something goes wrong – think of everything that could possibly go wrong (a good QA person will help with that). Then plan to deal with every major potential problem. Handle the problem as smoothly as possible so they user can recover where they left off and accomplish their goal.
• Mask transitions in a way that doesn’t confuse or frustrate users – if you have a transition, but it’s unclear what is really happening, you’re going to lose more users. I once worked on a mobile app that required the user to download a large amount of data, which takes time. To make it fun for the user, rather than annoying, we showed a variety of messages that were entertaining (think Domino’s Pizza order tracker).
• Stick with transition standards – it might be cool or cutting-edge to have some super fancy transitions between actions, but this is going to get you into trouble. Just stick with the standard stuff.

5. Don’t underwhelm the user; you must have some “delighters”

Users will quickly delete your app if they don’t like it. You need to have the basics that a user would expect to have, but you also need to have a few “delighters”. These are things that surprise a user and make them happy. It’s not good enough to just have the core functionality – anyone can do that. Find some special capabilities that will make the user’s life easier.

• Take advantage of unique mobile capabilities – mobile devices have far more capabilities than their sedentary desktop counterparts – use them! Voice input? Yes! Camera for QR scanning? Heck, yeah! GPS tracking for services in your area or directions? Uh, duh – no brainer! You have the power – use it!
• Delight, but don’t overwhelm with too much noise – so, yes, you want some delighters, but you also don’t want to overwhelm. There is a fine line you have to walk with mobile applications. Make it fun, but also make it simple and functional. Avoid ads and distractions.

6. Don’t lose control of your app score rating!

Your app store rating will make or break your app. This is one of the primary measures of success of an app. You must actively manage, and be proactive about, your score. Check user feedback and use that to improve your app. Release frequently.

• Apps that have low scores are less likely to be downloaded – this should not come as a surprise. People want highly rated apps that are functional, fast, and useful. If your score is low, you can forget about downloads.
• Keep your score up by listening to your users’ feedback – users rely heavily on the app store score, so work hard to ensure that your app has a high score. Actively listen and respond to your users’ feedback.
• Innovate and improve iteratively to keep the score up – it’s not enough to just let user feedback drive your mobile application development. You need to continually innovate, improve, and iteratively and incrementally release updates.

7. Don’t forget about non-functional requirements!

Talk about one of my biggest pet peeves. This applies to both mobile and non-mobile projects alike. Don’t EVER forget about non-functional requirements! It will come back to bite you in the butt! Trust me, I’ve ignored them at my own peril in the past. If you meet all the functional requirements, but your mobile app is slow as molasses, no one will use it.

Your mobile app MUST be performant. Keep in mind that these types of requirements tend to apply across the entirety of the project, and they are often tricky to nail down. Trick: it’s a CLUE if the word ends in “ility”. (Seems like a good topic for another blog, on another day).

8. Don’t overdo the use of push notifications

How many times a day does your mobile phone ding or vibrate because it has received a push notification? I’ll tell you this: far too many. This will only annoy your users and lower your app score. You need to be very judicious about how often you push notifications. Be sure to:

• Allow users to easily opt-out of push notifications
• Provide alternative communication methods if users do opt-out

9. Don’t invade your users’ privacy (without their permission)

In case you’re not already aware of it (or you just don’t care), if you have a mobile device – you are being tracked. No joke. I have worked on multiple mobile phone applications that took advantage of the phone’s GPS tracking capabilities to do things like track your behaviors, monitor where you currently are, or check to see if you are in the proximity of a store so they can push you a coupon… and that’s just the tip of the iceberg.

Whenever you download a new app, you probably just click through the agreements and requests to access your phone’s various capabilities. When you do that, you basically sign away any privacy you thought you might have. But sometimes this is to your advantage. Maybe you do want to be tracked. That’s fine. But don’t you dare build a mobile application without checking to see what the user wants. If you are going to track people:

• Make sure you disclose everything you are tracking and what you’re going to do with it
• Make it easy for the user to go back to their settings to adjust them
• Ensure that the tracking you do is for a purpose
• Provide a compelling reason why you need to track the phone, and sell it as a benefit

10. Don’t organize or develop by device – do it by feature

Last, but not least – DO NOT organize your development efforts by device. I was once on a mobile team that did exactly this, and it was a huge mistake. It was totally wasteful and redundant to build the exact same thing three times. Especially now that there are tools like Xamarin, which make it easy to develop the bulk of the code, there is no reason to have separate codebases for each type of device.

Instead, organize your development efforts by features or function. Build it once, and customize for special native or device-specific capabilities only. This will ensure consistency across the mobile user’s experience with your app.

Now that you know what things to avoid when gathering requirements and building mobile applications, is there anything I missed? Are there any other problems you have faced with mobile requirements that you wish you could have avoided? Drop me a line and let me know!