While each of these items is explained in greater detail throughout this document, here is a list of a few simple things you can do to make your design and
development experience for native mobile development better.
▪▪ R
ead the UI guidelines for the platform(s) you are supporting. In particular,
consult Apple’s iOS Human Interface Guidelines1 and the Android Design2
page at Google. Pay particular attention to differences in expected navigation
patterns, as these can significantly change design across platforms, and even
across versions of a platform.
▪▪ L
earn what functionality is available on the platforms, versions, and devices
you want to support. Take advantage of cool technology, but be careful to
ensure that you know what its limits are and can provide fallbacks when
certain items aren’t supported.
▪▪ F
igure out how you’re going to support different screen sizes. An Application
Style Guide is a great way to make this clear, but providing guidance on this
is an absolute necessity.
▪▪ M
ake sure your PSDs are clear and platform-appropriate. Make sure you’re
not giving iOS designs to Android developers, or vice-versa. Show your hit
states, keep related items in folders, and use layer comps wherever possible.
▪▪ T
alk to developers before finalizing your designs. Developers for each platform
can give you feedback that can save you tons of time in implementation,
particularly if you are targeting an unfamiliar operating system or a version
of an operating system still under development.
Designing for native mobile development, particularly when working crossplatform, can be extremely challenging. While some issues present themselves
across all platforms, every mobile platform has different design conventions,
screen size handling, and built-in controls. Attempting to build a single set of
designs that will be easy to implement on every platform is impossible.
We’ve created this document based on our experiences when working with
native mobile designs provided by clients. We want to help you limit the time
spent recreating native controls from a different platform, figuring out color
schemes, and requesting assets that meet the needs of the platform and application. The goal is to give you more time to focus on the really cool stuff.
We want, in short, to provide guidelines that will help you during your design process to create the best experience for your users in every application,
while keeping your costs and timeline for development as reasonable as possible.
1. Apple HIG, including iOS 7:
index.html - Consult your development partner for prerelease documentation for new versions of iOS.
2. Android Design site:
Some elements of mobile design and development apply no matter what the
platform. We’ve broken these out into things to take into consideration during
the initial Design Phase, when you are coming up with the ideas for your User
Interface, and the Asset Delivery Phase, when you are preparing to deliver Photoshop documents to developers.
These tips apply to any mobile development platform, though we will be
primarily contrasting iOS and Android, as they are presently the most popular
platforms at the time of this writing.3
▪▪ H
aving a mobile device gives you both less and more flexibility in terms
of how users interact with your application: The bad news is that your hit
targets will need to be bigger than on a website in order for users to actually
be able to select the items they’re trying to hit. The good news is that swiping
between screens becomes a much more viable option for navigation, and on
some devices multi-touch gestures, accelerometers, gyroscopes compasses,
cameras, GPS integration, and other advanced technologies can help create
very unique experiences. While all devices support tapping and swiping,
ensure that if you want to use any advanced technologies, you are aware
of the limitations of each technology, which devices support each option,
and can provide some sort of fallback for devices which do not support a
particular technology.
▪▪ C
onsider making an Application Style Guide, similar to one you would make
for a website. Answer some of the questions your designers will need to
know as they come up with the designs, and some of the questions your
developers will have as they implement those designs. For example:
▪▪ W
hat are the hexadecimal colors that will be used within the application
for backgrounds, buttons, text, or other repeated elements?
▪▪ Are there standard hit states for buttons?
▪▪ Are there standard sizes for rows in a list of items?
▪▪ H
ow should the app handle text that is longer than the designs permit for should it scroll? Should it truncate? Should it ellipsize?
▪▪ O
n different screen sizes, should elements grow to fit the height of the
screen, or should they stick to the top of the screen, remaining the same
height and/or width?
Even if you’re only starting with one platform, having this style guide built out
can help immensely when transitioning designs to a future platform. Designers
and developers can clearly see what you intended during the original design
phase just by looking at the style guide. Without a style guide, they might need to
3. U
S Smartphone Subscriber Market Share, July 2013.
make assumptions (which introduce additional risk) or seek clarification (which
requires additional time) for designs and implementations for a new platform
based on designs and implementations for the original platform.
▪▪ D
uring your design phase, look at your designs on a device. Export your
PSD or Illustrator document as an image at the size it will appear on a screen
(on multiple screens if you are working with Android), and open it on the
target device. This is a really easy way to tell if elements that look great on
your computer will be too small (or large) for a mobile device. There are a
few tools of varying price and sophistication available to facilitate this:
▪▪ F
or iOS only, there is an app called Briefs4 that allows fast prototyping
and display on an iPhone with a companion app. The iOS companion app
is free, the Mac app that facilitates it is currently $199.
▪▪ F
or iOS and Android, there is an app called Prototyping On Paper5 that
you can use to create quick, tappable prototypes on a device with either
pictures you take within the app or images imported from the Camera Roll.
Pricing is based on how many prototypes you are currently using.
▪▪ F
or a free solution, you can export your comps at the appropriate size to a
Dropbox folder, then using the Dropbox app on the appropriate platform,
open the comp on a device. It won’t be tappable, but it can quickly give
you a good idea of whether your controls are appropriately sized.
▪▪ M
ake sure you are aware of what controls various devices provide you as
part of the operating system and hardware. For example, iOS only provides
the Home button, which developers programmatically have no access to.
Android provides a system back button either through hardware or software,
and Android developers can intercept taps for this button if they wish to
do so. In this example, your designs need to account for a way for users to
navigate backwards through the app in iOS, but you may not necessarily
need to do so on Android. Android also offers developers access to other
hardware buttons not easily accessible in iOS, such as the volume keys.
▪▪ L
earn and understand the design conventions for each platform, and on
Android, what is available in the version you are targeting. Due to wildly
different screen sizes, pixel densities, and aspect ratios, you cannot use iOS
assets for Android or vice versa. There are also dozens of differences in the
user interface elements each system provides developers. It is significantly
less time-consuming for developers to re-skin a system-provided item rather
than try to implement one designed for a different system from scratch.
▪▪ If you have custom animations within your application, please provide
animatics or similar animations in other applications your developers can
use for reference. This will help eliminate guesswork in implementation and
can help your developers call out any potential pitfalls of implementing your
desired custom animations.
4. Briefs App:
5. Prototyping On Paper:
▪▪ S
eek feedback from developers before finalizing your designs. We
can often point out areas where a small amount of additional work
in the design phase can save dozens to hundreds of hours during the
implementation phase, or where you’re unnecessarily departing from an
accepted convention of a platform. This can be especially helpful if the
platform you are designing for is not the platform of the device you use
on a daily basis, or if you are targeting a version of a platform which has
not yet been released to the public.
▪▪ P
articularly if you have not provided a Style Guide or have hit states that fall
outside its bounds, make sure that you use Layer Comps instead of multiple
PSD files to show hit states. This helps ensure during the design process that
hit-state buttons are all the same size as standard buttons, and helps us slice
your elements accurately during development.
▪▪ P
ut related interface elements in folders in your Photoshop document - this
makes them much easier for the devs doing the slicing to find and saves time
during this process.
▪▪ Make sure you are using the correct Color settings for your PSD:
▪▪ Color Mode is set to RGB
▪▪ D
ocument is using Photoshop’s default “North American Web/Internet”
Color Settings
▪▪ RGB Working Space must be “sRGB IEC61966-2.1”.
▪▪ RGB Color Management Policy must be set to Convert to Working RGB.
▪▪ P
SDs without these color settings will result in inaccurate colors when
▪▪ M
ake sure that if you have text with layers of effects on top of them, the
layers are separated out rather than blended together - otherwise we will not
be able to slice them properly. In short, do not use layer effects unless they
can be flattened. Blending-based layer effects are particularly troublesome
to implement, and should generally be avoided.
▪▪ M
ake sure every folder with new versions of PSDs is labeled with the date
delivered. Please let your development team know exactly what has changed
in the PSD when delivering changes, particularly if development has already
commenced. This helps us focus on implementing changes rather than
figuring out what has changed.
▪▪ I f you choose to use any font other than those included with the system (iOS
encourages the use of Dynamic Type, which is optimized around Helvetica
Neue6, while Roboto7 is the only font included on Android as of 4.0 Ice
6. Apple HIG section on Typography:
7. Android Typogrophy including all about Roboto:
Cream Sandwich), make sure your custom fonts are properly licensed for use
in mobile applications and are provided to the developer in the proper format
for each platform. TrueType (.ttf) or OpenType (.otf) files will work for iOS
and Android - consult your development team directly for confirmation for
other platforms.
iOS design has, until recently, been somewhat easier than Android design,
largely due to the dramatically smaller number of devices that need to be supported. Right now, there are only three screen dimension types to support. At
Retina resolution (all devices supported by iOS 6 except the iPad 2, iPad Mini
and the iPhone 3GS), these are iPad 2048x1536, 640x960 iPhone/iPod Touch,
and 640x1136 iPhone/iPod Touch. Final PSD comps should be provided at
these sizes.
The biggest opportunity and danger in iOS design at this moment both lie in
the significant changes in User Interface and Interaction which Apple introduced
with the announcement of iOS 7. Apple has fundamentally rethought much of
the philosophy behind their User Interface and User Experience, leading to a
look and feel that departs dramatically from iOS 6.
There are several things that you can do to help keep implementation of your
iOS designs as smooth as possible:
▪▪ R
ead the Human Interface Guidelines8 for both their overall theory and
for notes on the individual elements you are designing. They can be very
helpful in terms of keeping you away from common pitfalls. Apple has made
significant clarifications and revisions to this document for iOS 7, building
on their decade of mobile User Experience research - take advantage of it
to the fullest extent possible. In addition, if you are transitioning an existing
app to iOS 7, Apple has put together a fairly thorough guide9 for this.
▪▪ W
hen designing, make sure that you facilitate supporting non-retina
devices by placing all your elements on even pixel numbers and making
them even pixel heights and widths. This facilitates resizing these elements
appropriately for non-retina devices - non-retina is exactly half the size of
retina, so all pixel measurements should be divisible by 2. If they are not,
you’ll wind up with assets that cause sub-pixel rendering, which both creates
a surprisingly large performance hit and looks blurry.
▪▪ M
ake sure you’re aware of the standard sizes for iOS UI elements. Going
outside this size range can be done, but it may add a significant amount of
time to development depending on the element. Apple, frustratingly, does not
provide a list of these sizes, but graphic designer Ivo Mynttinen put together
an excellent Cheat Sheet with several of these listed.10
8. Apple Human Interface Guidelines: Consult your development partner for prerelease documentation for new versions of iOS.
9. iOS 7 UI Transition Guide:
10. iOS 7 Design Cheat Sheet:
▪▪ A
pple recommends all hit targets be 44x44 points (a point is 1 pixel in nonretina devices and 2 pixels in each direction in Retina devices). On iOS, it’s
relatively easy to make hit targets larger than the images themselves, but you
may wish to have the full image you’re going to use as a target be that size
so the user can see the full extent of the tappable area.
▪▪ F
or pre-release/newly released versions of iOS, recall that Apple likes to
give the developers the tools to create many of the same interactions that
they use in their stock applications. They also expect developers to follow
many of the same design guidelines they have created for any new version.
Always carefully examine any updates to existing stock applications for
guidance towards new direction for your own applications.
Note that in the future, you should engage your development partners early
whenever any major changes are announced in conjunction with a Non-Disclosure Agreement. This will help you make sure you are aware of both new tools
and tricks Apple has provided to improve your application and any new pitfalls
that might affect your existing UI or functionality adversely.
Android design can be a real challenge. The myriad of screen sizes and the fragmentation both among operating system versions (named for various candies
and desserts) and among manufacturer modifications to each of those versions
can lead to all sorts of weird quirks in design support.
In addition, we’ve found in practice that many designers do not use an Android device as their primary mobile device, so they are generally less familiar
with the conventions of the platform than they are with a platform they interact
with on a daily basis.
Because of those factors, we’ve got a somewhat larger number of suggestions to help you make your design process successful with Android:
▪▪ T
ake a read through the Design Guidelines11 that the Android team has put
together since wholly revamping the User Interface in v4.0 (Ice Cream
Sandwich). This contains a myriad of examples of interface elements and
design patterns that are now commonly available for Android. Three in
particular to pay attention to, and all of which have been back-ported as far
back as v2.3.3 (Gingerbread) are:
▪▪ T
he Action Bar design pattern12. It looks somewhat similar at first glance to
the UINavigationBar in iOS, but is philosophically and programmatically
very different.
▪▪ T
he Navigation Drawer13. Note that Google’s implementation of this is a bit
different than the version seen in many existing iOS andAndroid apps, particularly
the older versions of the Facebook app: Bringing out a navigation drawer
overlays your content rather than pushing your content over to one side.
11.Android Design site:
12. Action Bar Design Pattern:
13. Navigation Drawer design pattern:
▪▪ Navigation patterns, in particular the Up vs. Back pattern as it relates to
the Action Bar. Google’s page on this14 has several excellent examples
with clear diagrams of the differing actions that can happen when the
user presses the system back button vs. pressing the Up button on the
Action Bar.
▪▪ S
upporting sophisticated user interfaces has become significantly easier since
Android v4.0 (aka Ice Cream Sandwich, or ICS). Unfortunately, only a small
subset of the changes have been added to the Support library that allows
some elements to be usable on Android v2.3 (a.k.a Gingerbread), which as of
this writing, was still on 30.7% of currently active Android devices.
You can view the overall Android install base at any time by on the Dashboards
Page at the Android Developer site15, but you should also consider whether your
user base might be one that is more likely to have a newer phone before deciding
to support Gingerbread. Most sophisticated UI elements and animations *can*
be supported on Gingerbread, but it can take anywhere from dozens to thousands
of lines of additional code (and therefore significantly more time) to do so.
The decision to support Gingerbread devices should be akin to deciding to
support a legacy browser: Consider realistically how much of your user base
will be using the older technology, and whether serving that audience until they
upgrade is worth the additional cost of development.
▪▪ D
ecide what screen sizes and pixel densities you wish to primarily target
up front, and provide appropriately sized assets for each. If you are only
targeting phone-sized devices, we have seen solid results with 480x800 hdpi
and/or 720x1280 xhdpi as baseline screen sizes/resolutions. The Android
Cheat Sheet for Graphic Designers16 can help you figure out how to scale
your assets appropriately.
▪▪ N
ote that social sharing in Android is significantly different than in iOS.
For Android, a system called “Intents” allows applications to register for
sharing links and other items, and users can easily use their social network
of choice to share a link. There’s a great post summarizing this at the Google
Developers blog17 - the “Intents over Integration” and “Avoid One-Off
Integrations” sections are a concise summary of why using system-level
sharing rather than individual share buttons is the superior approach. There’s
also an example at the bottom of the post of what sharing from the ActionBar
looks like in modern versions of Android.
▪▪ B
e aware that design changes can take longer to implement on Android than
iOS. Android assets have to be sliced *very* precisely to allow for proper
layout on multiple screen dimensions when views are complex, so having
custom assets finalized at the beginning of development is particularly
desirable for Android.
14. Android Navigation Patterns:
15. Android Dashboards page:
16. Android Cheat Sheet For Graphic Designers:
17. Android Sharing With Intents:
Beyond the links already referenced in the footnotes of this document, Here are
a few additional links we’ve found to be very helpful.
▪▪ M
att Gemmell’s How Designers Can Help Developers and its companion
piece, How Developers Can Help Designers. Primarily targeted at iOS
devs, but helpful guidance for all platforms. Designers Helping Devs:
Devs helping designers:
▪▪ F
lat Design - A blog covering well-done iterations of the popular flat
design for multiple mobile platforms and the web- there’s no direct link,
but click the “App” button to see examples of iOS and Android apps.
▪▪ M
obile Design Tips For Android - Designer favorite Smashing
Magazine’s comprehensive list of tips: http://mobile.smashingmagazine.
▪▪ D
on’ts Of Android Design - A solid reference of pitfalls to avoid,
particularly when transitioning your application from iOS to Android: http://
▪▪ A
ndroid Design Protips - A nice little set of Android Design protips from
Android UI guru Roman Nurik, including a great calculator for converting
Device-Independent Pixels to pixels for design purposes:
▪▪ A
ndroid Design in Action - A YouTube talk show with several high-level
Android designers going through the best practices and common pitfalls of
design for Android.
▪▪ A
ndroid Notification Icon Design Guidelines - For icons that show in the
status bar when the user receives a notification. Note that these are different
based on what operating system your user is running: 2.2 (Froyo) and below,
2.3 (Gingerbread), or 3.0 (Honeycomb) and above.
▪▪ A
ndroid Niceties - A good collection of modern Android user interface
design. Particularly useful for seeing how people are taking advantage of the
Action Bar.
▪▪ T
ips For Android Tabs - Android handles tabbed interfaces very differently
than iOS, and this is a good summary of the Android conventions. http://
▪▪ S
upporting Multiple Screens - The extensive, official, slightly overwhelming
guide to supporting multiple screens (ie, both phones and Tablets) in the
same application.
▪▪ A
ndroid Asset Studio - An open-source method to help you create
appropriately sized assets for various screen sizes and pixel densities. https://
▪▪ A
ction Bar Style Generator - An open-source tool to help quickly and
easily preview potential styles and generate appropriate resource files for
your ActionBars.
▪▪ A
ndroid Holo Colors - An open-source tool to help quickly and easily
generate the appropriate Android native-control-friendly colors and icons
for your application.
▪▪ E
nchant, Simplify, Amaze: Android’s Design Principles - A ~40 minute
talk from the 2013 Google I/O conference about UI principles for Android:
▪▪ A
pp Design Workflow - A great article from the prinicipal designer at
Bjango who detailed his entire workflow very thoroughly: http://bjango.
▪▪ T
eehan + Lax’s GUI PSDs - PSDs representing the GUI of iOS and giving
you an outline for the phone. Note that as of this writing, they have not
updated for iOS 7, but these can give you a running start if you need http://
▪▪ D
esigning for Retina Display - A two part article from Bjango highlighting
some tips and techniques for effective Retina display design. Part one, with
basic tips: Part two, with lots of
good questions and answers:
▪▪ B
eautiful Pixels - A good design blog covering highlights of recent
iOS applications. Also covers the occasional Android app. http://
▪▪ P
ttrns - A site with a collection of various design patterns easily sortable by
type - Activity feeds, calculators, popovers, etc.