Choosing the right mobile presence

Mobile strategy for my business: Part I

Decision No.1: Website, app or both?

This is one of a number of posts helping businesses establish a mobile strategy. We can’t attempt to give you a strategy in a single article, or even a series, as there are too many variables to think about. The articles will however help you understand what things you need to take into consideration when developing your own strategy.

 

Possibly the single most important decision a project manager, business manager or entrepreneur has to make when looking at their mobile strategy is what kind of mobile presence to build. A website or a web app? A pure native app, a cross-platform app or a hybrid app*? Or will your responsive website do just fine?

Three things come into play:

  1. The users your business needs to serve
  2. How you want your brand to be perceived
  3. Your budget

In a perfect world you’d build a mobile solution that satisfied every type of user’s need, that perfectly delivered your brand’s positioning, thanks to a budget that enables you to build, maintain and continually improve your mobile assets.

That would mean your mobile strategy would see you build a mobile-optimised website for the users who either don’t want to download an app or visit too infrequently to justify a download and a native app for your regular users who demand a high quality, more deeply engaging experience (that only truly native apps can deliver).

Anything less than building those two things means you are compromising, but sometimes there are a number of justifiable reasons for those compromises, normally because of budget constraints or the size of team you have available to service your mobile presence technically. That’s completely understandable, but we should point out that the world is now becoming ‘mobile first’ meaning your customers or users are preferring to use their mobile devices instead of desktop ones and they are expecting you to recognise this by giving them the best mobile experience of the brand you can.

 

1. Mobile strategy: Your users

We have an internal saying, ‘When you publish an app it is no longer your app. It is your user’s experience.’

Now one thing to consider is that 89% of mobile usage is on apps rather than mobile sites, which should be enough of an impetus. This is because they normally look better than web sites, are easier and quicker to use and always perform better. So you will always build a native app right?

Not always. The first thing to do is put your user’s needs, circumstances and expectations first (with suggestions as to which type of app is best in brackets):

  • Will they need to use the app often? (native)
  • Will they prefer not to wait for long downloads each time they use it? (native)
  • They don’t have time/want to download an app for the few times they use it. (website/web app)
  • Do they expect the brand to offer a high-end experience? (native)
  • Or do they accept a lessened experience as the brand puts value first? (web)
  • Do they need to use device functions, like the camera or secure offline storage? (native/hybrid)
  • Are there multiple different types of devices being used (website/web app/hybrid/HTML5 wrapped native)

There is another post here on the different types of app you can build.

As you can see, there are some instances, mainly around frequency of use, when a mobile-optimised website is better than an app at delivering what your customers want and need.

So let’s explore that statistic of 89% of users prefer native apps at little more. It is skewed more than somewhat by the high use of social media, video and functional apps like calendars. If you are a retailer, or an enterprise with an operational requirement, do you need to produce an app?

Not always. If you retail white goods, that consumers purchase infrequently, then you need a website because it is discoverable by search engines and then quick for the user to open and use, but an app may be rarely used. If you retail high-end hi-fi components, you might consider a web-app because you think you’ll get a lot of repeat visits and want to make each visit quick and more app-like for the user. If you are a fashion retailer you still need to ensure you have mobile-optimsed web pages for quick discovery and casual browsing but you will certainly need to invest in a native app that is easier to use for longer and deeper browsing sessions.

It’s really a question of user behaviour and segmentation, with the browser better for casual engagement and apps for frequent and loyal customers (the kind retailers like).

A really good example is the UK Financial Times newspaper (the FT). Via FT.com, they have iOS and Android-optimised web apps for users who want to dip in and out quickly for the latest daily news. But for longer, more richly engaging content, the equivalent of the Sunday supplements, the FT has native tablet apps for iOS and Android users who want to explore on dwell on the vast amount of content on offer.

 

2. Mobile strategy: Your brand

Unfortunately, great though they are, mobile websites and web-apps are just never as smooth, slick and robust as a native app, even when built in HTML5. But that can be fine sometimes. If you have a ‘no frills’ budget airline brand or you simply need to impart a lot of technical data in a table format, do you really need high-end whizzy graphics and native gestures?

On the other hand, if you have spent a lot of time and money gaining the interest of a potential new customer/user, you don’t want to put all that work to waste by delivering a sub-brand experience. We can think of a great example:

A leading automotive brand’s mobile website is quite often frustrating to use, with a typically clumsy web-style navigation. But ‘luckily’, every time you load the site, there’s an app store link at the top of the page encouraging you to download the brand’s app (because the brand knows regular users prefer to use a native app). But after downloading the app users discover that the ‘app’ is actually the mobile website, embedded inside a ‘native wrapper’ so that the same terrible navigation can now be stored on the device instead of having to wait for it to be downloaded! This app get a 1.5/5 rating from users, yet it’s by one of the leading automotive brands in the UK. Or at least in this newly mobile first world it is for the moment. But what if a competitor produces a much easier and nicer to use proper native app…

 

3. Mobile strategy: Your budget

Your budget determines what you can build.

Looking again at the example above, one of the reasons such a big brand may have made the decision to not provide both a mobile website and a truly native app is budget, because they wanted the initial cost and ongoing technical development to be cheap.

In this newly mobile-first world, you cannot escape the fact that you need to invest decent sums on your mobile presence, otherwise you will look cheap.

If you are a pure-play app, like a game, recipe manager or other productivity tool, then you can go straight-to-app and not worry about a functional consumer website (a marketing website to advertise the app is a must, though, for search and general discoverability.

If you are an existing business or service and you are taking mobile seriously, in most cases you need to make enough budget available to do both your web presence and your mobile app/s properly.

The first part of your budget is the initial cost.

We have a separate article, ‘how much does an app cost‘ on the typical costs of developing a pure native app, but the below gives you a rough idea of the differences in types of cost, if a pure native app is 100%. The article also explains what we mean by ‘pure’ and ‘as native’. This is the cost of the client-app only, not any other associated development such as a back-end.

  • Pure native for iOS and Android (100%)
  • As native (React Native, Xamarin, Titanium) app for iOS and Android (60-80%)
  • HTML5 wrapped app (55-60%)
  • HTML5 web app (50-55%)
  • HTML5 web site (50%)

These are extremely rough indicators and the differences can vary wildly due to the specification of the app you want to build.

The second part of your budget also needs consideration. One thing we constantly see is a lack of ongoing development budget and we need to be clear: Once you have released your website or app, that is only the start. To keep ahead of your competitors you will need to continually re-invest to give your users new functions and experiences to keep them using the asset.

What is obvious, especially if this is your first experience of building for mobile users, is that there is a lot to think about. So please come and talk to us about your strategy, what you need to deliver for your business, for your users and customers and how we can help you in a long-term partnership to ensure your mobile strategy works.

In further posts, we’ll look at distribution and how you can put your mobile presence in front of potential customers and users.

 

Native apps can mean one of three things: 1) apps written in native source code, compiled by the device you are using (that means Objective C for iOS apps, Java for Android app and so on), 2) apps written in a non-native language (Ruby, for instance) and subsequently compiled into native code (Obj C/Java) or 3) it can sometimes also be used to mean content is carried natively on the device itself (with no need to download from servers). Likewise, the term hybrid apps can be used to mean apps that are written using a javascript framework (React, Titanium) or html web code (like PhoneGap, Ionic) while using native code to house, enhance and provide access to native components otherwise inaccessible. We’ll try and be clear which one we mean, when each term is used. Confusingly, web apps aren’t really apps in the sense that you download an app – it is an application which uses a web browser (desktop or mobile) as a client rather than distributing and installing software on each computer/device – think Gmail (web app) rather than OS X or iOS Mail (application). The important thing about a web app is that is will still need an internet connection. Plus you don’t need to distribute the app via an app store.

TAGS >