Beyond the app model

Personal project 2015

The model that we use everyday to interact with our "digital asset" is outdated.
We've replaced softwares by apps, libraries of softwares (OS) by libraries of apps (mobile OS), physical stores by app stores, clicks by taps,... but the paradigms are always the same.
And solutions that worked 15 years ago when we were using Words 3 times per day and Outlook once every 2 hours are not suited for our current usage.

How many different products do we need to use to achieve even the simplest things like planning a meeting (calendar, emails, maps, contacts, linkedin,...)?
How many time do we miss opportunities to use interesting services just because we don't know about them (a map of transportation in a new city, online payment methods at the restaurant, app of a physical store to find more products,...)?
How many screens do we need to browse to compare all the options that we have in a specific situation (compare transportation options, compare all the theaters and their respective time slots to watch a movie,...)?

The problem is already very real, but it could get even worse as we'll get more and more devices and apps.

There is a model to reinvent

First, let's be clear about two words that we'll be using a lot in this document:
By "products", I'm referring to apps, websites, webapps, or any kind of "wrapper of services" (Gmail, Google Inbox, or Outlook are products).
By "services", I'm referring to end values offered by a product ("storing emails", "composing and sending emails", "searching in emails" are some examples of services from the above mentioned products).
For instance, Gmail and Google Inbox are two different products, offering different ways to interact with (almost) the same services.

Products don't have a lot of reasons to exist beyond the services that they offer to their users. And if we try to imagine another way to interact with our services, products could even be seen as obstacles: people need to know about a product; people need to acquire the product; people need to learn how to use the product; people need to remember the product, to find it and to open it whenever they want to use it; people often need to juggle between different products to achieve a single goal;...

Services as an API

If we push this idea to its limits, we could imagine a world with almost no products as we know them today, and where a kind of unified system would allow people to seamlessly access interesting services, no matter what products offer them, or even on what devices they are available.
Instead of having to learn about a product, to find it in an app store, to install it, to learn how to use it, and to finally use it, the system would let me know that a service interesting for my current situation exists, and I would just consume this service on the fly. We would shift from a paradigm based on the compartmentalization of services into apps, to a paradigm based on the distribution of services into contextual streams.

Of course, this model would raise a lot of questions (economic models, onboarding on new services,...), but it's always interesting to consider this kind of long term perspective.

Let's come back to reality

Disrupting the model that we use everyday is a huge challenge, and the gap is probably too big to tackle it at once. We need a long term vision, and we have a pretty clear one now: putting people closer to their services.
But we also need to think about a realistic way to achieve this vision, and if we try to imagine the first step to go in that direction, we naturally look at mobile OS as they currently are the platforms that rule our relationship with digital services: they define that we should install an app, and then open it when we want to use it for instance... these rules come from the good old computer era legacy, but they shape how we behave today, in a very different world.
Mobile OS seem to be a natural starting point when we try to think about a new way to interact with our digital services. They are just in the best position right now to engage any change and to tackle all the problems that we'll meet in this journey.

But we have to keep in mind that there could be a lot of different ways... another really interesting approach is explored by modern messaging apps like WeChat or Facebook Messenger for instance, where the conversation is used as an interface to access services.

Design proposal

The main principles behind this design proposal are not related to any specific product, but as an example, I've decided to imagine what a mobile OS could do in order to remove the friction in how people access services.

We won't go as far as what we described previously (services as an API), and we'll keep the concept of "app" in our system. Completely removing a concept like this one requires a lot of work on many design challenges, and the point of this study is just to draw the main directions.

We also have to keep in mind that we're not trying to redesign every part of the OS (settings, notifications,...). We'll focus our work on the way people access services (discover, acquire, launch, and use services).

We'll start by defining the main elements and principles of our design proposal (let's call it "the system" for conveniance): the actions, the cards, the feed, the pull and push mechanisms,...
At the end, we'll describe a typical user journey to have a better idea of how our system could help people in concrete situations.

The core values

Let's start by defining the most important guidelines that we'll try to follow when we'll design this new system.

This system will try to get rid of obstacles lying between people and their services:

In order to do that, we'll have to focus our system on 3 core values:

Two types of actions

End actions that lead to end services, are at the core of the system that we're trying to design. We want to remove anything that is not required to access services, but we also want to provide enough information to allow people to understand and to choose the best actions efficiently and wisely.

Examples of actions

We can define two kinds of actions:

In a long term perspective, we could easily imagine having more and more internal actions by completely changing the relationship between the services and the OS (services as an API).

A flexible wrapper...

One of the main missions of our system will be to gather information and actions related to specific contexts (for instance: all the different transportation options to go somewhere, all the actions and informations related to an email,...). That means that we'll need to create a lot of very different ephemeral groups of content that should help the user to 1) understand what this group is meaning (what concept it is illustrating), 2) understand what actions are available, and 3) choose wisely the best option between those actions.
In this document we'll call these groups of related actions and informations "contexts".

Contexts can all be very different: they can illustrate a very clear and simple concept (a person, a place,...) or some ideas that are more abstract (all the things related to the current location, a journey, an action like "call", a phone number, or even a text string like the first characters of a phone number,...). Contexts are even used for search results. In this case, we create a context that gathers everything related to the search query (in other words: the search results).

Because of this diversity, and because we want to handle each context in the most efficient way, we need to design a wrapper flexible enough to fit any kind of content (image, text, maps, videos,...).
However, we still want to preserve as much as possible the consistency of our system. The idea is not to be flexible for the sole purpose of being flexible, and we want to diverge only when we have a good reason to do so.
There is a balance to find, and our contexts will thus all share a common structure, but this structure will be made up of optional modules. This way, we'll be able to establish patterns at a macro level (consistency), to adapt our system at micro levels (relevancy), and we'll always have a fallback to handle any kind of content (reliability). the cards

Examples of cards

Cards are a very common design pattern. That's probably because cards are great to create and to highlight "entities". A card has boundaries (just like any box), has its own structure, and conveys perfectly the idea that we can handle it as a whole (just like physical cards that we can grab, move, stack, shuffle,...)... this is a great way to visually illustrate the idea of "entity".
Our contexts are very complex entities. We're trying to make it clear that all these elements form an unified concept, so it makes sense to think about the card pattern.

The structure of a card

Let's have a look at the structure of our cards (every part is optional):

The structure of a card
  1. Title: The name of the context (person name, place name, search query,...).
  2. Header: Additional information about a context (a map, a photo, address of a place,...).
  3. Actions: List of actions related to this context. On the feed (we'll explain the feed later), we only display the most relevant actions, and we'll provide secondary actions in the zoom-in view.

By taping the header of a card, I can access its "zoom-in" view: a detailed view of the card that offers other ways to manipulate the content (interactive map, photo gallery, more actions,...).

Zoom on the zoom-in view

Examples of zoom-in views

The rule is simple: every "more" request (more informations about a context, more options for a specific action, more ways to manipulate the content,...), leads to a zoom-in view.

The zoom-in view behaves exactly like the normal view of a card: when we know interesting things to tell about a context, we don't hesitate to be very specific, but when we don't really know what to tell, we always have a fallback to display (because every part of a card is optional).

This view is also the end point of our "internal actions", and is mostly suited for consuming information (reading an email, viewing an image, interacting with a map,...).
Users can access this view either by taping the header of a card, by taping internal actions, or by long touching any action. In the latter case, they will land on a zoom-in view dedicated to this action with more details about it (the app that will be launched for instance), and with other options when it makes sense (other phone numbers for a call for instance).

A new homescreen: the contextual feed

The context is the key of our system, and once we are able to understand the user, the challenge is to leverage this knowledge in the tools that we offer to him. Our best answer to this is the homescreen of our system: the contextual feed.

The contextual feed is just a feed of cards. Cards related to my current context pop at the top of my feed because our system has decided that they are relevant for this specific situation (and this decision is based on many factors like the time, the weather, the place, people or places around me,...). This way, cards never disappear from the contextual feed, they will just gradually be buried inside the feed as they will become less relevant. This mechanism fits really well the idea of "context" because cards that are the most relevant (and probably the most useful) are always within reach, but I can still dig to access previous cards.

The contextual feed is also helpful to discover services. The system will suggest interesting services to the user by pushing cards into the feed, even if the related app is not on the phone.

Search as main pull paradigm

The contextual feed is a push mechanism (the system pushes information to the user). That's the most important part of a contextual system.
However, despite all our efforts, we won't be able to answer perfectly all the different use cases that people will come across everyday. We need to provide a way for the users to pull information by themselves.

Our main pull mechanism (the user pulls information from the system) is based on a search pattern (more like a command based pattern in reality). That's risky, because that's really different from the current model of static libraries of icons (aka homescreens), but it makes sense if we want to remove the friction implied by the concept of "product". Plus, we counterbalance this effect with smart search suggestions that are not based on low value products (we could imagine search suggestions like "Facebook", or "Google Maps", or even "All my apps" but it really doesn't make any sense in our proposal), but that are based on high value services ("Go to X", "Call Y", "Z nearby",...).
Search suggestions are made up of a lot of different things: last search queries, contextual queries (queries interesting for this specific situation like "Set an alarm" depending on the time, or "Pay at Café Saint-Martin",...), and common actions ("Call...", "Go to...", "Nearby...",...). The goal is to avoid having to ask the user to type anything.

Results of a search query appear wrapped in a card. The context of this card is just the search query (that means that each search query generates only one card). A search result card behaves exactly like any other card (all parts are optional for instance), except that we'll display its zoom-in view directly because the whole screen and the whole attention are dedicated to it.

A typical user journey

Now that we defined the main elements of our design proposal, let's have a look at how that would work in real life situations.

My contextual feed on the morning

Every morning, when I check my phone for the first time, I can access interesting information to start the day : the weather, my calendar of the day, the latest news,...

Transportation card

Later on the morning, when I'm about to leave, a new card pops on my feed to suggest the best way to go to work.

Zoom in

I can zoom-in the card to access more transportation options.


I want to lunch in a restaurant that has been recommanded by a friend. I can easily gather all the relevant informations with the search mechanism.

Zara card

On the evening, I'm looking for a gift in a store, but I can't find the product that I liked on the website. On my feed, the system provides me with a card of services from the app of the store, so I can find the product that I was looking for without having to install the app.

Of course, this design proposal still raises a lot questions, and this kind of approach would require way more work in order to answer all of them properly. The idea here is just to start to question a model inherited from another era that is so deeply settled into our daily lives that it prevents us from considering other directions (and there are a lot of other directions).

There is a famous quote from Marshall McLuhan stating that "all media are extensions of some human faculty". Wilson Miner has perfectly seized the essence of this quote in his talk "When we build".
With so many new services and devices available, our faculties have obviously been extended, but they still depend on our good old homo sapiens brain, with its limited attention capacity and processing power.
Just think about the last time you walked in a crowded place like a metro station… can you imagine all the work that your brain was doing subconsciously to anticipate other people moves and to predict the best path? Now think about the last time you were using your phone and walking in a crowded place at the same time… we really don’t want to waste all this precious subconscious power.
Of course, we still want to send messages, to know when is our next train, or what is the best way to go to our meeting… but we don’t really want to interact with products, we just want to consume services.

We need something that will take care of most of our digital interactions in background, something that Marshall McLuhan could have described as an extension of our subconscious : an entire eco-system, with its own agents and rules that will help us to live in harmony with our new modern superpowers.

Don't hesitate to have a look at other case studies.

This great article from Paul Adams is probably the starting point of all this work:
Why cards are the future of the web

I also found some other very interesting links since I wrote this article:
Futures of text
Why Siri in iOS 9 Validates the Design of Ubuntu Phone
The end of apps as we know them
Why the end of apps theory is wrong
There is no app
App unbundling, search and discovery