“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.

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 SOLID principles 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

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..

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 your secondary 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.

Visible Design

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