The fact that something will “only take a couple of seconds”  is no excuse for disrupting the user experience and when considering to ask users for a favor, developers should not only think about what it means for their users, but what it would mean if similar products employed the same functionality.

Years ago, when there wasn’t such a flood of products, it was completely reasonable to, for example, ask the customer to register for the warranty,  fill a form or make a phone call to verify their serial number. Things have changed, however. People are consuming new “stuff” every day and these little interruptions from our everyday lives become a problem. It might be a one-time request to ask your customer to create an account to be able to use your latest app. But what you might not have considered is that people are using hundreds of products just like yours and the annoyances are multiplied with them

This applies to every kind of product, but apps and online services are the ones that annoy the most, because they are often continuously updated and, because of that pace, often don’t get the amount of consideration they deserve. Also, being relatively new to most people’s lives, customers are often open towards new ways of doing things. This doesn’t mean you should make use of that fact for the wrong purpose. People have a limited attention span and designers should use their attention to focus on the core product and not to get ratings on the App Store.

If people would get in they car and would have to dismiss a “write a product review for this car”-popup, there’d be an outrage, but with apps, they’ll grudgingly dismiss it or even do as you asked (and then realize that you’ll keep asking because there’s no API to tell if the user rated the app or not).

Often, the tradeoff is to only to ask people once per week. This would be a good Idea, if you would be the only one doing that. But there might be dozens of apps on the customer’s phone and the once-a-week turns into users having to dismiss multiple “rate on the App Store”-popups a day.

I have hundreds of Apps on my phone and I’m the customer of a lot of online services. Some free, some paid.  Every once in a while, Apps will get a major overhaul and greet you with a “see what’s new”-screen.

While you might have good intentions with that, imagine what it does to your customers. Even if you only do this every six months, a customer might use 200 similar products, wich means that they’ll have to go through the “hello, we changed everything”-process every day.

There might be hundreds of products like yours and just as their combined functionality might enrich people’s lives, their combined required micro-maintenance annoys them.

If you make a design decision, don’t just think about what it does to your customers but imagine what it would do to your customers if all  the products they use would do things in the same fashion.

Do the Math!

There is an iOS App available for my car that allows me to pre-heat my car while it’s charging. (Which is awesome in the winter).

Obvious usability problems with a software like that include crashes, server downtimes and connection problems. However, these are not part of the product per design.Micro maintenance, however is designed into the product.

Said app requires me to enter a passkey whenever I want to access the controls of my car. There is no need for that, because my Phone is already locked with a PIN. In addition, whenever the App is being updated, it will ask me to “register” my phone again. In the process, the server will send me an e-mail where I need to click a registration link. I don’t know why, but for some reason, the registration code in the e-mail is only visible on OS X Mail and not in iOS. I have two phones registered with the app and for every update I need to go through the process for each of them every time the app is being updated.

This may sound absurd, but many services employ similar mechanisms. The core problem is that the designers of these products don’t take into account the total annoyance created by these mechanisms.

How does one measure annoyance?

There isn’t a scale for that but a good start is to use the same approach used for the actual core user-experience of the product.

Often, during product design, a lot of resources are spent for optimizing the core experience of the product. Simple usage metering might show that a big part of the time spent with the product is spent not for the core experience, but for micro maintenance.

Pressing the “pre-heat” button in the app takes about two seconds. re-registering the device after an update might take several minutes and entering the PIN already takes more than two seconds. This means, about two thirds of the total time spent using the product is just for micro maintenance.

If you consider that our everyday activities are increasingly influenced by hundreds of small products, each as complex (and prone to micro-maintenance) as said car-heating app, in a couple of years, people might spend half of their time just updating apps, converting databases, reading license agreements,  and dismissing “rate-this-app” popups.

“but we need to do this, because…”

An engineer’s job is to find a way. Good user experience design involves the whole product, not just the core functionality. No great app will waste your time with unnecessary things, just because someone came up with them in a meeting as a quick solution.Also, why does everything have to be changed. As a Designer, you might think your product is in the center of the universe, but it isn’t. If you make, for example, a flight-booking app, you might think it’s a good Idea to change the user experience every couple of months and tell people about the great new features you implemented. Since you’re using your app every day, you think, things don’t change that often. But how often does the average customer book flights, and how often would they use your app? If you overhaul your service, let people register, ask them to write a review or read some agreement only every couple of months, it could mean that someone will encounter one of these things every time they use the app.

The biggest problem is not that micro maintenance is necessary and there is no way to avoid it, but that it’s not considered a core part of the experience and thus doesn’t get as much attention during product design.

As a designer, you need to take into account that the usability isn’t just the core functionality, but the sum of all interactions with, or related to, the product.In user experience development, priorities shouldn’t  be set based on synthetic usage patterns but on real-life scenarios.

You might have the best interaction designer in the world, but only let him design a part of your software, you’re wasting all the potential. A part of your software is also the activation process. If your software is awesome, but people have to activate it by typing a 40-character CD-Key where zeroes and “O” are almost indistinguishable, user experience has already taken a hit.

This may sound trivial, but in many companies, designers only have a limited scope and thus can’t design a consistently hassle-free product.

While it is a necessity to keep user interaction secure, If everyone asks people to change their password to a new one that contains five numbers and three ancient-Egyptian hieroglyphs every 20 days, we would be spending all day to change passwords!Everything can be improved and just because a feature is an absolute necessity, it shouldn’t be excluded from user experience design.

What should I do?

• Do research: Find out how people respond to the little tweaks in user experience. You’ll be surprised.
• Don’t settle with the quick solution: “but it only takes a few seconds” is not an excuse. Multiply these couple of seconds with the amount of apps on your phone and think about it. Will your customers have to spend three seconds a day getting redirected to authentication servers to log in? How about five minutes?
• Let people do their work: If the product designer can’t design the product… (surprise!), he can’t design the product!
• See the product as part of its environment and take advantage of it. (that could be physical or simply an app in an ecosystem of apps and a particular OS, for example by using TouchID instead of implementing your own passcode)