Mastering Mobile Design: Navigating Standard Components and Customization
When we talk about reducing costs and speeding up time to launch, standard components can unlock tremendous benefits when building and maintaining features. However, as a designer, it can be difficult to understand what “mobile standards” even are. Taking the time to become more familiar with standard UI options can help us be more efficient and effective as a product team. Likewise, choosing to invest in custom UI only when standards start to break down can help you maintain a high bar for experience quality without inflating costs to build and maintain components that already had a standard solution.
I am frequently asked what the fastest way to learn mobile design is, or if I have a guide to help people get started quickly. There are two pieces of advice I frequently give in response to this question:
The first is to build collaborative partnerships with your development team. Mobile standards and capabilities change frequently and documentation struggles to keep up with that change and complexity. Mobile design is a craft area that is hard to master on your own and I likely would not have continued to specialize in mobile if I didn’t have the support and mentorship of developers. If you invest in those relationships and give yourself time to gain experience, you can become more confident in your mobile knowledge, even if there is always something new to learn.
The second piece of advice is learning how to effectively leverage mobile standards in our products. That doesn’t mean that everything in your app must follow these standards all the time. In fact, I would expect each product to have some amount of custom components within their design system. The trick is embracing constraints of mobile experiences, understanding when to bring in custom components that add value to the user experience, and ensuring custom components can be reused as part of your design system.
The reality is there is no fast or easy way to master mobile standards. In fact, you will keep learning and refining your knowledge throughout your career. This blog isn’t meant to give you all the answers (there aren’t crisp answers to give) but I hope it helps you skip some hard lessons, get context for why developers push back, and help you build better partnerships with developers early on and throughout your process.
🤔 What are “Mobile Standards”?
Calling something the “standard” can make it feel limiting or restrictive. In some ways, using mobile standards do introduce very real constraints into our design process, but they also have notable benefits. We refer to UI components and navigation patterns on iOS or Android that are available by default, or with very little manual effort, as “Standard” for that platform. These are components that are easy for developers to reference and generally come with pre-made capabilities: animation, interactions, colors, padding, accessibility support, dark mode support, and so on.
When you use these components, it saves a lot of time for all members of the team and can have a positive impact on experience quality, too! In a world where we talk about reducing costs and speeding up time to launch, standard components can give your team an advantage when building and maintaining features. Additionally, users will already know how to use standard components which can reduce friction for new and existing users who download your app. Your team’s time matters – don’t waste it on rebuilding functionality or maintaining custom components if you don’t need to.
🌟 The benefits of standard patterns
|
Standard patterns are not the same for iOS and Android
When you look at the examples of standard components above, you may notice a few things…
First, they have a lot of things in common:
- These are components that are standard on both iOS and Android, and as a result, are generally fast and easy to implement in your app.
- They are flexible enough to be customized to match brand colors and unique icons.
- Both iOS and Android have some similar concepts for handling core navigation and displaying content.
But, there are some key differences that make them seem more different than similar:
- Despite having similar functionality and purpose, iOS and Android call these components by different names.
- How content is laid out and the options you have for modifying that layout is different between the platforms.
- There are some behavior differences that are both obvious and less obvious when comparing similar UI.
These are all qualities that make standard components both easy and difficult to work with. On one hand, you have similar functionality and components on both iOS and Android and they can take some customization without needing to be rebuilt. But the differences can make them frustrating to use, especially when those differences are less obvious.
Navigating these differences takes time and experience. Using the tools and documentation provided by Apple and Google for their respective platforms can be a helpful reference but, for many folks, they can be intimidating or flat out not helpful without a strong foundational knowledge of the constraints of each platform.
One strategy many designers start with, including me when I was first starting in mobile, is referencing other apps. This seems like a no-brainer for getting some insight on how other people are solving similar problems to give you a starting point. But, what many folks don’t realize is this can actually be very misleading, especially if you are still learning about standard patterns.
💔 When borrowed designs lead you astray
Using other apps to try and understand the capabilities and standards of mobile was one of my big mistakes when I was just getting started in mobile design. Not that looking at other apps is bad – it can often be helpful spark ideas, inspiration, or context on how to solve a problem. Where folks tend to become frustrated is when they think they are choosing a pattern that will help them solve their problem, only to hear a developer say “we can’t build that”.
What designers often miss – or don’t fully see at first – is many of these apps are using custom UI. Sometimes, this custom UI can even be dressed up to resemble standard components, making it extra challenging to know the difference. The issue often arises from seemingly “simple” design choices that have a huge impact on the time it takes to build a piece of UI, how well it works (or doesn’t work, especially with accessibility options), and how easy it is for people to use.
Looking at navigation
Let’s say you want to get ideas for what you can do with navigation by looking at a few of your favorite apps. Even looking at very basic things, like what people put in their nav header and tab navigation, can give you an inconsistent picture of what is difficult or easy to build and can muddy your understanding of constraints of standard patterns. It is very common for folks to assume that if they see it in the apps they use frequently that it is something they can use too, but it is rarely that simple.
The navigation bars
In the collection of screenshots above, you can see that every app is doing something slightly different with their navigation bars. Some have the page names displayed, some have search bars, some have additional icons. To an untrained eye, you may think that all of these are “standard” navigation bars, but the reality is most of these are custom and made from scratch. Not only can this add days or weeks to development time for something relatively simple, but it can introduce accessibility issues or jank to the user experience. If each screen has a bespoke navigation bar, these problems can become even worse.
In the example above, Spotify has a different navigation bar style for each of their main screens and the scroll behavior is also different for each view. This may be required for some apps with very distinct views that need unique behavior, but it is worth noting that all of these navigation bars are custom and need to be maintained by the development team. This also requires designers to design for all possible stress cases – large and small screens, accessible type scaling, scroll behavior, and more.
With every new version of iOS, there is risk of these critical components breaking or behaving in unexpected ways. This adds to the cost of maintaining these components in the long term.
In contrast, Apple Music uses system standard navigation bars. They opted for the “large header” style, which collapses in a particular way on scroll. By using this standard navigation bar, they are still providing clarity and unique actions on each screen, but the behavior is consistent. This saves the team time building and maintaining these screens over time. In many cases, this component will also be easy to update to the latest capabilities with new OS updates. Choosing to use this component also means designers don’t need to solve for accessibility, scrolling, screen size, or other stress cases; all of that is already baked into the component.
The tab bar
The same is true for the tab bars in these examples. Looking at other apps can give you misinformation about what is standard and what isn’t, even with seemingly subtle design changes.
At first glance, these tab bars don’t look so different, but upon closer inspection, you can see there is a lot of differences that indicate both Amazon and Facebook are using custom components while Apple Music is using the iOS standard component.
A common mistake for designers who are new to mobile is adding more than the maximum 5 sections to the tab navigation bar. Adding that extra option means that the development team needs to make a custom tab bar and can’t use the standard one, even if all other functionality remained the same as the standard tab bar. This will add significant time to a project to build from scratch and, if something were to break or regress with this tab bar, users would not be able to navigate the app.
Some customizations to the tab bar are easy or expected, like changing the tint color of the selected option, adding in custom icons, or changing the name of a section (assuming your name isn’t too long). Because standard components can be customized without being completely custom, sometimes it is hard to identify what changes would require a component to be rebuilt from scratch.
Mistaking patterns for standard components
Another common mistake is understanding what your customization options are for standard components. Much like with navigation, it can be hard to understand what you really get on iOS and Android if you aren’t familiar with their standard components.
Let’s break down this example of Apple Maps and Google Maps.
Standard on one platform but not the other
It is not uncommon to see standard UI from one platform used on another where it is not standard. An example of this is the Floating Action Button (FAB) on iOS. This is a standard Android pattern and has all affordances built into the pattern when used on Android (accessibility, animation, layout, etc). On iOS, to recreate a FAB it isn’t as simple as “just doing what Android does” because we need to reverse engineer all of that behavior. Sometimes, it may not be feasible to replicate the behavior exactly, either.
Use extreme caution when considering patterns from one platform on another. It is a great example of a situation that can sometimes be worth the extra effort to build a custom solution, but often times, there are alternatives that would make more sense for the platform. Experiences between iOS and Android apps do not need to match exactly, especially if changes in the flow or navigation would make more sense for the platform. Take time to carefully consider trade-offs of introducing non-standard UI to a platform that is standard on the other. Often times, that trade-off is not worth it.
In the case of Google Maps on iOS, the FAB is hard to see because of the content density on the screen and, on iOS, the FAB clips into the safe area for the home indicator at the bottom of the screen. The FAB is just one example on this screen, too. All the custom components in this view can have similar bugs or shortcomings. There are now dozens of components that need to be built from scratch and maintained through each OS update to ensure they work correctly.
There is typically no benefit to the user to ship the same experience on both platforms and it results in a much higher cost to build and maintain even seemingly simple UI components. What’s worse is there are options that are standard for iOS that would have achieved similar results that would not require such a large ongoing investment.
Commonly seen, but isn’t actually standard
Chips are an example of a pattern that are frequently used in iOS apps that aren’t actually standard (as of iOS 17). You can even find chips in Apple made iOS apps which can further mislead designers to believe they are a standard pattern. Chips can be a useful addition to some UI, but much like with FABs, the team is responsible for defining the behavior of this component and you don’t get anything by default like you do on Android.
A challenge for users who see non-standard components, like chips on iOS, is they often behave differently depending on the app or instance they are used. In Apple Maps, for example, you see the chips have an outlined style and very round corners. The chips scroll horizontally and multiple can be selected at once. But in Apple Fitness the chips are square with a fill instead of an outline and they navigate you to a different view when tapped. This means that users cannot rely on the behavior of this component from app to app which doesn’t help set basic expectations for use or behavior when they see these custom chips in iOS apps.
Even though Google Maps isn’t an Apple app, seeing chips used in 3rd party apps can further imply that these are a standard pattern. In this example chips not only look different but have multiple styles and different behavior in the same app. In Android, this actually makes some sense as there are different types of chips that do different things, but on iOS there is not that foundation. This can make interactions confusing for users who are not used to these kinds of patterns.
A benefit of standard UI is its consistent behavior from app to app and situation to situation. Having different types of chips, for example, isn’t necessarily a problem, but the fact that there is not a consistent experience for chips on iOS makes it harder for users to know what will happen when they interact with them. When we introduce new custom patterns into our apps, even if they are based on standard patterns from one of the platforms, we need to ensure that we are at least consistent with how that UI is used within our own apps. Consider how to communicate variations in components that may look the same but behave differently.
Unexpected limitations
When bottom sheets were first introduced on Apple Maps, they were not actually available as a standard component to everyone. While designers eagerly tried to bring bottom sheets into their feature work, teams quickly learned that they got nothing by default and needed to re-design and re-build a very complex piece of UI. Everything from working on large screens, animation, scrolling behavior, and navigation needed to be built from scratch making this seemingly simple design solution very complex to execute on.
Even when the bottom sheet became available to everyone to use a year or two later, it had some hidden complexity that was not clear when interacting with this component on Apple Maps. Unlike the bottom sheets on Android, iOS has very specific positioning for this view. Even a seemingly simple change, like changing the height of the sheet, meant that you could not use the standard bottom sheet component and were stuck building it from scratch yet again.
With SwiftUI, there is more flexibility with bottom sheets, but it is a great example of how just seeing a piece of UI, even if it is in a system app, can very easily mislead you to thinking a certain piece of UI or seemingly small design adjustment is easy to do.
😕 This seems complicated…
It can be difficult to assess UI to this level, especially if you are a designer used to working on web products, but it is a critical skill to have to ensure we are making the right kinds of trade-offs for experience quality, maintainability, and effort. Looking at other apps as a guide for what is and isn’t possible was one of my big mistakes when I was first getting started with mobile design, but I also want to stress that it doesn’t mean there aren’t good references out there.
I still look at other apps to get an idea of flow and assess how other people may be solving similar problems, but I never take that UI as an actual solution. I use it as a basis to start looking at what I can use from my standard set of UI for iOS and Android, and our own design system of custom components, and work with my developers to ideate on how we can best solve a given interaction or UI problem. Sometimes investing in custom UI makes sense, but being able to know when something is “custom” or “standard” is a critical skill in mobile design.
🗺️ So where do you start?
Understanding what is and isn’t standard on iOS and Android can be challenging as you get started with mobile design. Starting from appropriate standards for both iOS and Android and only modifying when something starts to break down is usually the best way to find areas where you may need to customize. But getting the foundation you need to start working that way doesn’t happen overnight. Building this muscle requires us to get feedback, find mentors, and gain experience.
Even if there are not shortcuts, there are some fundamentals that can be helpful to start from to keep you on the right path:
Create partnerships with developers
One of the most important things you can do is collaborate with your development team. Ideally this means exploring interaction ideas together, but at a minimum, proactively sharing your explorations to get feedback and validate your assumptions. If you can work with the folks actually implementing design work, that is preferred! Working only with a lead developer can sometimes feel like a game of telephone with the actual team. If you have the opportunity to build relationships and get involved with the group of developers taking on the work, take it! But every team will have a different structure and working style, and that is ok.
The more experience you get in mobile design, the more often you will be able to correctly assume the ease of customizing certain components or identifying when something is or isn’t standard. However, maintaining strong partnerships with developers is still critical to ensure you are making assumptions that are correct for your specific codebase and to stay connected to the constantly changing capabilities and constraints for mobile.
If working more collaboratively is new to you, these resources may help you explore different approaches for bringing your team into your design process early and often:
Design for both iOS and Android
iOS and Android have different system standards, different constraints, different programming languages, and users have different expectations based on the device they use. Shipping an iOS experience on Android or vice versa not only makes a lot more work for you and your team, it can be frustrating for users.
Although some thinking can be shared between platforms, it is worth the time to start with the respective standards for iOS and Android and make any adjustments to the experience that makes sense. Users are not going to expect literally identical UI between iOS and Android (or mobile apps and the web for that matter). What they expect is continuity for their data and the experience, not parity. Users (and product teams) benefit from UI and interactions that make sense for the platform they are on.
It is commonly recommended to reference materials put out by Apple and Google to become more familiar with their standards and how they change year over year. This is great advice, but I have found that this documentation can be, at best, intimidating for designers newer to mobile and, at worst, be really hard to consume at all. Getting familiar with this documentation and how to use it is important, but another way you can build a working knowledge of the standards for iOS and Android is to regularly use both devices. Not only should you be testing and using your own app on both, but spending time doing your daily tasks with both can give you a lot of context for the similarities and differences between iOS and Android and help you build more empathy with your user’s workflows.
Creating documentation for both iOS and Android workflows is important for your own understanding and ensuring your documentation is usable for your developers. Be sure to use correct terminology and names for colors, typography, icons, and UI to ensure everyone is on the same page. Make sure your designs follow guidelines unique to the system they are meant to represent (like size ratios, padding, and system features). Although this process does take time, it will save a lot of effort for the team overall, especially as you leverage standard components for each platform instead of rebuilding experiences from scratch.
Think in systems
In addition to starting with and using system standard components in your app, when you do need to introduce custom functionality, be sure you are designing components that can be reused in your app and are not just for one specific screen. This can be a challenge, especially if your product is worked on by many teams.
Many standard components offer customization options without needing to be rebuilt. This is where it can be helpful to work out solutions directly with developers instead of making UI you validate with them at the end of your design process. Keeping an open mind to how you solve a problem with UI can keep the door open for finding ways to achieve the functionality you need with standard components.
Try to only build custom functionality around the things that make your app unique. Make sure that you cover all stress cases (accessibility, large screens, dark mode, motion, etc) in your designs and that you have good documentation to capture all this behavior for other designers and teams to reference. Think about how these components may be reused throughout your app and ensure you are designing for those use cases to the best of your ability.
Most of the time, you can easily use standard components while still providing an on-brand experience for your users that feels delightful to use. The trick is learning how you can effectively customize standard components and build reusable custom components that benefit your whole app, not just a single screen.
Just because you can, doesn’t mean you should
Even if you have a large development team behind your product, or work on a design system team making reusable components, it doesn’t mean that making custom patterns to replace standard UI is any better of an idea. There are real implications to maintainability, usability, and accessibility when making completely custom components. There will be times when custom makes sense – because you need to do something that is unique to your product that there just isn’t a system component available for – and that is fine!
But invest your time in those hero moments, don’t reinvent the wheel on small things that have very low impact on the experience but very high costs to build, maintain, or use. These types of custom components can cause user frustrations when it doesn’t work as expected, if they don’t support accessibility options, or they are buggy with the latest update of the OS. Use your developer power to invest in what is most important or impactful as a custom experience. Don’t doom your team to an endless sea of tech debt, usability, maintainability, and performance issues, especially if a standard solution would have given the same amount of experience quality.
“Use your developer power to invest in what is most important or impactful as a custom experience”
🌱 Growing your mobile craft takes time
Mobile design is complex and ever changing space. As a designer, it can be very frustrating to bring all of your experience into a mobile project only to be told what you are doing is ‘wrong’ or goes against standard patterns. This can make relationships between designers and developers confrontational instead of collaborative and frustrate people across the team. Understanding mobile standards and how to use them is key to unlocking collaboration and the longevity of our teams and products.
Understanding standard components allows designers to speak the same language as developers and can help you be more effective together as a team. Creating space to have developers co-own the design process can help you grow as a mobile designer and improve your products. Likewise, being more involved in the development process – not writing code, but frequently testing builds and working through problems together – can further break down walls and improve communication. Collaboration is something we talk about frequently as designers, but putting it into practice in our day to day work can have a huge impact.
Reducing costs, speeding up time to launch, and delivering user impact are metrics nearly all app teams are held accountable to. Custom UI is not something we need to avoid, but it is something we should see as an investment. We should make that investment when it is the most impactful for users and our product experience. Spending our valuable time remaking functionality that we could have implemented at a significantly reduced cost by using standard components rarely makes sense. Consider the impact we could make if we, instead, started from standard patterns first and only invested that time on the hero features or experiences that would deliver the highest impact by being custom.
No matter where you are on your mobile design journey, it is worth assessing how we can leverage standard patterns to their maximum benefit in the app. There may not be shortcuts to growing this muscle, but the journey can make all the difference to your own craft as a designer, and to your product team.