The success of any app cannot be easily predicted. It is a mixture of various factors. The way it looks, feels, and the moment it appears on the market all have an impact on the end result. One way to make the whole process easier is to design your MVP in base of material design. In this article I’ll have a go at explaining what material design is and why it’s better than other custom solutions. Read on if you fancy exploring the arguments in favour of such an approach.
Application design is something we all understand the value of. It is responsible for the users’ first impressions and can determine whether or not a particular application will be chosen over the other apps on the market. It is understandable that everyone wants to make it as unique as possible but we have to remember that everything comes at a price.
Material Design, on the other hand, is a visual concept introduced by Google a few years ago. It defines the way that apps should look and behave. The company aimed to deliver a clean, modern, unified solution for Android application design. Not only does it say how to style an app - the whole system has been designed that way since Android 5. It is very distinct from iOS and its “Human Guidelines”. It does not support some of the features that iOS does and vice versa.
Often we encourage our clients to revise their designs. This may be for many different reasons, but we usually refer to material guidelines. As a company we always pay attention to each and every aspect of the products we create and our advice is only geared towards making it more successful. This is a recurring problem whenever we talk to clients so we have prepared a list of things to keep in mind when designing an Android application.
Every business relies on estimations. We try to more or less predict how long something might take, how well it will sell, what the whole company will look like next year. No matter the scale, estimations are crucial. This principle is just as applicable to software development. The first thing every project needs is to be estimated. Clients want to know if they have sufficient funds and time to make it happen. Of course, the more information they provide the better the estimation will be but sometimes even a well-documented project can be hard to estimate.
We understand that sometimes it is impossible to change the initial idea. It might be the main “killer feature”, the core of the app. It is important to decide what is, and what is not, an element of this core to avoid wasting time on things that don’t matter all that much. They might appear simple but sometimes they violate how the whole system works and prove impossible to code. This is not always the case but the truth is that unusual features bring rare problems in their wake that have not necessarily been tackled before.
It is not only the developers’ time that is saved. Graphic designers are also involved in the process. Many things that cannot be coded have to be supplied in a different way. They have to be prepared and exported by the designers, often in many different resolutions, just because the system does not support it. So the guidelines make life easier for both your development and the design teams.
Designs that don’t follow the guidelines are more likely to have unusual features. In such a case, the developers have to take a stab in the dark. They need to guess how the feature behaves, how the system handles it. Many questions arise, each of them increasing uncertainty. For every feature that does follow the guidelines, all the developers have to do is look at the average time it took them in their previous projects. No surprises there.
Design is not everything. Of course, it is the first thing a user sees up on the screen when they launch an app but it is not the only thing that matters. After seeing a beautiful logo and the main menu the user starts using the app. And yet again, something can go wrong here.
As we pointed out earlier, the whole Android system is optimised for material design. Features that are copied from iPhones or just completely new may require developers to pull some tricks out of the bag. Just because something looks the way it was supposed to, it doesn’t necessarily mean that it behaves as it should. It doesn’t automatically result in top performance. Users are more likely to use applications that are bug free and have a high frame rate than those with cool designs that are unusable. Because every app in the end has to work. Simple as that.
User experience. This is a term everyone keeps in mind but at the same time they may well have slightly different concepts of what is best for the users. “Better is the enemy of good” and this quote is pertinent here. Sometimes all the effort made to enhance user experience in an app ends up making it less intuitive.
This doesn’t mean to imply that the idea was wrong, but the final product should compromise between what we want users to experience and what they are used to. Imagine your everyday software with toolbars in completely different places than usual. Replace the Windows Start menu with MacOS Dock or vice versa. It will feel weird even though many people will swear that one is better than the other.
This point is similar to the previous one but it occurs at a different moment along the product development timeline. Every time a new developer joins a project they need to familiarize themselves with the code. It can happen before or after the initial release, or there might be a periodical team rotation or an emergency when some other team fails.
After the release, it is all about keeping the product up to date, fixing bugs, resolving issues. It is a long term process that usually involves new developers every couple of months. If the project is standardized, new developers can easily step in with minimum setup. If it’s not, it might take them weeks to fully understand the system and each custom feature only extends this period. If there is an emergency and the developer joins the project before the release - this is a critical situation. Let’s throw terms like budget and deadline into the mix and we can sense some panic in the air. To reduce the risk, make the task as easy for the new developer as possible and use solutions that he is more likely to be familiar with.
By keeping most of the experience similar to other apps they use on a daily basis, we can achieve a very impressive user engagement right from the word go. They know where all the standard stuff is, which leaves them free to concentrate on the killer features we have in store for them.