Principles of Design - Android Style

Brian E. Roach / Monday, April 1, 2013

I recently attended a lecture at the SXSW conference given by Rachel Garb & Helena Roeber.  Rachel Garb leads interaction design for Android apps at Google and Helena Roeber led Android’s UX research from 2007 through 2012.  The purpose of their lecture was to explain the current “Principles of Design” that the Android teams are expected to use when creating their applications. 

The idea behind them is simple.  People use software.  People are emotional beings.  Software should make people feel good, and not bad.  That’s obviously pretty clear to anyone who has done any kind of development or UI design work.  The last thing you want is for the users to hate using the application.   What the Android team did was take that simple idea and try and create a system based on emotional response to help them, guide them, in their design work.

The truth is, emotional responses are integral to every user experience that exists, and software is certainly no exception.  There isn’t a developer alive who hasn’t had someone somewhere tell them how much they “hate” some application or program because it makes them feel “stupid”.   It’s not something new, but it’s worth rethinking. 

What Android did was take into account the research of Nobel prize winning scientist Daniel Kahneman, who began studying exactly how emotional responses impact people.  Their findings aren’t totally shocking, but they are in some ways surprising by the powerful impact that our emotions can have on us.  They found that negative emotions are not only harmful to our health, but may actually shorten our lives.  Positive emotions on the other hand, are actually a necessity for our ensured survival.  We require them on a daily basis.  They also protect us from depression, illness and promote both physical and mental well-being. 

As developers, we may not always take into account how the impact of our design or perhaps a bug in our software can impact a user.  But we should. 

The Android design principles break down like this.  There are 3 “Pillars” which are the fundamental concepts which all their principles are based on.  These are as follows:

 

Each one of these “pillars” has a set of associated principles.   The idea is that the principles are the pathway to achieving the concept of the pillar.  The principles for each pillar are shown below:

If you look at the principles for each of the pillars, you can see how they are designed to support the overall concept of the pillar. 

Enchant me is, according to Garb & Roeber, filling people with joy.  It’s about giving them beautiful images to look at and providing graceful and seamless transitions.   It’s about letting users customize and design their space to suit them, and allowing them to directly interact with items, touching them, in effect.  

Simplify my life is about making things simple for people.  Explaining things clearly, either using images or brief and to the point words.  It’s about bringing attention to the things that are important.

Make Me Amazing is all about avoiding what I feel is the number one negative impact of software, making people feel like they don’t know what they are doing.  It’s about empowering the user and making them feel capable and smart.  It’s about letting them feel in control of things. 

It’s simple really.  Good design allows user to feel good about using your product.  Bad design isn’t.  

In days gone by I used to train people on using Microsoft Office.   The training was usually based on some kind of basic outline for how to use Word, Outlook, Excel, etc.  And more often than not, it was filled with replicative ways to accomplish the same task.  I remember the rational clearly.  Not everyone wants to do things the same way, and so we’ll show all of them a dozen ways to do anything! 

This only led to users being overwhelmed by options.   The number one complaint I got in these classes was “There are too many ways to do things.  Just show me one way.  It’s all I need. “    Think about that simple statement and how the principals Android has put together apply.  There are pieces to each pillar which apply to just that statement. 

  • Let me make it mine – too many options can prevent a user from feeling like they can make the application behave how they want it to.
  • Keep it brief, Only show me what I need when I need it, If it looks the same it should act the same – all of these can be impacted by too many choices.
  • Give me tricks that work everywhere, it’s not my fault, sprinkle encouragement, make important things fast – an overwhelming option set defeats all of these principals.

While this lecture was clearly targeted at UI and UX design work, I believe it can be applied to ALL aspects of development, and should be.  There is a very simple principal we can all keep in mind which will allow us to incorporate these principals.  Look at the ratio of positive and negative interactions which occur during any given process or experience.  If there are more positives you might be on the right track.  Why might?  Let me explain.

There is a very old saying  - “You only get one chance to make a first impression”.  It’s simple truth.  And underneath that is the concept that negative experiences don’t tend to go away.  They linger.  In fact, think of it like this.  It takes 3 positive experiences to essentially balance a single negative one. 

During their presentation Garb and Roeber used the example of having two jars – one for positive experiences and one for negative.  If you trigger something positive you get to put a marble in the positive jar.  If you trigger something negative, then 3 big marbles go in that negative jar.  It’s very clear how easily a negative experience outweighs a positive one. 

One example came right in to my head when I was listening to this discussion.  I remember doing some debugging work with a friend of mine, and we were trying to determine the cause of a load error for a piece of code.  There were a variety of links that came with the generic Microsoft error code, and finally at one point my friend stood up and just stomped away from his machine.  I wasn’t sure what had actually happened, but when he came back he walked over and he sat down and looked at me and said “You are not going to believe this, you’re just not.”

“So, I’m going through all the recommended fixes for our problem, and none of them work.  Not one.  So there is a link for additional assistance that pops up.  I click on it and you won’t believe what it says.”

“What?” I asked. 

“First it tells me maybe I should ask someone with more experience than me.  Then it says if that doesn’t work, maybe I could ask a friend.”  We both laughed, but I think you can see my point here.

HavingC software basically tell you that you are –

a)      not smart enough to understand this – get a more experienced person  and maybe you should

b)      phone a friend, well it’s not a positive experience.  Clearly.

My point is, if we all can find a way to keep the idea that any process, any GUI, any piece of our application should fall into these concepts, we’ll end up making creating software that is actually useful to our target consumers, and they won’t need to phone a friend to understand how to use it.