Designing for iOS and Android: Translating the Language of Design
3 principles of designing across platforms
Lucidchart for iOS launched about two years ago with great success. It was featured across 38 categories in the App store in 149 countries. Building upon the value we’ve provided our iOS users, we recently decided to expand our mobile offering and build a full Lucidchart app for Android.
A lot of things have changed over the last two years since the initial release of our iOS app. We understand our users better, we have a better sense of the cost of designing and building mobile apps, and we’ve had to consider new opportunities and constraints like designing for international markets. Moving forward, we realized that designing an app for Android needed to be more than just a “screen swap” with iOS. We needed an evolutionary path to another mobile platform that provided value to potential users.
If you are new to mobile app design or are making a platform transition like us, here are 3 principles that can save you design time, engineering time, and a whole lotta headache when designing your product for multiple platforms. These tips have helped us ensure that the Lucidchart mobile experience seamlessly fits our customers pre-defined expectations of system interaction patterns.
1. Document the existing app
Some designers, when given the opportunity to translate an app to a new platform, are tempted to start from the ground up — without documenting the existing app. Before starting a new platform project, take the time for some thorough reconnaissance to understand the depth of the previously architected experience. Breaking down the app and documenting each possible screen and workflow reveals technical truths, backend limitations, and edge cases that often get overlooked. This process helps produce a better “translation” from one platform to another.
If you are already familiar with your existing app, resist the temptation to quickly tap through screens and functionality for a few minutes; tapping through each screen on your device can only provide a linear understanding of one particular user flow at a time.
At Lucid Software we use Sketch to document our designs, because it allows us to break down large workflows, keep track of design iterations, and deliver final specifications. In Sketch, I use pages to break down workflows into smaller product sections and I use artboards to define specific states of the workflow (shown below).
For example, you’ll see that the “Sign in flow” (above) is made up of a launch screen, log in, and sign up workflows. I like using the first artboard of each row as a title page. Having the workflow titles baked into my mocks helps me stay organized and on task. Plus, when the time comes to present my work, I immediately have a presentation ready to export.
Although documenting every screen of the existing iOS app seemed tedious, it deepened my understanding of our mobile experience. After mapping out each section of the app, I was better able to contribute and provide valuable insight to my PM and engineering team — especially since some of us weren’t involved in the first iterations of our app.
Hint: If you don’t have the original design in Sketch, take screenshots of your existing app to document the current user workflows.
We also use Sketch to leverage the power of symbols — lowering the cost of changing/updating components. This takes a bit of planning and forethought. As you design, take the time to build symbols rather than copying and pasting content from each screen. This will help your mocks be consistent, organized, and iterative.
When I first started this project, we didn’t have a Sketch file that contained all of the screens and symbols from the iOS app. Thus I didn’t have a Sketch file to modify for our Android app. Instead of starting a Sketch file for the Android design, I first built the Sketch file to reflect our current iOS app making sure I used symbols where appropriate.
When mocks are organized and built with symbols, you can easily update icons and text position across entire files. Because I built the iOS Sketch file using symbols, I was able to update a symbol to match Material Design and it updated across all of my designs. For instance, I modified the “Navigation/Header” symbol (shown above) and 38 different screens across 7 pages were automatically updated. Boom — done.
2. Leverage common system patterns
Some UX designers feel the need to design every interaction pattern of their app from scratch. I think they are afraid that if they use a system component it might not have their user-centered thinking behind it, or using a system component will lack personal flair.
The truth is, custom components cost a lot. They are expensive in terms of code, design, and usability. Think of each custom component as a new language. As the designer, you create this new language (mocks), developers have to write the dictionaries & rules of the language (code), and your users have to interact with and understand this new language (app patterns).
Not everything is worth learning. It’s so arrogant of our industry to think that every customer wants to learn every novel UI pattern we create.
Both Xcode and Android Studio already have their own “standard language” of system components that help developers build their products. Using standard components will reduce engineering overhead — both in terms of initial investment and long term maintenance.
Mobile users have already learned the interaction language of their device, be it iOS or Android. They use cell phones and tablets daily. They understand these platforms so well that they can pick up on them quickly and even teach others how to use them. Have you ever seen how quickly a child can learn to use a touch device?
When designing a mobile app, ask yourself: Will a custom interaction language communicate more clearly than the interaction language my users are already familiar with? Is creating a custom design pattern worth putting extra work on my team and cognitive load on my users? Taking advantage of standard components reduces engineering investment, decreases design debt, and meets users expectations. Win, win, win.
System patterns in our app
When we designed the editor of our new iOS diagramming app we focused on using standard iOS components in order to lower development and maintenance costs. Some patterns between operating systems are very similar and can be interchanged. For example, the segmented control on iOS (shown below: left) can be directly translated into Material Design tabs (shown below: right).
Other interaction patterns aren’t as easily swappable between platforms. The iOS world tends to be very icon based, with layers of information. Material Design is more descriptive and text based, exposing more options at once. When designing our Android app, instead of hiding options under icons, we presented them in a scrollable list (shown above), similar to what is found in the Google Slides App.
Another difference between platforms is how menus and functionality is contextualized. The FAB, (floating action button, shown below: right) is unique to Material Design and represents the primary action for any given screen/view.
Notice how the FAB is a stronger call to action than the iOS plus button in the bottom toolbar. Once the user interacts with the FAB, the primary action maintains it’s presence and still stays in focus, revealing secondary menu options. However, on iOS you’ll notice the primary action gives way to the secondary menu, without remaining an object of attention.
During pattern translation, you should appreciate the strengths of each design language and pay attention to the subtle experiential flavors of each one.
Custom components in our iOS app
One of the few areas we decided to develop a custom design pattern was in our document management system. Two years ago, when we were making decisions for our iOS app, we felt like document management was an important experience of our tool. We felt that using iOS system patterns would be clunky and too different than our desktop experience and we wanted something more dynamic.
The interaction patterns below were not provided by Apple, had to be custom coded, and required an extra two weeks of engineering time to build. Also, our engineering team took on additional maintenance costs for this pattern each time a new iOS version was released — costing us even more time and resources.
Although this custom component provides a great experience, we determined that this pattern didn’t have the right “bang-to-buck ratio” for the added investment, and it was cut during our translation from iOS to Android.
Over the past two years, we have had a change of philosophy with engineering investment: we prefer to focus on developing features and improvements inside the editor rather than dealing wth the perpetual remediation costs of custom development. Following a common pattern in our document list allowed us to focus on our core experience (inside the editor) and ship the Android app sooner, while providing a familiar pattern for Android users.
3. Pushing your brand
With all this talk of using standard components and icons, you may be asking yourself: “Where do we draw the line with cookie cutter apps and a product that reflects our brand and value?”
Lest you think you are being forced into building bland iOS and Material Design apps, let me assure you that you can find a balance between reuse, efficiency, and branding personality.
Here’s how we decided to maintain branding value in our mobile apps:
a. Color — Although we used standard components from iOS and Material Design, we changed the colors of the components to match our branding. Because of device size and the backlit technology of phones, it’s likely you’ll have to adjust branding or UI colors for mobile devices. For example, our dark blue colors appear too light on mobile devices, so we adjusted them to provide the needed contrast.
b. Investment in our own iconography — The iOS Human Interface Guidelines only provides a handful of system icons useful for common system actions. Our product has concepts unique to diagramming, which required us to create many icons from scratch. The Lucidchart mobile icons are drafty, technical, and sophisticated, not playful or chunky.
In contrast to iOS, the Material Design library is chock full of hundreds of beautifully designed icons. In fact, they have an entire section dedicated to “editor” icons (shown below). You’ll notice the icons provided by Material Design are heavier and more playful (less technical) than the brand language we have established.
As we translated to Material we reused the custom icons we had designed for iOS in as many places as we could. There are a few places where we had to change our icons into something that an Android user would understand. For example, we needed to design two separate icons for the share action, because the icon paradigms are so different between iOS and Android. Again, we want to speak to the user in the language they already understand. The share icons (shown below) are lightweight and drafty versions of the system icons that users already recognize and understand.
Delivering icons for Android: I deliver SVG icons for android development. This makes changing color easier for design and engineering. When delivering SVGs, you’ll need to build them correctly. Older versions of Android devices can’t render icons with empty space inside (e.g. the page icons shown above). You’ll have to change them to non-zero fill types. This article explains how to do it: Exporting SVGs in Sketch for Android.
Delivering icons for iOS: I deliver 1x pdfs to our engineers. Xcode can interpret, change color, and resize as necessary.
c. Typography — Both operating systems provide varying font faces with differing characteristics. When choosing typography, don’t go crazy. Remember that the purpose of text in an app is to inform and direct. Be sure that the character of your font doesn’t compete with the usability of your app.
A year ago when we were designing our iOS app, we decided to use Avenir as our primary typeface. Avenir is clean and lightweight, it fits well with our technical and drafty icons, and it was already available as a standard (free) font on iOS. It didn’t cost us anything to use it.
As we were designing our Android app, we realized that Avenir is not a standard (free) font on Android devices. The only way to get the same font on both platforms was to pay for an Avenir font license on Android.
Today there are so many good free fonts available, you can suitably replace a paid font with a similar free font. We decided to use Muli in our Android designs because it has similar characteristics as Avenir without the hefty pricetag. If it’s important for you to maintain that level of consistency, you may have to pay for the same fonts across multiple platforms.
Our Android and iOS apps share an identical mobile canvas (this is the core user experience where diagrams are created), the same Lucid mobile color palette, the same iconography, and similar typography. Keeping true to the language metaphor, these details are the accent to an already common language. When you are designing for each platform, you should speak the language your users understand (iOS or Material) but don’t be afraid to add your own accent through colors, iconography, and typography.
Making the jump
Hopefully, you’ll appreciate the advice and judgement that has helped Lucid make a more seamless transition to a new mobile platform. I don’t think designers have to abandon all design judgement and only design using the interaction patterns provided by iOS or Android, but I do think, as designers, we should consider the power and value of adopting existing components and platform patterns.
Staying organized, leveraging system components, and delivering consistent branding will give you extra time each week to focus on what’s most important — your users. Maybe you can squeeze in a few more customer interviews or additional user research! Spend less time pushing pixels and more time understanding your customers and what they value most. That’s how you and your product development team will become really good at delivering value!
For great examples of iOS to Android pattern translation check out how Ionic translates design patterns across multiple platforms.
(This is a post from the design team at Lucid Software. We make collaborative diagramming and layout tools: Lucidchart and Lucidpress.)
