Live Blogging at DeveloperWeek: Good Rules for Bad Apps

I'm live blogging my experience at DeveloperWeek, en masse, at my site. You can follow along there, or look for me to post some talk summaries here, individually.

This is a talk by Shem Magnezi, engineer at WeWork. It's a series of rules that you can follow for building apps that suck.

He's apparently given this talk a lot, and it shows. The slides are fun/engaging.  I'm currently looking at one that has Christian Bale's batman confronting Heath Ledger's Joker, and life is good.

He wants to clarify, up front, that he's talking about "bad' apps not in the colloquial sense of "bad as good," but in the sense of bad, making you miserable.

He also mentioned that he used to talk a lot about how to build good apps, but that it could be more helpful to think in terms of how you ruin apps (and how to avoid that).

So, how does one ruin an application?

1. Ask for As Many Permissions as Possible

Consider a flashlight. One screen. Single button to turn the flashlight on and off.  Simple stuff.

So it needs to be able to take and record video, right? I mean, obviously. Sure, you may not need these permissions now, but who knows what the future holds?

And then, it probably goes without saying that you need to prevent the user from using the app altogether if they don't agree.

2. Don't Communicate Anything

Alright, now let's say that we're building a reminder application.  What do I have to do over the next week?

When it loads, you see nothing there.  Great!  Nothing to do.  Or, wait... is it just that your reminders haven't loaded?  Do you not have a connection?

A good way to make a bummer of a user experience is not to communicate anything about its current state or what's happening behind the scenes.

3. Don't Save Screen State

Let's move on to a less trivial app: buying a few books through an eCommerce app.

Add the books to the cart, go to checkout, and then, well, fill in a lot of information. First name, last name... you get the idea. Then you need, of course, your credit card information.

So, as you reach into your wallet for your credit card, the screen rotates accidentally.  Oops, everything is all gone. For some reason, that triggers a refresh of the form.

There's no better way to create a maddening experience than forcing you to fill all of that out again for no good reason.

4. Don't Optimize App Size

You're looking through the app store and you decide to install an app. You go into the store, find some well-reviewed, heavily downloaded app and you get ready to go.

But then, wait a second. Why is this app 70 MB? Yikes!  What if you're somewhere with a bad signal or you don't have time to wait.

So you skip it, do something else, and later wonder why the download is so large. Then, maybe, you dig into it and realize that they're packaging in all kinds of images of different sizes and iterations, perhaps for features that you're not even going to use.

But then maybe you dig in further and find that there's a huge file containing all sorts of phone numbers in different countries.  You probably don't need all of those.

And maybe, this continues with a lot of different examples, all of which combine to add up to a lot of unnecessary data coming along with each download.  This is an experience that Shem has had, and it stopped him from downloading an app when he could have used it, which, obviously, is bad.

(As an aside, this is an interesting analog to the SOLID "interface segregation principle.")

5. Ignore Material Design Specs

Have you ever seen a beautifully laid out app that had buttons and a general user interface paradigm that was completely new and foreign to you? That's an interesting conundrum.

You may like it aesthetically, but you'll have no idea what to do. We've come to expert a mobile experience where things are intuitive, lining up with what we're already familiar with.

So if you want to create a bad app, you can make sure to do stuff the user has no experience with. Bonus points if it's not even aesthetically pleasing.

6. Create Intro, Overlay, and Hints

Can you picture an app that shows you a LOT of explanations? It requires six pages of onboarding wizards to help you understand what's happening. And it pops dialogs to help with new features, often which are non-dismissable.

Some of this, I'd imagine, can be useful. But a good way to create a bad app is to bludgeon the user with exposition at every stage of use. If you find yourself needing to do this, your app probably needs to be more intuitive.

7. Ignore Standard Icons and Widgets

The phone providers give you a lot of standard icons and widgets on the screen.  You should probably use those.

But if you want to build a bad app, use your own mysterious ones that nobody understands.

8. Create Your Own Login Screen

You know the feeling of getting a new app, and immediately being prompted to generate login credentials? Well, take that, and add to it the feeling of having to hand type in and then remember a new password.

Bummer, right? Wouldn't it be better to just log in with Google or Facebook or whatever?

When you ask new users to use a login screen that you've hand-created, you're asking them to trust you.  A lot.  You probably shouldn't do this unless you want to build a bad app.

9. Support the Oldest OS Version

When you're a mobile developer, you need to look at the different OS versions that you need to support. You can actually go and check out a breakdown of the current user base to see who is using what. You make decisions with this, like the minimum version to support.

Product management, of course, by default, won't want to lose any users. "We should go back and support all the things!"

But they don't understand the complexity of checking for those users, adding conditional code, and generally juggling all of these concerns.  You, as the developer, will.

But, if you want to build a bad app, let yourself be overridden on this account. Support all the things.

10. Make Decisions without Data

Imagine an app with a button, like a "donate" (and give us money) button. You probably want as many people clicking on this as possible.

So the product manager wants this button to be green. But then the designer has the idea that the button should really be red. And the developer, well, the developer doesn't care about color, but wants it to be at the place in the screen where it would be the easiest to implement.

What should you do?  Well, if you want to build a bad app, you should probably duke it out, going with the strongest opinion.  But if you don't want to build a bad app, you should probably rely on real, measurable data to see what works best.

If You Don't Want to Build a Bad App, What Should You Do Instead?

So, flipping out of fun sarcasm mode, what's a quick list of things you should do instead?  Here is Shem's guidance there, in a nutshell:

1. Permissions?  Instead, ask for only what you need
2. Communications? Instead, notify about loading and empty state.
3. Lose screen state? Instead, save screen state.
4. Large app size? Instead, use vectors and modules.
5. Unknown UX? Instead, use material design whenever possible.
6. Have introductory exposition? Instead, let them explore and offer hints in context.
7. Mysterious icons? Instead, use predefined icons.
8. Roll your own login screen? Instead, use single-sign on.
9. Support every framework version? Instead, know your users and strategically target them.
10. Make decisions with no real data? Instead, measure data and use A/B testing.

He has more rules, which you can find at his site.

My Takeaway

I really enjoyed this talk a lot. He's a good speaker and it's an engaging and relatable premise, but my enjoyment goes deeper than that.

Like anyone, I spend a lot of my time using my phone for very tactical, often time-sensitive purposes. I'm trying to catch a ride or look up whether my plane is late or whatever. So my phone is present for some of the tensest, most annoying moments of my life.

And it is these moments that provide some of the most intense technical frustration. Waiting for something to take forever to load when you're already late, or getting bonked with some kind of cryptic error message that won't let you proceed to the next screen.

And when you're confronted with these moments, nobody around you cares. They're not interested in the temper tantrum that you're bottling up.

So for all of those angry, frustrated moments when I had no one to confide in, I feel vindication from this talk. Shem captured a bunch of frustrating, relatable moments and made them into actionable lessons, in a funny way. It's nice to know that I'm not alone in my intense frustration with mind-boggling UX choices.