Luke Wroblewski is a hero in UX and UI design. He understand ‘the game’ more than anyone, and is able to articulate the rules of this game in an excellent way. Check out his recorded videos on YouTube, of which many were given at Google I/O talks.

This post is about a term he flipped: ‘rich vs reach‘. In this article, you can read more about this philosophy and what it means for UX design. Basically, he argues that (when talking about web-based vs native apps):

“In other words. The Web is for audience reach and native apps are for rich experiences. Both are strategic. Both are valuable. So when it comes to mobile, it’s not Web vs. Native. It’s both.”

Meaning: web based content is easier to approach, has a larger audience, and doesn’t require users to (per se) download an app before he or she can use it. As such, it’s a great way to ‘grow the funnel’, e.g. when you’re selling a service or want to get people interested in your offering.

At the other hand, native applications – and thus ‘native content’ – is ideal when the interactions with your service are more deep (‘rich’), frequent and with the ability to use the phone’s hardware capabilities (i.e. camera, fingerprint/FaceID security, gestures, etc.).

Native app users spend way more time on mobile native apps than they do on the web (see bars in figure above), but mobile web content has approximately 3x more unique visitors, than mobile apps do. This distinction is very relevant when you have to decide what if your future service will be web-based, and what will app-based. These two ways of providing a digital experience are not mutually exclusive.

First web, then native

So in our case, we are working for a company that is launching a self-service storage business, from scratch. Clients will be able to find the unit or their choice, and after reserving it and making the first payment, they need the ability to manage their bodega in any way they want (think of renting a van, tools, racks and shelves, managing payment methods, etc.). Essentially, we first need people to become aware of the product, then reserve and buy it, and finally engage with the product on a much deeper level than before Point Of Sale (POS).

In a diagram, that would something like this:

Following Luke’s theory – and of course with some healthy common sense – we decided to break up the experience in two parts:

  • The general website where people can find and subscribe to their storage unit
  • A native app that will be offered to them at POS that allows them to manage the unit

We could have chosen to create an administration portal on the website, where clients login and manage their unit from there, but since the interactions will be more frequent, ‘deeper’ and more contextual (consider for example, that somebody wants to rent a van the moment they arrive at the physical site), it makes sense to use a mobile application rather than adding a portal to the website.

Evaluate the ‘richness’ of your journey, from start to end

The take away here, is that you need to think about your (future) service journey, and the channels you’re going to use at different points of that journey:

  • Do I need reach? Or richness?
  • What is the intensity of interactions users have, for each journey phase?
  • What is the context of use, per phase?
  • Am I selling something, or do I need people to manage something?

Some food for thought for your next digital project, frankly!