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


Design principles from Don Norman’s Design of Everyday Things provide a fantastic overview of the fundamental principles in industrial design. Those same principles apply to any type of design and are especially relevant in digital and mobile design. But like many academic principles, implementing those principles in a practical sense is often difficult. What I hope to learn with these articles is some practical ways of implementing that within Android. Feel free to correct me when I’m wrong, I’m learning this too.

While the first two parts of this series worked on some fairly high level design concepts that are usually part of the design stage. This part will focus on those principles that are more the responsibility of the developer. Yes, even those developers that have the luxury of working with a professional UX team have to be able to assume some of the responsibility for the user experience.

Feedback and Consistency are best described as the “little things” that can be handled by developers. Both are simple concepts but require a little rigour in your development practice to ensure that they are followed. I use a couple of internal rules to ensure that they are followed but the principles are simple enough that with a little foresight and developer can ensure they are implemented with great success.


Probably the easiest and most intuitive concept to understand is the idea that each action should provide appropriate feedback such that the user understands that something is happening or about to happen. A state change happens when the screen updates with new information, typically in response to a user action. Letting a user know about state changes is critically important to your usability. Imagine how frustrating a toaster would be if it didn’t indicate when the toast was done. “Burnt Toast” is probably the same way your users would feel if you lacked appropriate feedback within your app.

Feedback that is poorly implemented is almost always responsible for very frustrated users. Did I click that button, I thought I did? Maybe I didn’t? Should I do it again? Will it break this time? Implementing smart feedback has to be done in a conscientious and purposeful way to make sure the user doesn’t get confused and frustrated by the device.

So how do you know what is appropriate feedback? Primarily it means communicating to the user every time you make a change to the state or perform any action they need to be aware of. In Android the easiest way to think of a state change is anytime you update a View. This means after the initial render you must think about feedback in terms of any further changes you make to the view.

If you are making a change to a View within your application you should consider what feedback needs to be communicated to the user. Rarely is the answer “Nothing”

For instance clicking a Button should change the colour, elevation or even provide haptic feedback. Otherwise the user has no way of knowing the button press even worked. That change should be immediate and visible to the user. That’s the kind of feedback the user is expecting. It gives them the sense of completing an action. It is also one of the easiest to implement. You can theme all your buttons with the following code;

<style name="MyApp" parent="Theme.AppCompat.Light.NoActionBar">
<item name="android:buttonStyle">@style/MyButtonStyle</item>
<style name="MyButtonStyle" parent="Widget.AppCompat.Button">
 <item name="android:background">@drawable/button</item>
<item name="android:foreground">?attr/selectableItemBackground</item>

That’s it. Apply a Drawable State Resource as a background and an animation on the foreground. All your buttons will be theme’d the same way and act the same. Consistent feedback to the user. Without it, users will hammer away on the buttons (you are running a debounce right?) thinking the action is delayed. Honestly, it’s a pretty simple addition. Try it with and without the button feedback and you’ll notice the difference immediately.

Simple animations and transitions work great for immediate feedback and should be used often. But what happens if your state/View change takes a little longer. Your app might do some processing, retrieve data from the network or transitions to a new page. For those actions that are delayed what type of feedback should you be sending to the user? Should you be showing a dialog or progress bar, or maybe nothing at all?

Jakob Nielsen, another pioneer in UX design implemented a set of rules for response time for web users based on digital interface rules.( Those rules haven’t changed since 1968 [Card, 1968] ). I’ll repeat them here (abbreviated) since they provide a great guideline for different types of actions to display.

  • 0.1 second is about the limit for having the user feel that the system isreacting instantaneously
  • 1.0 seconds is about the limit for the user’s flow of thought to stay uninterrupted, even though the user will notice the delay.
  • 10 seconds is about the limit for keeping the user’s attention focused on the dialogue.

Using those response times as guidelines we can come up with some rules around what types of feedback you should be looking at based on how long the view takes to update after the user performing an action. Like when a user clicks login…

At 0.1 seconds this is the level that is at the limits of the users ability to see the change. If you have a state or view update that happens in less than 0.1 seconds you might want to consider slowing it down with an animation. For instance if you are updating a ListView from a local database, new items can be added very quickly and the user might not see that change. Having a ListView change unexpectedly is jarring to the user. Using anRecyclerView.ItemAnimator is a simple way to implement proper feedback about the state change to the user. Animate the components in when the update time is less than 0.1 seconds.

Up to 1.0 seconds is about the limit that users will wait for feedback on an action without getting annoyed. Greater than this delay you will need to let them know that something is happening. Convention tells us that we need to add a progress bar. My preference is to put the progress bar directly on the content that will be changing (i.e. progress button) but wherever you are putting it should be consistent with what the user expects. (Spoiler! Consistency below)

Up to 10 seconds is about the limit the user will wait without any other feedback. What this means is that even with a progress bar showing an action delay you will have to provide some sort of other feedback showing the progress. At 10 seconds a progress bar will need to display a progress percentage and not just be indeterminate.

Proper feedback within an app is a straight forward and fairly routine to implement. TLDR; for Developers…

for(View view: updatedViews){
if ( delayInSeconds <= 0.1 ){
} else if ( delayInSeconds > 1 && delayInSeconds < 10){
} else{


The second principle in this section is another simple concept although I’m consistently (ha!) surprised at how often it is violated, especially in terms of making an app “unique” and “different”. Consistency refers to the concept that similar actions use similar components. Drawer Button opens a Drawer Menu, Action Bar menu key opens a quick menu, Back button actually goes back. Consistency is important because it allows the user to understand what an action does even if they haven’t seen it before.

For Android, consistency applies in two core ways;

First, is internal consistency. That applies within your own application. You should make sure that actions that the user engages with are consistent. If you have a page where you add content by clicking a floating action button, you should try to maintain that language. Adding any other content should use a floating action button also. That consistency provides a natural mapping for the user and they become proficient in using your application.


Skype, strangely consistent UI

Skype, strangely consistent UI

Skype implements “Add Contact” and “Add Call” in the same fashion on the image above. Users have an easier time understanding the language of the app and can navigate the two screens with relative ease.

Implementing an internally consistent interface is a matter of being lazy. Find simple components for your user interact with and reuse them across your app. As a double bonus, reusing the same UI components for similar actions makes your code easier to manage.

The second, and more problematic consistency issue relates to consistency within the Android ecosystem. I understand app developers want to make a stamp with their new, innovative and different app but changing the interface patterns the user is accustomed to creates a frustrating experience for them.

Jakobs Law, users will spend most of their time with other apps.

On average users engage with roughly 26 or 27 apps per month. That means your app occupies a small portion of their day and attention. If you want to gain the benefits of consistency you have to consider how the other apps implement similar functions. You can see where this is going, Material Design standard.

The Google Design team has created a great product with Material Design. It is built to apply a consistent interface across multiple applications. Whether you agree with the design choices or not, the Material design specification is what the user expects and if you want to be consistent you should implement the interface with religious fervor.

Design | Android Developers
Create beautiful experiences in your

What I’ve seen more than once, is Android developers will port an iOS or Web application over to Android without modifying the UI in any sense. iOS and Web UIs are functional and very good for the the ecosystem they were developed in but Android users need the applications to be consistent on theirplatform and the design language from iOS and Web are not compatible with it.

Tip. Don’t directly port the UI from iOS or Web apps. Their design language is inconsistent with the Android platform and even the best implementation will cause confusion with users


  1. Follow the 0.1–1–10 rule with View updates. Each view that is updated should follow the same algorithm.
  2. Use Material Design. Users will naturally understand your application and it will be consistent with the other apps they use
  3. Don’t use the UI from Web or iOS interfaces. The users of those platforms have different expectations for similar actions.


Miller, R. B. (1968). Response time in man-computer conversational transactions. Proc. AFIPS Fall Joint Computer Conference Vol. 33, 267–277.