Centralis Blog

Rss Image Subscribe (RSS)
Hone Your Mobile Site First Before Tackling Native Apps Posted May 16, 2011, 5:15 pm CT

Hone Your Mobile Site First Before Tackling Native Apps

By: Matthew Scholl | 1 Comments

The question of whether to build a mobile website or native app seems to elicit a similar response among industry experts, often along the lines of, "It's not either/or, it's both." Yet one suspects that for many organizations "doing both" (or least doing both simultaneously) may not be feasible. So where do you start? The following are some reasons to consider honing your mobile website first and applying what you learn in the process should you later decide to build native apps for one or more mobile platforms (e.g. iPhone, Google Android phones):

1. Mobile sites offer a dramatic improvement over full sites. For anyone accessing your site via a mobile browser, the difference between using a thoughtfully designed mobile site and being forced to contend with a full site is enormous. Both make an immediate impression, and only one for the better. A dedicated mobile site shows that you have given some thought to the kinds of things your customers might want to do on-the-go and have taken steps to make it easy for them to accomplish those goals. Compare, for example, the experience of checking on a reservation at two different rental car companies, Enterprise  and Payless:

  • At a glance, it is clear that the Enterprise site (see below) has not been optimized for viewing on a small screen. To even begin determining what options are available to them, the user must first zoom in to make the text large enough to read. From there they will need to pan left and right, up and down, to find what they looking for, if indeed they are lucky enough to find what they are looking for. The “Modify an Existing Reservation” link appears toward the bottom of the screen, in text nearly too small to read even with the screen zoomed in. 
  • Contrast this with the app-like experience of using the Payless mobile site. At a glance, it is clear that the site has been designed with mobile users in mind. All of the text, of which there is sparingly little, is large and easy to read. The user can readily determine the actions that are available to them, which include both self-service options (e.g. View / Modify / Cancel) and an invitation to call customer service. That the list of options is short suggests the company took time to consider what would be most useful in a mobile context. There is also an invitation to explore the full site should the customer have needs that go beyond what is shown. 

 
Figure 1
| The Enterprise (left) and Payless websites as accessed via the iPhone browser Safari

2. Mobile sites reach a wider audience. 
The most awe-inspiring iPhone app only benefits the subset of customers who own an iPhone. While you may ultimately want to provide your customers with a platform-specific app, keep in mind that despite considerable growth smartphones still only represent 30% of the US mobile market. That number is expected to reach 50% within a few years, but within that slice of the larger mobile pie, market share is further divided across mobile platforms. Currently, Google Android phones and the iPhone each account for roughly 30% of the smartphone market in the US. It follows then that apps for any one of these smartphone platforms only reach a subset of your potential customers. Contrast this with a mobile website, which by design is device-agnostic, meaning anyone with a web-enabled mobile device can enjoy an experience tailored to their on-the-go needs just by launching their mobile browser.
 
3. Your mobile site can help you get to know your mobile customers. By monitoring the use of your live mobile site you can learn a lot about the needs of your mobile users.  You can learn:

  • What devices are customers using to access your mobile website? If you later choose to build native apps, having a sense of your audience and their device preferences can help you prioritize which platforms to build for first.  
  • Which features of your mobile site are people using most? This can help you to validate whether you have identified the right feature set for the mobile context. Frequently used features should obviously have a home on any subsequent native apps, while seldom used features may warrant conducting user research to explore the underlying reasons. For example, is a feature underutilized because it is poorly implemented or is it just not something people are interested in doing on a small screen? The answers to these questions will help prioritize which features to promote to your apps and which to exclude.  
  • Are large numbers of users navigating to your full site? Even if you offer your customers a dedicated mobile site, you should continue to provide them the option of exploring your full site. To the extent that customers are clicking thru to your full site, look for patterns to understand if there’s content or functionality that deserves to be promoted to your mobile site, and later to any native apps you choose to build.

4. Users get the latest version of your mobile site automatically. 
Every time your customers visit your mobile site they are seeing the latest version. If you make changes in order to better meet the needs of your mobile users (or to correct a bug caused by an earlier release), those changes are available immediately and without any action required on the part of your users. In contrast, the only way for customers to interact with an updated version of your app is for them to manually download an update. Behavior will vary across customers, of course, but it is conceivable that a sizeable portion of your customers will continue using the version they initially downloaded, oblivious to the availability of subsequent updates (the author, for what it's worth, currently has 48 app updates pending). 


5. With native apps, there is a greater need to get it right the first time. People are fickle when it comes to their use of apps. Even as consumer demand for apps continues to grow, 1 in 4 mobile apps once downloaded are never used again. Further, use of iPhone apps appears to drop precipitously over time. One study showed that the majority of apps are in use by less than 5% of users a month after being downloaded. In short, consumers are as quick to discard apps as they are to download them in the first place. All of which places additional pressure on organizations to get their app right the first time, lest they end of on the great heap of unused apps.


To be clear, this is not meant to be an argument for or against developing native apps, but rather to suggest that the mobile Web may be a better starting point. From ensuring a positive experience for the majority of your mobile users, regardless of which device they carry, to learning about their needs and adapting your mobile offering accordingly, there are several advantages to focusing on your mobile site first instead leaping directly into developing apps for specific mobile platforms. Further, the process of honing your mobile site will provide you with a solid foundation should you later decide to develop native apps, at which point you can focus on identifying features that only a native app could support.
 

Comments

Post a comment
Nov 30, 2011, 1:13 pm CT

From David at Buy Books:
So true with the often divisive discussion on mobile website vs native smartphone app. I built my buy books smartphone app as a "web app" to avoid doing multiple platform implementations. Because I need access to device features such as the smartphone camera, my app has to be more than just a mobile website.

The landing page for book purchase is somewhere between a regular webpage and a mobile webpage. i.e. it is smartphone-friendly but not smartphone-optimized. As an affiliate program "publisher", I am currently working with the affiliate network and the "advertiser" to ensure "mobile tracking" is working such that I get affiliate credit for sales which I drive to the advertiser.

Oh the complexities.
Report abuse

Post a Comment

Name (Required)

Email (Required, but not published)

URL
Comment

Enter security code:
 Security code