I'm designing a mobile app.

The developer is using a framework which uses native building blocks for iOS and Android. Customising means extra dev work.

Developer says: "Why waste time when guidelines exist that have already been researched? Let's use native building blocks."

Example: tabs at the bottom for iOS, top navigation for Android with next button and hamburger menu.

She has convinced me, but, at the same time I realise that I don't know enough to be satisfied that she's right. I see millions of apps with a vast variety of combinations out there. Some of these have excellent UX, despite not strictly adhering to guidelines.

I am torn between the thought that she's using UX as a motivation when what she wants is an easier life developing, but on the other side I see her point.

Should I stick to the design guidelines?

  • Hard doesn't always equate to valuable. Just because it's easier doesn't mean you should find her motivations suspect. Commented Sep 16, 2016 at 12:13

4 Answers 4


Stick to the design guidelines because you might break the consistency with other apps.

Design guidelines are your best guess and are based on years of research. They're also developed so all apps resemble each other so when the user opens up a new app she knows how to use it because the navigation, icons, behavior are similar to previously used apps.

Said otherwise users don't have to build a mental model each time they open up a new app when they can use their already created ones from the other apps.

If you are going to do something "custom" please do some research before that (interviews or user tests).


It really depends on the functionality and nature of your application. Bare in mind that App Store might not approve your app if it doesn't meet the guidelines.

Bare in mind user is more attracted well designed rather than well developed (ex. IPhone)


Guidelines are guidelines.

If you follow the guidelines, you are leveraging the platform's consistency. This reduces the cognitive load for your users because they already have an innate understanding of how to use your app, and because your app is more likely to feel like it fits along with everything else on their phone.

If you choose not to follow the guidelines, be able to clearly articulate why you're not following them. "I don't want to" is probably not a good reason. Keep your user's experience first and foremost in your mind. After all, the guidelines are for general app development, and they don't necessarily make sense for every application or every workflow. Any app should be user tested; this is more important the further that you get from the guidelines. If users aren't able to find an important control because you've chosen not to use the system controls, you might need to re-think some aspects of your design. If you have a well-articulated case for why the guidelines don't fit, and if you have data from user tests to back up breaking the guidelines, your boss and clients are going to be a lot more comfortable.

Likewise, given constrained development resources, consider what are the biggest improvements in your user experience. Is it going to be in a highly-customized user interface, or is it going to be in spending that time on improving the user experience of a feature? Consider the big picture. Having a beautiful UI but a horrible UX is rarely a good decision.


Navigation is one thing, OS guidelines are another. In the field of UX we need to balance a whole slew of requirements, while maintaining user advocacy. While I'm most curious as to the scope of the project, the only way I have ever been able to sell in a feature, or departure from the norm, is through added value. Added value is something that can only be gathered through research: competitive analysis, user interviews, best practices, nngroup studies, etc...

So in the sense of added value, it is entirely up to you to analyze 1) the primary features, 2) user expectations, and 3) primary scenarios (user flows, etc). And through your exploration, only you can crunch the situation and find the best path forward-- balancing requirements and scope. If you are essentially asking the Dev team to do extra work, be ready to back it up with an objective analysis!

And finally the quandary of navigation: to follow guidelines, "standards" or reinvent the wheel. Again, this goes back to use cases/scenarios and definitely IA! This was a common problem for me, when teams continually want to discuss navigation amidst the Discovery/Research phase of the project. Don't put the cart before the horse, navigation should be an informed design decision.

I recommend telling your Dev partner that you'll need more time to hammer out the IA and user flows. And! Hey! If you go with a unique navigation like a hamburger, or Snapchat, all of your designs can conform to a Single set of design principles! So in this sense, you only need to document/spec small variances between iOS/Android, whereas if you follow their respective "standards" you may have a lot more design work to do...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.