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.

Feedback

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;

values/theme.xml <style name="MyApp" parent="Theme.AppCompat.Light.NoActionBar">

<item name="android:buttonStyle">@style/MyButtonStyle</item>

</style> <style name="MyButtonStyle" parent="Widget.AppCompat.Button">

<item name="android:background">@drawable/button</item>

<item name="android:foreground">

?attr/selectableItemBackground</item>

</style>

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.