The Appification of Everything & Why it Needs to End

Image for post
Image for post

Contemporary product design is obsessively focused on app-based user experiences. Control your lights from an app! Control your speakers! Even control your car! These products are usually designed under conditions where everything goes right — and when they do, the convenience factor is amazing. But what happens when the real world intersects with this idealized approach?

In 2011, I found myself sitting on a curb somewhere in Portland, far from home. My partner at the time had just discovered a then-innovative service which offered the promise of on-demand rental cars through a smartphone app. But that night, the only nearby vehicle was in a dead zone. After multiple attempts to get a signal, including waving his phone around like an antenna, he couldn’t get enough signal strength to enable the app’s unlocking process.

We wound up sitting there for at least 10 minutes with our hands full of groceries and other items. I was impatient. He was accusatory. He wanted to show me how amazing the tech was, but every time he tried, the connection would fail.

Instead of just an app, I wondered, shouldn’t everyone on the service also have a universal key fob backup? But somewhere along the line, the company’s product team decided a smartphone app was the higher (and only) priority. And in most cases, it was the most convenient option.

A core principle of good design is graceful failure — that when a product fails, it should still provide the basic service of the product and somehow work. For nearly a decade, however, we’ve resigned ourselves to accept the exact opposite design approach, even at the expense of our personal wellness, or relationships.

Call this the product trend of “always-connected, app-first development”: The belief that the best user experience requires cord-free connectivity, and ideally, connectivity through a smartphone app. And to judge by recent reports, the principle’s underlying assumptions have not been addressed since 2011. If anything, the bad outcomes they cause have only become worse.

The problem with app-based real world services

Image for post
Image for post
A “smart lock” owner’s urgent tweet while his children are trapped outside their home

Customers love the promise and convenience of app-based technologies, but we often ignore the cost of failure. It’s not just, say, the minor inconvenience of an app asking you to install an update before you can use your smart TV, but serious disruptions to our well-being:

Image for post
Image for post
Petnet’s Terms of Service warns users about unreliable service

We read service outage stories like these seemingly every week, and have become numb to the fundamental reality: The idea of placing the safety of yourself, your child, or another loved one in the hands of an app dependent on a server you cannot touch, control, or know the status of, is utterly unacceptable.

When your only tool seems like a smartphone, everything looks like an app

Image for post
Image for post
Photo by Daria Nepriakhina on Unsplash

As with touchscreens, which have their own problems, the appification of everything seems to be a response to the pervasiveness of smartphones — as if the only way to create a satisfying user experience is to integrate it with the iPhone as much as possible.

The assumption seems to plague post-iPhone start-ups in particular. A few years ago, I was consulting with a successful connected speakers company on Calm Technology. After my presentation, a member of the product team (a recent Stanford graduate), piped up with his own feedback:

“We plan on removing the buttons on speakers and have them controllable only by an app.”

I countered that it would be a terrible idea to remove physical buttons for volume. Even though smartphones have removed many of their buttons over the years, I pointed out, buttons for physical volume have remained for a reason.

It’s ironic how, at social events, people in technology often jokingly mock their own dependence to their iPhone — but then back at work, help design services that make us even more dependent on having a smartphone with us on our person (and fully charged) at all times. Especially for products that have nothing to do with the phone itself.

This problem is compounded when CEOs don’t even test or use the products themselves, or wave away connectivity concerns. That failure in leadership is evident whenever a company’s tech team gets visibly annoyed with people who have issues with their app, as if that was “user error”, not a fault in its design and development.

A Calm Approach to Connectivity

Image for post
Image for post

What happens when you’re in a product design meeting, and your boss, client, or co-worker insists on an app-based solution? Are there ways to still satisfy this demand, but in a human-centered, reliable way? It’s definitely possible to embrace the convenience of connected devices while maintaining a UX focus on the simplicity and solidity of calm design. The key is insisting on calm design principles early on, throughout both the design and implementation phase.

Design the product to work even without the app: App-based device controls are occasionally the best option — assuming the consumer’s phone is connected and charged, the app is updated, and is quickly findable amid a sea of other apps, which is not often the case. The only way to guarantee 100% uptime is to always include analog control alternatives, including dedicated buttons and cable options, and ensure that options exist to control products without using the cloud. Volume control should always be analog: There’s nothing calm about a device speaker being too loud or too soft, and struggling to adjust it without controls that have been part of our technology user experience for over a hundred years.

Enable an analog backup if the product can’t reach a web or cell connection: For apps that support critical real life needs, it is crucial that an “offline mode” is baked into the system from the beginning, no matter how confident a company is in its servers. Consider the pet feeding service which went awry when its server went down: An internal chip could have been easily installed in the serving system, programmed to dispense food at regular intervals, or at time periods set in advance by the owner; if connectivity to the server was ever broken, this backup system would be triggered. without needing to be connected to an external network.

Image for post
Image for post
Photo credit: Jessica Merz

Finally, for vehicles and vehicle services: no matter how “smart” they’re described to be, always include a physical fob. Because there’s nothing more instructive on the failure of connectivity, than contemplating that reality while sitting in the middle of nowhere on the side of the road.

Have you ever had an app-based product fail on you in an unexpected way? Or as a designer, felt the pressure of creating app-focused solutions from inside your team? How have you countered these demands and ensured that people still have a backup plan if something goes wrong?

Written by

Design advocate, speaker and author of Calm Technology + Designing With Sound. Research Fellow at Institute for the Future. Caseorganic.com

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store