By John Houghton on January 9, 2014
We previously discussed about how to design an iPhone app UI, and now we’ll discuss how to design an Android app. The good news with Android is that Google doesn’t need to approve your app. The bad news is that you have enough rope to hang yourself. A poorly-designed app is enough to cast a death sentence upon the whole project. When you start to get traction the first set of negative reviews will do you in. Design is the most visible element of your project, so it behooves you to invest heavily here and do it right.
1. Read Android’s Design Guidelines. You can find Android’s design guides online if you query: Android Design. You’ll find that Google has put a lot of thought and research into user interface and user experience design. The way they frame things is different from Apple’s approach, as are their theories and conventions. I’ve mentioned this before and need to say it here again, you should not bring Apple’s design conventions into an Android app (and vice versa). Android users are used to Android conventions, and bringing in different conventions will make the app hard to use. The analogy is putting a Mac user in front of a Windows machine. They just aren’t going to know how to use it. I should mention here that quite a few things are different from an iOS project, most notably the programming language, which is Java instead of Objective-C.
It’s not enough to skim Android’s design guidelines. You need to look at what applies to your app and follow the conventions. For example, a notable difference is that the tab bars tend to be on top with Android, while these should be on the bottom with iOS.
2. Look at Google’s Apps. Make sure you have a phone with apps designed by Google (the carriers can change the main apps and design their own), take a close look at how the screens are laid out, and how they flow from screen to screen. The big mistake I see first-time app designers make is that they make a wireframe (a diagram that shows screens and the flow from screen to screen) many times more complicated than it needs to be. Invariably, the app turns out poorly, and even other team members have trouble using it (that should be your first sign of trouble). If it’s your first app design, it’s good to take an existing Android app, designed by Google (such as Calendar or similar) and sketch a wireframe for it. You can do this on butcher paper, and it’s a great way to see how simple an app can be while still providing good functionality.
3. Look at your Competition. There’s no filter on Google Play for getting an app approved, and designers don’t tend to follow Google’s recommendations as closely, so don’t put too much stock into what’s already there. However, it’s important to know what others are doing. As it is with an app on the Apple store, just because it’s there, doesn’t mean it’s correct and you should do something similar.
4. Sketch your Wireframe. Just like the exercise in step #2 where you sketched a wireframe for an existing app, now you need to create the wireframe for the app you want to build. One mistake I see first time designers make is that they are not familiar with the prebuilt widgets, such as the date picker, and instead they diagram their own inventions. You should know that while it is possible for a developer to build a new date picker just as you specified, and novice developers go right down that path; it’s nevertheless better, cheaper, and more forward compatible if you use the prebuilt widgets that Google supplies. Thankfully, Google provides all of these widgets and icons in PDF format to speed up your design process. Query: Android Design Template, in the search engine and the first link should be the Designer’s download page at developer.android.com.
5. Consider your Target Devices. Ok, here is the headache with Android. Google runs their development program like a democracy (device builders can do what they like), which might be the right thing in the long run (let the market decide, right?), but has led to chaos when it comes to device characteristics and capabilities. There are thousands of devices out there, and the headache for you and all developers is in trying to cover them all from a design and testing perspective. Here is the trick: don’t try to cover all the devices, just focus on the major ones. Your task is to figure out which are the devices with the most market share and design for those, while trying to cover as many of the others as resources allow. Appbrain.com is a good resource for device marketshare information. Trying to predict which device is going to be big is hard/impossible, so it’s better to stick with the top 5 devices, and hopefully they have similar screen sizes and pixel densities. See this article on the Android developer site for details on out how to support multiple screens. Unfortunately, it’s a lot of work to design, develop and test for all these screens and to do it right you’ll need to get the hardware (don’t rely on a simulator).
From all of this you want to set your work area dimensions so you can start designing. Android allows what are called NinePatch images which allow flexibility to accommodate different screens, but you don’t want to stretch too much. I frequently use three different sizes, 480×800 (which covers a lot of phones from 2011 and 2012), 720×1280 (which covers phones similar to the Galaxy S3) and 1920×1080 (which covers phones similar to the Galaxy S4). Right now it’s rather heterogeneous with Samsung dominating the top spots, so it’s up to you to decide who your target audience is and what device they’re likely to have.
6. Lay Out Your Design. This is best done in Photoshop, and you should start with one screen size to set your work area, say 1920×1080. If you have special icons, these are best designed in Illustrator and then imported into Photoshop. Make sure you use the wonderful Stencil sheets provided by Google to lay out your widgets. When your design is done you can shrink the interface (if you know how to do this gracefully in Photoshop without causing pixelation) to get it to 720×1280. For the 480×800 interface the aspect ratio is different, therefore you can’t simply shrink the interface to get to this size, you need to redo this layout.
7. Finalize Your Design. Good developers want your graphics finished before they start coding, so you need to slice the Photoshop document to get all of your graphics. They should all be in PNG format and not JPG (JPG adds compression to the image). If you’re giving the developer all three resolutions, make sure the files are all clearly marked and organized. Also, do a sanity check to make sure everything fits together and that there are no overlaps or gaps in real estate. This will cost extra money to fix and it creates needless problems.
8. User Interface Testing. If you want to save money, choose one device and don’t develop for the other two screen sizes while you are iterating design and user interface testing. The idea is to put the app in front of a new user and watch closely to see how they use it. You want to provide the best user experience possible (UX). You might spot issues that warrant redesign.
So those are the basics! We’ve assumed that a creative brief was already done, as well as exercises to segment and understand your users. Really, there could be many more steps, but these are the basics for getting you a design in about a week’s time. If you’re at a big company with multiple stakeholders, this design can take many times longer. Please share if you like this article!