10 (hard-learned) lessons when designing for native mobile
Before I started designing for native mobile applications, I was developing responsive web apps. Back then, if we had met at a happy hour event, I would have extolled the virtues of mobile web and progressive apps, predicting the decline of native app installs.
When my at-the-time company pivoted away from their web app to focus exclusively on the native app, I thought, “Well, I have a smartphone, and I spend all day on it, so I know mobile.” Oh, how wrong was I; I had so much to learn.That shift took me down an unexpected path: I fell in love with native apps. Five years later, I am working exclusively on iOS and Android.
If you are new to the mobile space, you may ask what is the difference between mobile web, progressive apps, and native mobile? At a very high level:
- Mobile web applications are responsive web apps accessible only through a smartphone or tablet browser while connected to the internet.
- Progressive web applications are web-based apps that are installable and appear like a native app with a home screen icon. PWAs are delivered through any web standards-compliant browser and have some offline capabilities.
- Native mobile applications are apps created to run on an operating system specific to the hardware it is running on, e.g. iOS on iPhone, or Android on devices made by Google, Samsung, etc. Native apps are intended to work the same offline as they do online, when possible.
Native is not the solution for every product, but when it is the right choice for your application, there are many upsides:
Permanence — Maintaining user context means that when the user leaves, the app is waiting where they left it when they return.
Performance — Access to system resources and a database with background refresh means blazing fast speeds with low or even no internet connectivity for most apps.
Features — Native apps can often take advantage of new operating system features sooner, better, and more efficiently than web-based apps.
Security — Platform security models, app approval processes, and device-level authentication add valuable verification layers web apps can’t promise.
Speed — Ready-made components and software development kits result in a robust app up and running in hours.
Accessibility — The baseline tools available for developers to build accessible apps are unparalleled, using the same technologies that make mobile devices, usable for everyone.
Interested in designing for native apps?
In most ways, designing for native involves the same research and methodologies used to create any type of design. Also, this type of work is constantly changing. Even when I get the hang of it, a new OS release arrives, and the landscape shifts. The upside is that my work never gets boring.
Here are a few of the lessons I have learned designing for iOS and Android apps:
Frameworks are out, platforms are in
The crux of designing for native mobile comes down to platforms vs. frameworks.
A standard definition is you install native apps and access mobile web apps via a browser.
But there is more than that — post-Bootstrap web apps rely on frameworks the user never sees, generating bespoke experiences seen through the browser window.
With native applications, users do not distinguish the apps they install as wholly separate from the operating system of the iOS or Android devices they use. And those users arrive with expectations of how your app will work relative to all the other apps they use on a daily basis.
Know both platforms equally
Designing for both iOS and Android? Dig deep into what is entirely unique and rule-breaking for each system. See how navigation works on both platforms before making global information architecture decisions. Also, become familiar with the similarities across both platforms. They each have distinct design languages - similar to how French and Spanish are Romance languages but share Latin roots; it is much easier to learn the other if you speak one already.
Let’s get technical
The Material Design System for Android and Apple’s Human Interface Guidelines are gold mines of documentation, but they don’t cover everything. Attend the Developer conferences if you can. The upside of remote events is that it is possible to access streaming versions of conference content in a way that was not possible before the pandemic.
Publicly available developer documentation can inform how you design for device-unique features:
- Notifications
- Sharing
- Location services
- Camera
- Gyroscope
- Gestures
Chasing parity can lead to disparity
At Trello, we are lucky to have a dedicated mobile design team, but it is not uncommon for designers to create simultaneously for web and native in some organizations. That work should always be done in parallel to deliver the best cross-platform experiences, but it can be challenging for one designer to do it all at high velocity.
Chasing absolute parity with a web app can leave mobile teams feeling like the caboose on a very long train. Does this sound familiar? Encourage product, design, and engineering stakeholders to collaborate on an engagement model that prioritizes the right mobile feature sets across multi-device experiences. Mobile teams with the agency to negotiate for the best features are more likely to deliver exceptional experiences. Make sure to leave bandwidth for mobile features only available in native apps, leveraging tools like scan to text or the most granular location services options.
Focus on continuity over consistency
Jakob’s Law of the Internet User Experience was written for the web in 2000, “Users spend most of their time on other sites,” but the principle holds for apps today. If you leverage familiarity, users already know how the built-in apps feel, even for first-time users. Predictable native patterns between apps are more important to users than matching the web experience pixel for pixel across devices. The web shouldn’t be like iOS or Android; iOS shouldn’t use Material design, and Android shouldn’t look like iOS.
Everything shouldn’t look generic, but there are better ways to connect your experiences without inducing overhead. A modal dialog with an identical close icon on the web, iOS, and Android detracts value by confusing users across the device ecosystem. Every organization has at least two touch-points between apps, websites, retail locations, out-of-home advertising, social media, and print media (catalogs are back, FYI). Use information architecture, content strategy, storytelling, imagery, color, and iconography to connect those experiences. Engage talented content designers to enable teams to do amazing things that user experience and interfaces simply cannot do alone.
A light touch with the right features will ensure you always get the best updates without bulk rework every time the operating system releases. Reinventing all the components while keeping the app operable on the underlying platform is expensive for design, development, and QA. Heavy customization leads to both tech- and design debt accruing at a higher rate.
Design buildable things
Collaborate with developers early and often. Sometimes a minor design difference can be 5 to 20 hours of work, even though it looks like a simple design change. There are times for pixel-perfect documentation, but most mobile developers would say, “give me sketches today vs. pixel-perfect tomorrow.” Developers know these platforms well and will be the first to tell you when you’re fighting the platform rather than working with it. Engineers are also great partners when it comes to problem-solving.
Documentation, prototypes, project posters, decisions logs et al. are essential for development to begin, but that should never be the first time the developer sees a design. Work with your team on a process that involves engineers early — empower developers to give feedback on your designs and you’ll find your customers get to see your work faster. Be ready to articulate your design decisions when they ask questions, as this process will only make your designs stronger. Open communication and agency make for happier teams.
Leverage accessibility features
Familiarize yourself with the audio, visual, and mobility support features offered by Apple and Google. Start with inclusive design. Collaborate with your developers and QA to make decisions along the way to produce the most lovable products, not just the most usable. These are some baseline accessibility elements to start researching:
- Voice navigation and screenreaders
- Dynamic type vs. accessibility type scaling (they are very different between iOS and Android)
- Screen rotation and adaptation
- Color contrast
Accessibility at Apple | Accessibility on Android
Don’t punt on internationalization
If localization is on the horizon, talk to your product partners early, because doing it later is significantly more complex. A mentor of mine likened working with localization strings to dishes during a dinner party. If you do the washing up as you go, you‘re not left with a room of dirty dishes. If adding new locales is on your product’s roadmap, consider designing flexible components now that can work with Korean’s succinct character set, as well as German compound nouns.
Remember to forget a few things
The context of a touchscreen is different than a desktop/laptop computer. Consider hover, for example, or how you need to hold and interact with a device that has no mouse. Taps, double taps, swipes, and gestures supported by touchscreens offer many interaction options. A keyboard can be attached to a tablet — keep that in mind but think before you use the word “click.” Unless a user has an external accessory paired, they will not be clicking.
Craft matters; start with good design habits
This may be cheating by listing so many tips here under lesson number 10, but these really are valuable to my mobile design process and may help anyone early on in the journey of designing for native.
Libraries: Download or link the appropriate design resources for the platform, start with what exists. Both iOS Human Interface Guidelines and Material Design offer component libraries, design templates, and production templates. Know what exists before deciding to create bespoke components from scratch.
Names: Reference the platform idioms in your component naming for modified elements. Others working on the app will know how that component connects to the platform version.
Typography: Take a look at your size classes. You may have a new device when most folks are rocking something more classic. You might like the smallest text size, but many people use larger default sizes. Design for more than just the best-case scenarios (e.g., design for short/long text strings, all error states, for large and small device sizes, etc). iOS and Android each have their own unique scaling systems; spend time understanding these systems before starting a new project.
Interactions: Interactions and transitions are critical to a polished mobile experience. Communicate flows in an actionable manner for literal-minded developers and QA teams.
Animation: Be aware of system-provided animations; they will feel the most natural on a given platform. Develop a position about how you want to use movement across your apps; used sparingly, this is one more way to add to continuity across the entire device ecosystem while leveling up experience on the whole.
Haptics: Work with your developer to choose how and when to use haptic effects. Platform conventions are a great starting point, but you can customize them depending on what you want to convey.
Dark Mode: Supporting Dark Mode may seem optional, but it’s effectively not. Every system-provided alert and interaction will use the preferred mode and reveal that you aren’t wholly integrated. When working with custom components, use tools like Sketch or Figma plugins to help manage Light / Dark mode in your designs. Features like this create the infinite complexities that make mobile design challenging but deeply satisfying when done well.
Test: Learn to use all the relevant simulators or make sure you have enough test devices. A great design on the Pixel 5 could be very different on a Samsung Galaxy Z Fold3. Get access to certain tablets or foldable devices if your data indicates those are popular with your users.
Versioning: Use versioning in your design workflow — it is not only helpful for you, but it also shows empathy for the developers and QA downstream of you. To quote a developer I know, “No design survives contact with development unchanged.” Slack conversations are great for iterating, but many people didn’t see that chat and will continue to rely on the design docs for implementation or testing.
Team scaling means the near-constant addition of more developers or designers to the project. Don’t make them reverse engineer the decisions; always update documentation as things change and communicate those edits in a trackable manner.
What next?
Ok, so now you get it: I love native design and development. I have immense gratitude for the mobile community who helped educate me with patience and goodwill. I am grateful for their guidance and collaboration. My attempt here was to be accurate and comprehensive, but there are still many more lessons to learn.
Robert Frost spoke about the positive effects of constraints in his statement, “I’d as soon write free verse as play tennis with the net down.” He found more significant challenges and more exciting results when he bound himself to traditional poetic forms. Native design comes with many requirements, but it is a fun puzzle with opportunities for new and better solutions.
By the nature of what we do, the journey is the destination. Stay curious and know that there will always be more to learn when designing next-level app experiences. I can’t wait to see what you create.
