Designing an Android App
A consolidated guideline by a Dummy
The Startup Buddy is expanding to Indonesia and if you didn’t know, Indonesia is a classic case of a country that exhibits technology leapfrogging. This means that unlike countries like America and even Singapore, where the general population makes a gradual progression from a desktop then to mobile phones, Indonesia has leapt straight to mobile phone usage. In fact, research shows 46.7% of Indonesians solely use smartphones and 50.7% of them use both smartphones and desktops. It was thus exceedingly clear to us that we had to develop The Startup Buddy app. All in about 2 months (totally possible…) considering we were going to unveil the new app in TechInAsia Jakarta.
Another interesting statistic that we had to take into consideration is that around 80% of Indonesians use an Android phone. Now, I won’t lie that this disappointed both me and our developer, Denny. Denny is an iOS developer and I have personally never owned an Android phone in my life (at least not when we could get apps on it). I have always been an Apple girl, and am completely inept at using anything other than Apple products now. But it was clear to our whole team that this wasn’t the time to play to our strengths but instead develop something that the majority of the Indonesian population can use on a daily basis.
Hopefully, my experience in designing an Android app can help some of you in designing your own especially as I will be trying to consolidate the various things that I found useful while designing the app. Also, Denny has written a pretty cool guide on how to develop an Android app where he praises me extensively! Anyone who needs to develop an Android App and has no clue on how to get started should definitely take a look at it, plus you all can know how wonderful I am!
Step 1: Reading
Material Design guidelines are literally going to be your best friend (sometimes worst enemy) while you are designing your Android App. You can find it here and I would suggest you take half a day or so to skim through everything so that you can get a better understanding of how an Android app should look. This was a really important step for me especially to get familiar with the various elements in an Android app that look and react quite differently from an iOS one. What really helps (unless you have a photographic memory) is to draw out the particular component with its name right next to it. This will save you a lot of time when you are actually designing and you can drill down to the exact component instead of scrolling through a bunch to find the one you want specs for!
Step 2: Deciding
The Startup Buddy web app has a whole bunch of features like tracking your progress, finding mentors and resources and even a community where you can chat with other founders. With our time crunch and manpower shortage (startup problems), we knew we could potentially only develop 3 or 4 features. And thus began an extensive discussion about what to add in The Startup Buddy Android app version 1.
How we went through this process of deciding started out based on gut feelings. But what we should have done is look at the analytics on our page and choose the features that had the highest usage. While this didn’t strike us at that point in time, we got lucky in the sense that we ended up choosing the features that our users on the web platform use the most and what we felt would benefit users in Indonesia the most.
I have purposely left out the specific features that we ended up choosing because I want it to be a surprise… But what I can say is that you are going to love how easy it is to connect with industry experts through the app to get help on your startup!
Step 3: Drawing
Get a piece of paper and fold it into four. Instead of UI designers who know how to use Sketch/Adobe Photoshop, be a kid and draw out how your screens should look. I like to label it, with descriptions on the back so that you don’t get confused. You can also use this paper and pen method to quickly decide on the look and flow of your app taking into consideration what your team members say. Trust me, this extra step could save you a lot of time since changing things on a computer can be a lot more time-consuming than just using your eraser and pencil.
Step 4: Density
Ok, you are probably thinking why I suddenly started talking about physics, but bear with me. This will make you a whole lot more efficient. So there are many, many different Android phones, with many, many screen sizes. And, trust me, designing for each one will probably take a year and will drive you mad.
But material designs to the rescue. They came up with something called the Density-independent pixels* or dp for short. This basically means that you only have to design for one screen size and the elements will look like it takes up the same amount of space on all screen sizes. Amazing right?!
*Density-independent pixels, written as dp or dpi, are flexible units that scale to have uniform dimensions on any screen. Material UIs use density-independent pixels to display elements consistently on screens with different densities.
The set of android screen densities and their conversions to pixels are as follows:
Step 5: Sizes
Now all of that looked scary, but what you should take away from this is that you only have to design for one screen density, which is MDPI. So make a custom artboard with the dimensions 360 x 480 px and design as you normally would with pixels, since 1 px = 1 dp in an MDPI screen!
Step 6: Designing
Remember that piece of paper I told you to scribble on with components and their names in Step 1? Well, that’s going to be really helpful here. Keep in mind your house style guide and start designing your screens. When it comes to components like buttons, menus, cards, and a lot more, material guidelines is going to be your best friend again. They have specified the specs for each component towards the end of the page. This is the one for buttons and this makes your life really easy as you just have to follow these guidelines to the T and you are good to go.
Step 7: Check if your UI makes sense for users
Following the material guidelines has its benefits, but sometimes it can make things less friendly for your users. For example, our missions page has 4 tabs for users to get content, jot down their progress, find their mentors and get resources. In the app, we only have 2 tabs (won’t reveal the two just yet). Being the rule (in this case guidelines) abiding person I am, I decided a floating action button would be apt, where users can toggle between the two screens by clicking on this button. But, my developer pointed out that it doesn’t make any sense to do it that way and we should do the traditional tabs. Now, the tabs in material guidelines recommended we have at least 3 tabs for people to choose from and thus began an hour-long discussion about what we should choose. And then it hit me, material guidelines are just that, guidelines. It might not always suit the function you are building and that’s why it’s important to always consider the user first and to make sure that your app is functional to them and not simply a guideline abiding platform.
Step 8: Exporting
Now you have your design, but you have to hand it off to your developer, which includes all the assets. This was by far the most tedious part of this whole process, and the only comfort that I can give you is that after this it’s your developer’s problem.
Your components are all designed for MDPI but you need to have components for all the other screen densities as well. What I did was create folders on my desktop named MDPI, HDPI, XHDPI, XXHDPI, XXXHDPI. After that, I exported the first component with the size 1x to the MDPI folder, size 1.5x for HDPI, size 2x for XHDPI, size 3x for XXHDPI and 4x for XXXHDPI. Rinse and repeat for the other components as well. It sounds a lot simpler than it is, unfortunately.
Pro tips so that your developer doesn’t murder you in this process:
- Make sure the names of each component are the same for each screen density. For example, ‘bitmap’ should be ‘bitmap’ in MDPI, HDPI, XHDPI, XXHDPI and, XXXHDPI and not ‘bitmap_HDPI’.
- Ensure that your component names don’t have spaces in them. For example, components should be named as ‘bitmap_1’ instead of ‘bitmap 1’.
- Make sure that there are no similar names to components so that your developer can identify it easily.
Phew, that was a long article. But, I hope it helps anyone that needs to design an Android App! Do stay tuned for our app launch, then you can see what I have been working on for the last month :) And as always, if any of you have further questions, you can always find me on The Startup Buddy as a mentor in the mission Product!
The Startup Buddy is SEA’s founder friendly Startup accelerator. We provide step-by-step guidance through specially designed missions, mentors from around the world and curated content to help you with your Startup journey! Find out more at The Startup Buddy!
