Category: Launcher

I’m a dabbler in matters of neuroscience and cognition, I listen/watch things from Sapolsky, Dennet, my kindle is loaded with Sam Harris, Metzinger and love to torture my Sunday breakfast partners about what our fear of snakes teaches us about App design.

A little knowledge is dangerous, but can be applied to Mobile App design and human interaction — particularly how Apps help us and stress us. From years of mobile product experience, I believe a design’s balance cognitive overload and resultant stress should be a major counter-balance to a Product Manager’s KPI’s to moooaaaar session time in the App.

Cognitive overload from mobile devices is an “un-understood” problem for users.

The results of a recent survey of 14,000 people revealed statistics that imply “the more competent you are with Apps, the more trapped you are”.

The clear sufferers (“I feel more stressed”) are the most powerful adopters — the 26–55 year old range and in particular 36–45. These people are mid-career, mid-family and if they are like me they have more than 5 chat Apps with business and social conversations appearing in all of them. The chat is happening while dropping the kids at soccer and their colleague on the chat wants an immediate response (they are sitting at their desk).

Older age groups likely have less Apps on their phones and less competing social signals.

The problem is “Un-understood” because we are all frogs slowly being boiled in the pot — more Apps, more usage and the stress (temperature in the frog metaphor) will keep increasing. Each App has initially been optimized for single purpose flow but:

• Shouting: each App now contains notifications forcing the user to context switch (at massive impact to flow and stress production). Moreover, Apps compete exacerbating the stress.
• Feature Discovery: any successful App has more than one feature which the Product Manager wants to introduce to deepen engagement and utility.
• Visual Clutter: Features need to be JTBD-focussed when a user wants them, otherwise “out of the ways” when not. Its well understood that desktop design does not map to Mobile App design, but users still expect the same features in the Mobile App.

I propose a solution for designers that leverages the existing cognitive processing hardware humans have without creating overload.

What snake detection teaches us about layers of cognition

A fascinating example of visual cognition is the “Snake Detection Theory”. Simply stated: when we were monkeys, snakes (or their giant predecessors) were an evolutionary threat.

Our evolutionary response was:

• natural selection: the survivors (us) developed visual detection wiring to accelerate response to “snake-like” shapes hidden in the leaves.
• Signals sent to the adrenals (all the way down in the kidneys) trigger life-preserving flight/fight response.
• This acts waaaaaay faster than prefrontal cortex (PFC) rationalizing, this which spins up a few hundred milliseconds later and provides more sophisticated analysis of the threat. (“ahh, its just a stick”).
• today we retain that biological ability and will startle if a rope or stick is lying across our path.

Another layering example (unrelated to stress) is our in-built facial symmetry detection as a gene preservation trait. (“If I can mate with this symmetrical partner then my offspring will have greater chance of doing the same”).

So our visual machinery has innumerable layers processing below our consciousness: performing edge detection, pattern matching, classification etc. App designers can take advantage of this knowledge and apply it.

Layering for Cognition

The solution to cognitive load in Mobile Apps has been to “dumb-things-down”. A well-designed mobile App should assume the user’s IQ is halved: recognition that mobile Apps serve people on the run, getting out of cars, crossing streets — these activities split their attention and effective IQ. Therefore UI JTBD is a primary design goal.

This does not mean the App should be less rich or have subtracted (or unbundled) features. Throughout the user’s journey, the unlocking of new features can be done outside the initial use-case — enriching value to the user.

I propose user’s already understand the presence of a “signal layer” that is separate and distinguished from App design. In our blog, we cover a lot of tear-downs and examples where Facebook, Google, LinkedIn are already using a well-understood layer that users’ recognize and process automatically.

Just as the brain has high speed “Snake Detection” that executes well before the PFC gets involved — by “layering” in a UI design we are consciously reducing cognitive stress. Users already understand this layer and cost zero processing power, context switching and interruption to flow to be aware of them.

Users automatically know they exist and can return back to them as clues, guides and signals from App complexity. This is a far better solution than notifications, visual cluttered UI or removing the feature from the mobile UI completely!

Common Signal Layer elements

The good news about layers is that we use them already. We just don’t have an organized way of talking about distinguishing engagement (or journey) elements from App objects at the design phase.

Here are some common engagement object in Mobile and Web UIs.

Modals — the classic disruptive stop to flow. (“do this now”).

Tips — less intrusive “clues” that should be presented contextually to aid a users understanding

Placeholders — the light gray text that provides a clue in an empty text field. This is a nice use of screen real-estate to offer help without visual clutter.

Launchers (tooltips) — graphic clues that offer expanded help to the user in the context of a specific object, field or actions.

These objects cognitively sit in this signalling layer above (or distinct from) the application functon. Great Apps have layer of content and a layer of guidance (“signalling”). See our tear-downs for examples.

Lets take a look at how Launchers play a role as a “signalling layer”.

Launchers are one of the most common tool-tips and universally understood, its usually small, unobtrusive but in a moment of confusion, the user knows there is access to more information. Of course the other variation of this is the standard Look at me button. The benefit of a button is that obviously its known as a clickable element but the downside is the screen-estate and conflict with the App’s own features. Perhaps the button starts to look more like the application and that probably not what you want.

This pattern is also now understood by everyone, even your grandmother. Specifically: I cognitively know Netflix telling me, or even urging me, to find out what special gift is awaiting me when I touch the badge.

Small things are underrated

As mentioned earlier, our evolutionary survival has benefited from negative biases. So usually we only give significance to things that annoy or threaten us. So tooltips and launchers are taken-for-granted. That’s fine but is it a clue to how we should design.

One of my all-time favourite acts of design genius beats anything that Jony Ive ever came up with.

The Facebook “like” is deceptively simple, but it punched directly through to human reward systems. That little icon has injected more dopamine into human blood streams than ever before!

In summary, launchers are like a great waiter at a great restaurant….A launcher never over-services, never shouts, is available when needed and delivers the goods.

• Get the Job Done
• Get out of the way
• Measure the success
• No Code

Too Subtle? (Your Apps undiscovered features)

As a Product Manager, you have to defend your design from your management team. If you are too cautious in alienating users by over-burdening them, then risk them not graduating to activated users.

Bad actors like Facebook have set precedent for spammy behavior but they are the in rare position that their spam is perceived as a communication from a friend, so the dopamine shot

Discovery — we think that contextual, temporal feature discovery is the antidote to cognitive overload. The delivery mechanism is on different layer that the user can readily access and understand that its separate to the Apps utility but can unlock more utility (at will).

The UX analog of MVC

Programming radically changed (improved) with the introduction of Model, View, Controller (MVC) and its subsequent variants. Separation of Concerns allowed programmers to organize code according to recurring roles (data representation, date presentation).

To my knowledge User Journeys and engagement are still largely considered “more art than science”. I challenge that at a minimum model is an “App Layer” and an “Engagement Layer” — and that this model already exists but is not formalized.

A slightly more radical approach is an “App Components Layer” and an “Engagement Layer” and the user has access to the latter.

The Long View — add/subtract App components

Components — Why shouldn’t Apps be more like a dashboard? Why can’t they be componentized to allow users to show/hide/discover/unlock elements. If I don’t user UberEats, then the presence of it in the App is clutter to me. We know it serves Uber’s interests to have it in my face — but I pay the cognitive tax for that?

In devop’s lingo: this is “Docker for App features”.

Many Apps/sites already use a capability called “Feature-Flags” that allow add/subtract of components (and component versions) under developer control. It allows for A/B tests — but its not at the user’s option, its something that could be put under the control of users. We don’t know the pattern for that. As an extension of layering I’m excited about this area as a major shift in app design and delivery.

If I decide I want to get UberEats back in my app, then the engagement layer pattern allows me (the user) to easily select that.

User Access to the Engagement layer — using the layer diagram above, a user gesture would allow a user to access the orchestration capabilities of the App. To show/hide features and to strip back the interface to the utility they supports their JTBD. Such a gesture and orchestration UI

Uniformity and Predictability —Consumerism has programmed product designers into thinking about fixed designs. There is nods to “Customerization” in Volkswagon bugs, Mini’s and Shoes of Prey. However, Apple has built the most valuable company in the world by avoiding Paradox of Choice.

Temporality and Context — In the early days of the mobile push notification space, we learned that intersecting location context with user interest had far higher push notification open rates than normal (or spammy) marketing pushes. Basic design for “whats in it for me”. All Apps should be using contextual computing to add value to a user. The most obvious consumerizations are stories around amazon/netflix recommendations, youtube home suggestions (with many arguments for/against personalization).

Push notifications, Alerts and Popups — Even in 2017 we still get bad Apps that ignore Temporality and Context in push notifications and emails. Contrast this with good apps like Slack that makes a nice job of snoozing alerts and EASILY setting office hours.

User Retreat — If we don’t solve this problem, user will retreat:

1. by uninstalling (good-bye relationship)
2. disabling key parts of the product to escape shouty applications, I’ve mentioned in previous posts about increased happiness by simply uninstalling Facebook and Twitter apps from my phone. (Even today Facebook emails me every-bloody-day to “get back onto facebook”).
3. Tech detox — a relatively new term but one that will increase if App design continues to be driven by harmful UX patterns.

Summary

App designers and Product Manager can organize their thinking into layers:

1. Design and Experience Layer (where all the code gets done)
2. Signal and Engagement Layer (which maps a user’s journey and orchestrates what “nudges”, clues and help move a user into deeper engagement and understanding of the application).

It makes sense that the cognitive discoveries should be used productively to help make less stressful and more useful applications.