How To Be A Good Android Designer
Designing an app for Android is not easy — at least not as easy as it is for iOS, especially when Android is the secondary platform.
On Android, you will probably have more than 4 different devices at hand to test; you will need to provide “9-patches” to engineers, while most of the time even they themselves don’t know what that is. (It is actually a type of resizable asset with marks on the edges to indicate how it should scale.)
Even leaving the resolutions and the technical difficulties aside, Android is full of surprises. For example, sometimes the color blue looks green, other times the layout is off on non-typical devices — there were 18,796 distinct Android devices in the world back in August 2014, and there are even more now.
Even worse, it will become 10 times harder if you are working on a cross-platform team and there’s another platform being designed for first (e.g. iOS). Here, I want to share with you why this happens, but don’t worry: I’ll also share some tips for dealing with these issues!
Part 1
Why is it so hard?
If you are an Android-focused designer working in a medium-sized team (20–30 people), you might collaborate with product manager, engineers, and user researchers. There might also be at least one other designer working on iOS or other platforms as well.
When collaborating in such a multidisciplinary team, just as people learn the true meaning of life as they grow, you will gradually realize that:
Design is an art of compromise.
It can be better explained in this diagram:
Overall, the designing process is like a journey of exploration. As you start, you may be fascinated by exploring one direction (perhaps an especially creative one), but soon you will find that every journey has its boundaries. The boundaries for design are defined by several major factors: product goals, technology, creativity, and user experience. (And these factors could vary from different projects.)
Balancing these tensions is an art. For example, engineering resources are never enough, and the product goals should always be kept in mind. A unique design can be enticing for designers, but everyday users may just not appreciate it in the same way.
After months of exploration, if you are lucky enough, you will finally reach a point where everything seems to be taken good care of. Kudos! A good design is born. A perfectly balanced point is found!
However, for an Android designers things can be even more complicated, especially when another platform (e.g. iOS) is the focus of the team. On the one hand, frequently iOS can receive more engineering resources and have faster development cycles. On the other hand, since Google keeps optimizing Android experience, there tends to be more and more similarities and dependencies between Android and iOS. (If you design for Windows Phone, probably you don’t need to worry about these at all.)
So, what will happen to your design boundaries?
In this case, the design space will be even more limited.
Why? When you start off to design a feature for Android, there are times that the team may already have a workable solution on iOS because they have more resources. If it happens to be on the perfectly balanced point on their side, the team would naturally hesitate to introduce a different design on the Android side.
Therefore, the blue area in the graph below constitutes the real boundaries you will have.
Not too much left, right?
The graph above is already a lucky situation for you. If you are not lucky enough…
You will have to say good bye to the perfectly balanced point on Android.
If you think nothing could be more heart-breaking — just wait! Nowadays more and more teams embrace iterative development methodologies like scrum. You might need to keep changing your design to catch up with the iterations:
These are all the real world problems that an Android designer may run into for once or many times during a project.
Part 2
How to be a good Android designer
Here I want to share some tips to deal with these issues. They can be not only applied to Android design, but also how to be a good cross-platform and especially secondary platform designer in general.
Handy Tip 1
Never focus only on your platform
As mentioned above, design is an art of compromise. To be deft at it, one needs to gather as much information as possible so that you can understand the conditions and limitations of all the involved platforms.
As discussed before, the design boundaries on Android might be largely influenced by iOS. This means that while iOS designer might only need to consider iOS, Android designers should never focus only on Android — a thorough understanding of both platforms will make your work much easier.
Unless you understand the iOS platform, you won’t be able to know the true rationale behind the design. For example, if you see a menu in a certain place, you might not know if it is driven by user experience concerns, or simply following iOS tradition.
These learnings will lay the foundations for understanding your design boundaries.
Sometimes, you can even get some “aha!” moments from understanding other platforms. For example, Android system has much more freedom than iOS in terms of technical limitations. If you take advantage of these “privileges”, you can make crazy things happen! (One example is Chat Heads for Facebook Messenger by Joey Flynn.)
Handy Tip 2
Contribute your opinion from early enough
When designing the same feature on Android, you can usually have a chance to rethink the problem. Sometimes, when you think about a problem thoroughly enough, you might have some exciting new ideas come up; it could even be a huge improvement to the current design on other OSes.
But then, hold on… you will find after a design decision has been made on iOS, you can’t just think about whether your idea is better. There are lots of other factors to be considered: project progress, engineering effort, etc. It’s possible the feature is already being implemented on iOS, or has already been built.
It’s going to be really, really hard to change a decision that has been made on another platform.
If possible, start thinking about the problem and actively join the discussion ASAP, as soon as a problems are emerging, as soon as ideas are being initiated. Do so even if it can dramatically increase your current workload. You will eventually find it all worth it.
After all, cross-platform design is a process of intense collaborative efforts.
Handy Tip 3
Communicate, communicate, and communicate actively
Try to make yourself heard when a decision is being made. If you don’t, nobody will seriously care about Android — it is not their main job and not their fault.
When this happens, active communication will be the key.
Even after a decision has been made, it is still important to keep the communications going on. Remember this graph?
A small, detailed change can cost a lot of communication effort in a cross-platform team. Therefore, it is crucial to keep track of what’s going on the other platform.
In other words, don’t be afraid of being a walking “question mark”.
If one day you wake up to find that an engineer has changed a feature on Android to sync up with iOS without letting you know — calm down, even if it means a redesign of many other dependent interfaces. Try to understand the reasons behind the decision and figure out how to get involved earlier in the future. Sometimes changes made on Android have caused similar frustrations for the iOS team. It is natural for this to happen; staying aligned is hard and to err is human.
Mutual care and support is the spirit of cross-platform collaboration.
Handy Tip 4
Keep parity
Every once in a while you will be obsessed about an Android specific solution, and such a perfectly balanced point can be indeed found after days of thinking — user-friendly design, identical functionality to iOS, and very much “Android-ish”. However, think twice before you leap: is it really worth it at the cost of harming the unified experience across all platforms?
If you are not one hundred percent sure about the move, then probably you need to compromise — kill the idea now.
Some people may get confused. Then what am I here for? Isn’t the team hiring me for an Android specific design?
While it seems so, it doesn’t mean you cannot make it look like the iOS one. In fact, keeping a uniform interface makes the app recognizable across different platforms. More importantly, since future changes are likely to occur, it is easier to keep parity when they do take place.
For example, if the iOS team decides to add a rock-star feature on a specific part of the app, but on Android that area is already full and nowhere else is suitable, should you redesign the whole interface? If so, how about other dependent screens?
A mess like this is never pleasant, right? Trust me, keeping unity across platforms can save time and resources across the entire team, especially if you’re developing very quickly.
However, there can be times when a certain design makes it worth it to break parity, then simply follow your intuition.
At the end
If I had read an article like this before I started working on Android, I would have saved a lot of time and energy. This serves as the key motivation of me to write this article — I hope my experiences can help more people get prepared for working on cross-platform design.
In order to become a good Android designer, you not only need to approach Android design in its own way, but also to know how to think deeply about multiple platforms, communicate actively, and lots of empathy for both users and members of your team.
This is a challenging but fruitful journey.
Appendix
Here are some Android design tools that I frequently use：
- 9-patch making
- Export assets from Sketch (if you want pixel-perfect assets, you still need to manually tweak them)
Thanks to all the people on my team. As a novice Android designer, I can recall the times when I have messed things up, and your patience and tolerance in answering my questions, resolving my doubts, and helping me grow up. Special thanks to all Android engineers, it is you guys that bring my design into life.
Thanks to all my friends who read this article and shared their advice before it got published.
