“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