The absolute minimum Android developers need to know about UX — Part 2 of 5

May 15 — Corrections following the text

In the first part of this article series we introduced the concept of Visibility as a UX principle of design. In practical terms, Visibility in mobile design can be achieved by focusing the users attention towards core actions by making them clear and legible. This principle of Visibility also extends to cluttered interfaces. Having too many actions on a single interface can effectively hide the actions you are trying to get the user to accomplish. Sticking to a small number of core actions per page will go far in your UX design.

Next up is Affordance. While much more complicated (at least to me*) than many of the principles, apps that implement Affordance properly have a much more natural look and feel to them. If you wondered why some apps seem magically simple, it’s because they implement Affordance effectively

Affordance

Affordance is the principal that your design should give obvious clues on what can be accomplished without explicitly indicating it. Buttons that look like they are physical buttons allow the user to understand their meaning without having to guess at their functions. In industrial design, affordances usually reflect some physical capabilities. For instance looking at Lego pieces for the first time you can naturally see how the pieces fit together without consulting the manual (hopefully). While this natural mapping seems intuitive for physical objects, Affordances in mobile design become slightly more complicated. Mobile devices are constrained to a 2D digital touch screen and don’t have much physical space to work with. Even at that, the same principles need to apply. Buttons should look and feel like physical buttons, date pickers should look like a calendar and the layout of components should have an intuitive feel to them.

Let’s see how this applies with an Android time slider;

 

In both these examples, the component functions as expected. A user can change the time but in the left design the “natural” look of the circular face give the familiar interaction of a physical clock(1). The simple change on the design reduces the cognitive load for the user and makes the interaction much more natural. That is what we are after in our designs


Google’s Material Design team makes some great steps in this area. I‘ll be honest when I was first introduced to the concepts behind Material design I tossed the ideas into the “feel good artsy terms that marketers love but developers don’t actually use” category. But in terms of Affordance they start to make sense. The idea that digital space should reflect physical paper and material lend really well into more “natural” Affordances and interfaces. It’s almost like they thought of this when they were building it.

People evolved to interact with physical items in a spatial world, so if you want to get the most out of your design consider how you would implement it in a physical space and translate that into mobile.

The first thing about physical space is that it has height and depth (usually I don’t go out much so I’m not sure). To take advantage of this you can “layer” your interface hiding details beneath other features. Android provides a simple way to implement “layers” through the use of elevation. Either directly within the xml (API 21+)

<ImageView …
 android:elevation=”8dp” />

or using the ViewCompat libraries (my preferred way)

ViewCompat.setElevation(View, int)

This allows you to separate layers and isolate content. This is important because it creates the illusion physical space and makes it much easier to create components with where the user understands the function. But how do you decide what to elevate and separate? Well that’s complicated, but since we are trying to do the minimum, try separating controls from content.

Separate layers of content and control by adding elevation. Controls elevated off the page give a good indication they are actionable

 

The Floating Action Button was designed for this purpose. Elevated from the content it provides a perfect way to isolate controls. But it doesn’t only have to work for controls.

 

Facebook. Like you didn’t know

Facebook. Like you didn’t know

Cards are essentially content and controls all together, and automatically give the impression that they are clickable. [Tip: Don’t make the mistake of not making cards clickable. That will confuse the user]

Using cards and elevated buttons will go a long way in your design. Just implementing those will help your users out significantly.

Bare with me here, one more quick concept to cover…

Motion

A second noticeable feature of IRL is that it tends to move around. That motion can indicate function and therefore, Affordance. In industrial design motion is difficult to achieve but in mobile we have the luxury of moving components around on a screen as much as we want. Motion, or Animation, is a great method of indicating to the user what the function of a specific item is without having to explicitly tell them.

 

But tackling Animation within Android is a big and daunting project (for this article at least, we will address animation in future parts). While the animation framework in Android is getting better, it is still plagued by performance and complicated legacy issues. Thankfully, taking the lazy way out we can indicate to your users the functions of actions (Affordance) through the use of View Transitions.

Transitioning layers or components between scenes is the easiest way to show to the user that common components such as action buttons carry over from one state to the next. The obvious movement of the components gives an indication to the user about their functions. If you transition an action component (like a FAB) from one page to the next you don’t have to indicate it’s new function. The user will already know what to do. Same applies with content. A state transition on content means that the user can intuitively understand where the content is coming from and going to. Remember the layers from the previous section? They make great targets for view transitions. Making those layers transition between state is a natural and expected change for the user.

Summary

  • Affordance is magic. Make it less magic by making your controls similar to their physical counter parts, like calendars and clocks.
  • Isolate controls and content using view elevations.
  • Cards are great way to display actionable content, just make sure they are clickable
  • Make liberal use of transitions to show the state of content and actions have changed
  • Don’t animate components between layers. Too confusing.

Corrections

/u/VitoCassisi makes a great point about what I have been calling Affordance but Norman refers to as a signifier.

Excerpt from Design of Everyday Things

Excerpt from Design of Everyday Things

 

Like I mentioned Affordance principle was complicated for me to wrap my head around in a practical sense. For this article I’ll keep the Affordance name and principle however if you are ever invited to a dinner party and the topic comes up..you should probably refer to it as a Signifier. That should win over almost anyone at a dinner party.

  1. I guess you could consider the right design like a digital alarm clock. But digital alarm clocks were a poor design decision made when displays were limited on the characters they could display.

The absolute minimum Android developers need to know about UX — Part 1 of 5

“I’m just a developer, UX isn’t my job”

I get it. MVP vs MVC, Retrofit vs Volley. Am I leaking views? What about performance? Do I need to build for API less than 19? These are all key questions and as a developer you need to address all of them. [ Hint: MVP is great for testing, Retrofit works with RxJava and you are using RxJava right? Leak canary, and it depends, are the users with API < 19 your target?]

We discuss different architecture and technical decisions because in the end it makes development faster and simpler for us to manage. This makes developers happy. Does that extra abstraction layer help or hinder your architecture? Is your model too detailed or not detailed enough? Did Jake Wharton wear a blue or green shirt to DroidCon and should I do the same?

Those architecture discussions and framework libraries reduce the cognitive load required to build an app. That’s a complicated way to say “libraries solve problems so I don’t have to” and I can spend effort building something awesome (or not, I’m not your boss)

On the same principle users engage with your app because it reduces their cognitive load in achieving their specific goals. Finding music, instant messaging, sharing photos with friends. The goal doesn’t matter but if you can reduce the amount of cognitive load the user has to accomplish to get to their goal the more successful your app will be. Uber wasn’t the first taxi app but it simplified the parts that required an excess cognitive load on the users part. Payments and booking.

As a developer your responsibility is as much towards a clean UX design as it is towards a clean architecture. You should be aware of the concepts that make it a functional design versus a painful experience and how the choices you make influence that decision. Saying you want a simple app is much easier than implementing it. But much like the computer science theory and libraries you lean on for your development, UX has a number of design rules and libraries that will drastically reduce the effort you need to spend on UX design. That’s what this series of articles hopes to accomplish. Reduce the effort you need to spend on UX and increase the likelihood of users jumping on your app.

Libraries

While I want to focus on core design rules it should go without saying that you should have a good handle on the Google Material Design site.

Google Design
At Google we say, "Focus on the user and all else will follow." With this in mind, we seek to design experiences that…design.google.com

Material Design is a great framework to help you build out the components of your application. Framework is the key concept here. Material Design provides you with a great set of tools but like any other framework you need to know what parts to implement and how. You will still be responsible for the UX decisions on where to place buttons, animations and feedback. No framework will do that for you.

That’s where Design Rules come in.

Design Rules

Design Rules are just like they sound, rules that should be followed to ensure your design is simple and easy to use. However there are quite literally dozens of rules to follow and about twice as many exceptions to each of them in the design theory. That is very different from computer science, where the theory is basically all deterministic and there is very little room for debate. /s

But like computer science, if you strip away the nuances you arrive at a standardized set of principles that accompany all the best designs. Like Uncle Bob’s SOLIDprinciples for software design,Don Norman’s Design of Everyday Things is the handbook for understanding the principles of design. It is a really important read (and will likely change how you look at doors) and the principles apply equally to mobile development as much as industrial products.

Keep in mind design principles are just that, principles. Some components work well within the principles and some violate them. The best applications meet most or all of the principles. Principles don’t tell you what you are doing right, just why you are doing it wrong. Much like your gym coach.

Remember the most important part, if your user can’t complete an action your design is probably at fault

Principle 1. Visibility

Simply speaking, can the user find the action you need them to complete? Each page or screen has a core action that you need the user to accomplish and sometimes more than one. That might be a login, select content or enter information. Is that action clear to the user? Do they know what to do and how to accomplish it? Your design goal should be to ensure the user can complete that action without any unnecessary distraction. Seems intuitive enough but let’s examine where it can go wrong.

Take a simple login page for example;

Don’t let marketing choose your action icons

Don’t let marketing choose your action icons

 

 

Assuming there is content personalized to the user (why else would they want to login?), A user might want to access that content. Email and password is a standard process (more on that later) so they enter their information. This part is visible and clear. Once they have entered the data, they want to execute the action. This is where this example fails. Where do they “Log In”. I’m under the assumption that the action is the top right cleverly hidden with the cute check(logo) icon. Why is that an action? How is the user supposed to know? While it seems like I’m really picky on something that is a minor inconvenience, design flaws like this increase a users cognitive load and chip away at their ability to get things done. Here’s a tip: action buttons should have text, or better text and icons. If they have only icons, they should be very, very clear. In fact unless it’s a cancel or save don’t use icons only.]

 

Instagram example. This company may go places..

Instagram example. This company may go places..

A text button located directly adjacent to where they enter their data eliminates any confusion and makes the action visible to the user. This Instagram example works well. “Log In” is what I’m trying to do and it’s clearly actionable below the username and password. No uncertainty in the action.

[ Here’s a tip: Be aware that when the soft keyboard is extended it may overdraw the action button. You should be cognizant that the screen changes and you need to ensure the log in action is not hidden. ]

Ensuring visibility for a login page is fairly simple design process because the actions the user needs to undertake are limited. You can login, hooray. But for more complicated pages where there are multiple actions, you will need to prioritize which actions are core and which are secondary actions.

To increase your visibility make your core actions visible and hide yoursecondary actions behind menus.

That is the reasoning behind navigation drawers, pull down menus and slide-out content. Hide certain actions from visibility to avoid confusing the user. It’s a straight-forward design principle but often developers put core actions within these hidden menus or worse, don’t hide secondary actions polluting the interface with too many options.

A polluted interface is confusing for the user to navigate and rapidly increases the cognitive load.

 

I can’t even.

I can’t even.

Visible Design

Gold Status for me? I’ve never won anything before!

Gold Status for me? I’ve never won anything before!

 

The Starbucks Android app is a great example of principle of visibility in design. The core action on this page is to be able to pay for a purchase. Clicking either pay on the bottom, or clicking the giant card initiate the payment process. Other features, past transactions are all hidden behind menus or in the navigation drawer. There is little confusion on this page even if it is your first time approaching it…in a Starbucks line…and that lady behind you is huffing…I’m working on it, you’ll get your stupid frappucino lady…hmm that was easy..

Summary Tips

  • Button and actions should have clear text, or clear text and icons. Be careful using only icons as their meaning is not always clear.
  • For text entry, pay special attention that when the keyboard is extended it doesn’t over write the users ability to execute the action
  • Place the action you want the user to accomplish in a clear and expected location.
  • Prioritize the actions on a page. Highlight the core actions and hide secondary actions behind a menu, navigation bar or other slider