Mobile Strategy Best Practices

Recently I had the opportunity to discuss mobile strategies with Vidya Drego of Forrester Research. We chatted about how businesses are looking at the emerging mobile market and how they are approaching application development. We quickly got to the subject of mobile app development best practices. Our conversation motivated me to look at what we are hearing from our clients and potential clients, and to discuss some of the things we have learned over the last couple of years.

Most businesses are discussing mobile best practices in the terms of design and development tactics.  Most of which can be found on sites like w3.org, or uxmagazine.com. For example:

• Optimize for application start-up time
• Use cookies sparingly
• Make telephone numbers “Click to Call”
• Replicate Local Data
• Use clear and consistent labels
• Avoid using specific font point sizes
• Icons should not save space at the expense of user understanding
• … you get the picture

Another thing many marketers are thinking about is the mobile marketplace. “How do we monetize the application” or “How do we make sure our application is findable” or “What is the right go-to-market strategy”. These are all important questions that need to be asked. But not yet. Not until we understand one very important thing, “why”…

After reviewing hundreds of application ideas, reading user research reports from our research team, and checking out multiple consumer surveys that have been conducted on mobile, I decided to take a stab at developing a best practices for mobile strategy…

There’s an app for that… why?

Seriously – “why” is the most important question you can ask. It is also the question that talks us out of a bit of application work too. We ask “Why are you building this?”, “What is the compelling business case for a mobile application?”, “Can this be accomplished through a well designed mobile site?” or “What are your customers demanding from you in a mobile application?”

Once you understand “why”, you need to make sure it is well documented. It can be a simple sentence, or a paragraph, but not much longer than that. I call this getting to the “reason for being” or the “Raison d’être” of the application. Defining the Raison d’être of the application will ensure the team is pointed in the right direction. It is something that should be referred back to when making decisions as to what to build and what not to build.

True story. We were talking to a small organization a while back. We were discussing the value of user research, to understand what their users would wanted in a mobile experience. We received a significant amount of push-back from the client on the time and energy of the research (which was only a few days worth of work). For us, research is a critical ingredient in designing and building an application that users will want to adopt. After several frustrating conversations, the client finally came out with the reason why they didn’t want to do any research. “If you ask our customers what they want in a mobile application, they will tell you they don’t want one.”  Do me a favor and pause on that thought for a second. The client was funding an initiative they already knew was currently unnecessary. They didn’t really contemplate the business case and the user case – they were just blindly following their CEO’s direction.  The “why” will also help guide your team and direct design decisions. That brings me to my next point…

Ask your customers what they want

Don’t guess, know. A little research goes a heck of a long way. In fact, research may show you that you don’t need to do anything right now. You may find out that your customers are perfectly fine without a mobile application from you. This research needs to be contextual (ie: in person and in the field) to make sure you get accurate responses. But be warned, don’t try to do the research internally or hire a pure-play research firm to do it. You need an agency that understands how to design and build the application to do the research. It is surprising how different the questions are when you are asking from the perspective of having to apply the research and turn it into a solution. Joy, our director of research, and her team of researchers work closely with our design and dev teams to make sure there is no fidelity loss between research and the final product. Even outside of a mobile context, for any application, the right user research and design collaboration will drastically reduce maintenance costs and increase initial and sustained user adoption.

Your mom has a smart phone

Just a few years ago, most of the people we designed for were technology savvy and understood how software and applications should work. User interfaces were intuitive because users have seen something similar in another program or device. The metaphors I use to navigate an application were learned over years of being a geek. But my mom has none of that – she has no frame of reference on how an application should work based on intuition learned over years of software experience.  And this community of late adopters is growing. In fact, the fastest growing market of web related services and devices are people over the age of 70, according to one study. That means you need to care about how they perceive the device – many designers talk about using more physical metaphors when designing UIs – largely because they understand that novice users need their connection to the physical world to map to their digital interactions. Long story short, it is not only important to ask “why?”, but also to ask “who?”

The mobile app market is not the web of yesterday

I wrote about this last year claiming “the iPhone is not an ad platform” – perhaps I could have chosen a better title given Apple’s iAd platform. My point was you shouldn’t treat an application initiative the same way you would treat a microsite, email campaign, or television spot.  Do not think of the creation of an application as a “campaign”. User’s look for utility from an application. Sometimes that utility is entertainment, but if you are not an entertainment company, don’t try to entertain your consumers in an attempt to drive traffic. What is worse, many companies are trying to create throw-away applications for the sole purpose of brand awareness. Driving traffic, find-ability, clicks, impressions, are typically the wrong metrics to use when measuring the success of a mobile application initiative.

Focus on what your business does

If you are a credit card company, you don’t need to build a game. If you are a Shipping company, you should not build a social network. Stick with the primary purpose of your business. Consumers know one thing for sure: if you build an application that does not have direct utility related to your business, it is probably an application designed to market to them. A quote from a review on an app that tried to build something outside of their core business:

“This app is an advertisement. It features cute bubbles that contain useless information about deals. I expect quite a few Fortune 500 companies are going to do this. The iPhone will turn into the Internet soon, just an ad machine. Don’t waste your time with this and don’t encourage this.”

Most consumers do not want you taking up space on their device and data away from their data plan for the sole purpose of delivering advertisements. There are very few brands with enough consumer brand equity to successfully pull off their own adware application. There are plenty of options for you from a mobile advertisement perspective if that is what you want to do, stay away from trying to build your own advertising channel.

Design for mobile use cases only

73% of mobile app users say they expect a company’s mobile app to be easier to use than its website (link to study). If your website or customer portal has 50 things a customer can do, your mobile application should do 10. In almost all circumstances you should never consider a “port” of all your website’s features to a mobile application (or even a mobile website for that matter). Ask these questions once you have identified all the requirements of an application:

• Will they need to access this feature more than once a month (or, even better, once a week)?
• What is the compelling reason for  using this feature on their mobile device?
• Will this feature be easy to use on a small screen?
• Can we get this feature perform well?
• Could this feature deplete the battery too much?
• Is there a ton of data to transmit to make this feature work? Will it require high bandwidth?

Most good mobile applications offer a fraction of what their website offers. And some great ones add a feature or two that takes practical advantage of the device’s GPS chip, accelerometer, compass, or multi-touch display.

Cross-Channel is not just a buzzword

You have a digital product ecosystem. Your marketing website and campaigns, your automated customer service call-center, your customer self-service portal, kiosks, and perhaps a tablet or desktop application. If your organization is like most large organizations, these experiences are probably disparate initiatives that have no connective tissue. Don’t make the mistake of creating yet another skunk-works initiative that further fragments your digital ecosystem. Take the time to think about the entire customer journey and map a mobile experience to their overall user experience with your company.

Every smart phone has a browser

In other words, ask yourself: “do we really need to build an application or can you simply design a smart-phone specific website?” All new smart phones render HTML very well in their modern, mobile browsers. If there is not a compelling reason to download an app, they won’t. One major side benefit to creating a mobile website is that you have something that will work across devices. In most circumstances you need to build an application specific to a device – where a mobile website is much more ubiquitous. There is a great post written by mobiThinking if you are struggling with the decision to build an app or build for the mobile browser.

Plan for frequent updates

Most successful applications have an avid audience because they created a great experience first, and then continued by following up on that great application with updates and improvements. You build great fans and and evangelists if you show a responsiveness to customer feedback once the application is launched.

Focus on outcomes, not features

Actually, this is good advice when discussing any application initiative. Quite often teams focus on the tactics of creating the application before they figure out what the user and business goals are. Focus on the outcomes. In other words, focus on the things the user will accomplish with the application – figure out the details of the features later.

Examples of features:

• Secure log in screen that does not save the user password
• Recent transactions with access to scanned checks
• Connect to existing web services
• Allow customers to view accounts in list form, click on an account, and transfer money to another account

Examples of Outcomes:

• Our customers will have access to relevant account information (balances and pending transactions)
• Our customers will be able to find a branch closest to them quickly
• Our customers will be able to process transfers while on the go

The data is very important, but…

When asking for input on this list from our team, a common theme emerged: “Before you invest in a mobile app, invest in an API”. It is 100% true that you need to care about the services and data that will drive a mobile application. Without a well architected API, a mobile application is just a Hollywood set. However, do not make the mistake of allowing your IT department to build your API layer before you understand user needs. If you already have an API, great! But your IT department needs to be willing to work with you on iterations and modifications so you can adapt to user needs quickly. Many times we find ourselves developing to APIs that were defined before user needs were, and many interactions and data requirements were just not architected in the API. The best case is to define Outcomes, map the experience, sketch wireframes, architect and build the APIs, and then continue with building the mobile application. This sounds linear but it does not have to be. In circumstances where a release date is critical, we can develop a mobile application to a set of what we call “mock services” while IT builds true services in parallel. It is not optimal, but it can work if planned correctly.

A good API also has a potential alternative benefit. Although many (if not most) organizations would never consider releasing their APIs for public consumption – there may be a way to get other developers to build when you don’t have the time or resources (or even the great ideas). Tony Hillerson reminded me of the story behind the twitter iPhone application – Twitter simply enabled third parties to access their API and let the developer community at large build multiple Twitter clients (then they bought the best one and branded it with their name) – Further, even if you don’t ever release your API to a developer community,  a great API provides you with a platform in which you can leverage across other channels in the future, like a tablet application, a desktop application, or even an Apple or Google TV app.

Be careful with “Social”

Just because a mobile device has social features doesn’t mean your application needs to. I personally have always been a little skeptical anyhow of social strategies that go beyond listening to your customers feedback through social channels. First, not every organization needs a facebook strategy – second, your customers may not want to include you in their social sphere (in fact, they probably think negatively of  your brand for even asking to be included in it). If there is a compelling reason for the user to be connected to facebook through your app, then by all means, go with it. But it MUST be compelling enough for them to invite you there.

Don’t just “Dip Your Toe In”

Many companies are wanting to get an application in the market quickly. There are a couple reasons for this. First, they have very limited budgets for mobile as the market is still relatively small. Second, the market is very new and largely misunderstood – companies treat a mobile app the same way they would a web microsite or a flash banner ad. But, consider this, do microsites or banner ads receive consumer ratings? Can your brand afford a “two star” application? If your customers download an application and have a bad experience with it, will they ever trust your brand in the mobile market again? A recent study conducted by EffectiveUI and Harris Interactive showed that 13% of all mobile app users already don’t trust a brand because of a bad mobile application experience they had with that brand and 69% say that a bad experience with a brand’s mobile app results in a negative perception about that brand

A fresh, clean canvas for innovation

I’ll end where we began – with a conversation I had with Vidya. The most poignant thing she said was that new channels like smart phones give organizations a chance to innovate on user experience. Your website is wrought with legacy issues, probably a Frankenstein of multiple initiatives over the course of many years. But a mobile initiative gives you the opportunity to look at your customer’s digital experience with fresh eyes. This is a blank canvas where you can really focus on user experience the way you always wanted to. Vidya reminded me of our work with eBay, where they viewed the desktop as an opportunity to innovate. eBay’s goal was to create a better shopping experience for their customers without the constraints of their main website. Not only was the application itself was a success, but many of the new features created for the desktop application bubbled up into their website.

Operating without the weight of legacy decisions and many of the nuances of interdepartmental silos can be quite liberating – and a huge opportunity to shine a bright light on user experience for  your entire organization…

………..

We are releasing the results of an in-depth study this week confirming that a bad mobile experience can have negative consequences for your brand.  A good strategy and a focus on the user will ensure that your mobile initiatives are well worth the time and resources your company will spend to capitalize on this new frontier.

• android
• EffectiveUI
• iPhone
• Mobile Strategy
• User Research