Android wireframes: key aspects you need to know
Android wireframes are a non-negotiable step towards a great product. But what's the right approach? Check out all the key points to keep in mind!
Android. Today, it’s become a regular name among the icons of tech no matter where in the world – much like Google, the all-time tech giant that operates this system. In fact, Android is the most popular mobile operating system by a very large margin, as you can see from the graph below. The market share Android enjoys is simply huge – too big for any designer to pass up.
As most UX designers will tell you with a sigh, great product design is a ladder. You need to establish an idea and build on it as you progress, adding building blocks that will form an experience for the user. And as it so happens when it comes to ladders, jumping over steps can get you to the top faster – or lead to a pretty nasty fall.
One of those steps during the design process is wireframes. They are an essential building block for your android app. They offer the opportunity to look over the sheer basics and ensure everything makes sense. No distractions with colorful branding. No looking for the right images for the home screen.
In your Android wireframe, it’s all about making sure your building block is placed perfectly, and having a solid base before moving on to the next step. So let’s read up on how you can create an Android wireframe that works – it’s time to bust out your favorite wireframing tool!
Wireframing apps is key and the reason why is closely related to the small size of screens across mobile devices. When creating a regular website wireframe, we want to establish the information architecture, navigation and general composition of each screen – and having a smaller space makes navigation design, for example, even more challenging.
The Android operating system comes with a set of guidelines that are offered to us by Google itself (but we will get to those in a minute). For now, let’s briefly go over the classic reasons why making a wireframe before investing in small details can make or break your app.
In an app, information architecture (IA) will have a massive impact on the user’s ability to understand your app and operate it. IA will dictate what is truly important within the app, and how information is presented to users at any point in time – it is crucial in any digital product. So crucial, in fact, that getting it wrong is likely to render your entire creation un-usable. The same can be said for navigation design.
Your information architecture will define what is most important in your app, and your navigation design will create a road for users to find what they need. When designing for the smaller screens of mobile devices, you’ll find making that path requires you to plan every little button carefully.
Side note: You can read our post for more on navigation design and how you can orchestrate an efficient road system your users can follow to any desired destination.
Your Android wireframe is going to put both your navigation and IA to the test. It should make it clear if people could use your product. Or if, for example, navigating to the bottom line of the design is even possible or logical.
Android wireframes aren’t necessarily more difficult by default. But they do come with several factors that one must take into account – more factors than its iOS counterpart.
The biggest factor that separates Android UI design and Apple UI design is perhaps the fact that many different mobile devices rely on Android – from actual Google phones to Samsung and Xiaomi devices. It is true that Android products in different devices can differ a lot in look and feel – especially from one Android version to the other.
This fragmentation can be difficult to cope with. After all, your Android wireframe isn’t concerned with looks and marketing. However, it does touch on what you include in your product, how it works, how it responds to users and how users will feel when navigating around it.
This kind of fragmentation doesn’t exist in other systems, which impose stricter rules on both appearance and behavior, such as iOS.
This fact does make Android wireframing a bit more challenging, but fortunately Google has a secret weapon: Material Design. Created in 2014, Material Design works as a design language for designers and developers who work with Android. It works in a similar way to a design system in the sense that it tries to unify the feel of Android products.
This system is meant to smooth things out between developers and designers, so that everyone can have an easier time designing Android products. For designers, Google even offers some general guidelines when it comes to designing Android UIs.
These range from showing only what users need, when they need it, and having components that look the same and therefore should behave the same way.
You can find these guidelines on their official website, Android Design Principles. It is interesting to note that while Google offers all these guidelines in order to maintain a certain consistency in Android products, they invite designers to use them while still giving free rein to their creativity.
Part of why Material Design is great is because it doesn’t necessarily try to be trendy. Instead, Google wanted a style that could last for many years and stretch across many devices. The folks over at Google were focused on how any interface should act – which means it focuses on classic usability issues, and applies a certain style that can be used for just about any product out there.
Your Android wireframe needs to include the basics, and create an idea of what the finished product will be. Aside from studying up on your information architecture and navigation design skills, here are some key factors to account for.
Yes, studying up on these specs and principles isn’t nearly as much fun as creating something that will stand out from the rest. Something truly unique. But having a unique product comes at a price: consistency.
As many designers know, consistency is a virtue of high value in UX. While there is a lot of fragmentation among different Android products, it remains a fact that Google applies Material Design to all its products. This means that over time, users will become very familiar with Material Design UIs – which is, in itself, an opportunity.
It’s no secret that learning to use a new product can be tough. As new users explore the product and learn what each component does, they need to remember that functionality. Both the learning and the remembering require cognitive effort from the user. The more effort users need to invest, the more users will abandon the product before they get past the initial learning curve.
Even at the wireframe stage, it’s good for you to keep in mind that users will become accustomed to Google’s guidelines and Material Design’s characteristics. Having users that greet your product with pre-existing knowledge of what each component does is a good thing!
Material Design has a surprisingly close connection to metaphysics and how we perceive the world around us. When it comes to your Android wireframe, however, there is a classic element from Material Design that you cannot lose sight of: intentionality.
Consider your navigation and the small screen it will be in. Material design and Android UI are all about the intention behind each component on the screen: they can’t just be there because they look pretty.
They need to do something, to add value to the screen and product as a whole. This is sound advice for any kind of interface design, it’s true. But it does serve a bigger purpose when it comes to Android wireframes.
As previously mentioned, your Android wireframe will be heavily focused on structure, information architecture and navigation. These factors will impact all other aspects of your Android product – which means they need to be tested and validated early on.
Consider your IA, for example. Depending on what your IA looks like, the hierarchy of importance will change. This means your navigation menu will change. Your homescreen is likely to change. All these changes can be quite troublesome and expensive to implement at later stages of the design process.
It is always preferable to identify and make these changes as early as possible!
As previously mentioned, the key difference between designing iOS and Android products could very well be the fragmentation factor. The fact remains that while only Apple makes iOS devices, there is a whole range of brands and companies whose devices operate Android. If that ain’t enough to complicate matters, there is the other fragmentation: the version game.
This marks another key difference between the two biggest operating systems for mobile devices. Apple has the advantage of getting users to update their systems to the latest versions. In fact, about 87% of Apple devices from the past 4 years use iOS 12.
In comparison, the Android version distribution is much more divided. It is estimated that the latest Android version, Pie (version 9), operates on 10.4% of Android devices. This stark difference has a lot to do with Apple’s ability to influence users to update, while various types of devices go about updating their systems in their own way.
So what can we do when trying to design our Android wireframe? The most indicated approach is to select a type of device that is popular among your target audience, and use that when creating the actual Android wireframe. Once you have the main structure down, you can test the wireframe on several different devices and see how it adapts.
Tip: Some market research is needed here, as you want to find out what device your ideal users are more likely to have - and hopefully, even the Android version they use.
There is a recommendable way to account for all this fragmentation when designing. It may be more relevant down the road, when you move on to all the visual elements of the Android wireframe – but worthy of noting regardless. When trying to create all the visuals to complement the Android wireframe: think of it in terms of responsiveness.
Try to see your app wireframe as a regular website as opposed to an Android app. The simple reasoning behind this is that since Android comes in devices that have all sorts of screen sizes, your elements need to adapt – your UI design needs to be flexible.
There are quite a few ways of ensuring your interface adapts to user’s devices, such as avoiding hard coded layout sizes. Instead of establishing unmovable perimeters, aim for wrapping content and extend the content to match the parent view, using “wrap_content” and “match_parent”.
The good news is that Google itself lists out the top tricks you can apply to your Android wireframe to make sure it will look good on all devices, independent of their screen size. You can find this list in the Android Developers page.
With so much information on how one can mitigate the challenges that come with the Android system, it’s only fair that you test the impact each aspect has on the product. Think of the testing as two phases: the first being the classic usability test while the second checks the Android-specific tactics you implemented.
In theory, you want to make sure your information architecture and navigation is well planned so that users can easily learn their way around the design – not to mention, find the information they are looking for.
You want to make sure the structure of the screens lives up to certain usability standards – paying special attention that your design is finger-friendly! You absolutely have to check that there is enough white space between control buttons so that users don’t need to invest too much thought and energy into hitting the right spot to activate the button in question.
On the other hand, you also want to allocate some time and other resources for those Android peculiarities. The key one being that you need several devices at hand, so you can check that the fragmentation of the platform doesn’t impact your design too much.
It’s understandable that purchasing several mobile devices isn’t an option for everyone. That is especially true when it comes to one-person design teams or freelance designers who are just starting out. It’s become standard in these situations to invite people – family, co-workers or friends – to visit the UX lab and volunteer their phones for your Android wireframe testing.
When you do this kind of testing, we recommend you keep track of which devices and Android versions you’ve tested on, so you can have a realistic idea of how complete your testing has been. You want to cover as much ground as you can, making sure that you test your design on the devices that are most used by your target users.
Android wireframes can be a bit more challenging when compared to other simple app wireframes. But it’s so heavily used around the world, that no designer could ever ignore its existence or its dominance over other operating systems in the market.
With the right preparation, however, UX designers everywhere can use Google’s Material Design in combination with their own creativity – and deliver products that users truly use and come to love. The tricky part is accounting for some of the peculiar characteristics of Android, and finding creative ways to get past them.
With this post, however, you’re much more likely to build an Android wireframe that will go on to work well in all Android versions, in screens of all shapes and sizes!