In this guide I’ll describe the deliverables you’ll be expected to produce, outline the constraints of the medium and introduce fundamental iOS and UI design concepts.
Knowing your medium and its quirks is an important part of being a good designer. I’m sure you’ve been witness to large print-outs with horrible pixelation artefacts – the result of misunderstanding print media. Similarly misunderstanding the role of pixels on screen can result in blurry, squished, or pixellated designs.
iOS devices come in two main form factors, the iPhone and the iPad […] . While this seems quite simple on the surface the iPhone 5, the iPad mini and Retina screens have added a bit of complexity. The most important difference is between the devices that have Retina screens and those that don’t. A Retina screen shows an incredible level of detail which makes good design look even better. Unfortunately it also makes certain mistakes much more obvious.
Most recent iPhones and iPads are fitted with Retina screens, a high resolution screen intended to make pixels invisible. The Retina resolution of a device is an exact doubling of the previous resolution. A single pixel in a non-retina iOS device is taken up by four pixels in the retina version. This makes text crisper and allows for significantly more subtle detail. There are many complexities to designing for retina screens, so this is an important area to read up on.
A pixel (px) is the smallest unit of measurement on a screen. It represents a minuscule physical square that is part of the display. If you look very closely at a screen, you’ll be able to see them (and the gaps between).
It is not possible to have a line that is smaller than “1px” in width. For example a 0.4px line can’t possibly exist, instead graphics software interprets this as a fainter 1px line. This result is often considered ugly.
We use points (pt) as a resolution independent measure. A point can be represented by many pixels, normally one or two in a single dimension (high or wide). For example all iPads have the same resolution in points and all iPhones have the same width in points.
Over time you’ll learn to think in points rather than pixels. But it’s important to remember that each point can be made of many pixels and so there is room for extra detail.
Now have a look at the various resolution measurements below. You’ll see how the resolution difference between the iPhone 3GS and the iPhone 4 significantly changes detail, but doesn’t change the way we refer to element sizing. You’ll find this very useful when considering the way that physical measurements (like the size of a finger) interact with on-screen elements (like a button).
|Device||Retina?||Point Resolution (pt)||Pixel Resolution (px)|
|iPhone < 3GS||320 x 480||320 x 480|
|iPhone 4, 4S||eye||320 x 480||640 x 960|
|iPhone 5||eye||320 x 568||640 x 1136|
|iPad 1, 2 & Mini||768 x 1024||768 x 1024|
|iPad 3, 4||eye||768 x 1024||1536 x 2048|
The various resolutions of iOS devices in Portrait orientation […]
- Designing for Retina by Marc Edwards of Bjango
- Retina Display Design Techniques and Workflow on Smashing Magazine
- iOS Design Cheat Sheet by Ivo Mynttinen
To develop the high level flow of your app many designers choose to create a storyboard. The first version of this storyboard is often on paper, simply linking boxes with words together. After you’ve drawn your screenflow out on paper you’ll find it much easier to imagine travelling through the interface. Often through visualisation inconsistencies and complexities will become immediately obvious. Many times you’ll have moments where you think “I want to do x” on a screen and suddenly realise there’s no obvious place to do it.
An example storyboard.
You can use your inital rough storyboards as a framework to organise and design a more fully fledged concept. A sketched out, more detailed storyboard is quite easy for others to interpret, so you can spend time having people “try” out your design to see if they understand the direction it’s going. Testing your design is a really great way to see what is and what isn’t working.
- Printable Templates at Smashing Magazine
- From Wayfinding to Interaction Design by Matt Cooper-Wright
Laying it Out
When you begin the layout process for each screen it’s often best to forget about “decoration”. Instead focus on the core structure of the UI. To put it simply, where things will be on the screen. This is the step between your initial sketches and the final product. Here you’ll do a lower fidelity version, one which you won’t invest too much detail in so that you can reorganise without much time wasted.
Hierarchy performs two important tasks: it provides a way for users to reason about navigation within your app and allows them to determine what effects a button will create. At the top level an app is normally divided into a few main pieces of functionality, normally achieved through a tab bar at the bottom of the screen. Many apps have switched this for a side opening “hamburger” menu or a landing “grid” menu. Navigation within a top level section is assisted by the navigation bar, where you’ll also find actions that are significant for the screen you’re on.
It’s often useful to quickly compose app mockups using existing wireframing tools and templates. An existing iOS template gives you the advantage of the native user interface feel without much time investment on detail. However using these templates can confuse clients as they’ll consider this as “done”. To indicate that something is a wireframe or a mockup some designers prefer to use a template which has a “drawn” feel. The downside to using generic UI Templates is that you often limit yourself to the UI elements available, rather than inventing new and perhaps much better suited interfaces.
Choosing the size and placement of your touch targets (buttons, sliders, switches etc) is often a balance between subtlety and usability. Because of the innaccuracies of fingers touch points within your app should be around finger size, which Apple designates as 44pt x 44pt. If you’d like your touch targets to appear small, you can often designate a larger touch area than the visual appearance.
You’ve probably experienced accidental taps when browsing the internet, something that rarely happens with a mouse. To stop this sort of behaviour avoid putting small touch targets close together, especially if they perform very different actions (for example “flag as inappropriate” sitting next to “like”). In a similar vein, placing related actions very far apart can be as annoying. As before, balance is important.
- The Apple HIG on Platform Characteristics
- The Teehan + Lax iPhone and iPad templates
- Bryan Clark’s Sketch Template
- Meng To’s Wireframing Guide + Resources
Universal & Flexible Design
When you’re designing for iOS you’re not just designing for a single screen size. Even if your app won’t be universal you still need to consider orientation differences and vertical flexibility. When deciding on how your layouts should flex and what should show, think about a user’s intentions on that particular device and in that particular orientation.
Portrait vs Landscape
When approaching the portrait and landscape layout problem many designers choose to forego one and stick to a single screen size. While this is indeed a good way to cut down on work, it doesn’t take into account different users requirements. Perhaps you lock your app down to just portrait, but a user comes along that finds it difficult to type in portrait mode. Or you lock it into just landscape and then people try to use it with only a single hand. Orientation flexibility is a core feature of the platform and people expect it to work.
iPad vs iPhone
iPads and iPhones are very different devices. Depending on the sort of app you are designing users may expect a universal solution, only iPad, only iPhone or even two seperate apps. While many of the constraints are similar the larger iPad screen allows for more creative activites and longer periods of use. Whereas the iPhone portability means people want to see information at a glance and achieve tasks quickly, often while moving.
iPhone 5 vs Classic iPhone
The difference in height between the classic iPhones and the iPhone 5 means you’ll need to allow for vertical flexibility in height. While this has always been somewhat true (due to the in-call status bar), it is now a very obvious issue. This doesn’t mean you need a design for each of Portrait and Landscape on iPhone 5 and classic iPhones, instead designate which parts of your design should stretch and which parts are fixed (in both width and height).
iPad vs iPad Mini
In most respects you can consider an iPad mini to be an iPad 2. The most important difference is that the iPad mini has a physically smaller screen, but the same resolution. This means that your hit targets will be physically smaller (and there’s nothing you can do about it). So when doing your iPad design be especially wary of small hit targets. Users get particularly frustrated when they think they’ve tapped something, but instead get the button next to it.
You may have noticed a common theme, in many cases marking areas that should be flexible and those which should stay fixed helps think through and solve flexible layouts. In iOS terms these are known as layout constraints. Layout constraints are part of a system in iOS called “Auto Layout”. By decorating your interface design with layout constraints you can explicitly indicate to developers your intentions for how the interface should lay out.
An example layout constraint diagram (not to scale).
A big part of designing for iOS is not just where things are on screen, but how those things behave when you interact with them. The high resolution, portable, touch based screen of an iOS device is a whole new sort of canvas that gives you the opportunity to explore rich interactivity. Every application is unique and at some level there will be room for novel concepts, making these useful and delightful will truly excite your users.
Unlike the indirect nature of a mouse and pointer, on iOS users are directly touching the screen. This sort of direct contact affords more interactive manipulations. You’re probably familiar with Slide to Unlock, Pull to Refresh, Switches, Pinch/Unpinch and Slide to Dismiss/Delete. Balancing visible actions and manipulations is important, interfaces with too much (or non-obvious) direct manipulation create barriers to discovery and are difficult to learn. Conversely buttons clutter up the limited screen real estate, creating and confusing interface. In many cases users expect direct manipulation and will get frustrated when it doesn’t work.
Touch States & Feedback
When designing your buttons and interface elements be sure to give adequate feedback to the user. Users expect iOS to be highly interactive, this means that manipulations should have immediate effect. If your button doesn’t “press down” when tapped or it’s not obvious the user has interacted they may get confused. By default iOS puts a darkened mask over interface elements when they are tapped, but often this doesn’t quite fit. Keeping these sorts of details in mind makes the difference between a good app and a fantastic app.
Animations are useful for giving visual cues to the user that are not possible with a static image. For example if you have a shared notes list and the user initiates a sync, some notes will have been removed, some will have been changed and some will have been added. If you simply hard transition the two states it’ll be harder to identify what the changes were. Creating a visual transition for each of these backend state transitions will really help the user with processing and internalising the changes.
A Segue is the name given to a whole screen transition by iOS. You should use segues as a spatial hint to screen hierarchy. In iOS you may be familiar with sliding sideways to represent moving down a hierarchy, flipping to change settings, and sliding from the bottom to show modals. If you decide to design a custom Segue you should create a short storyboard (e.g. 4-8 frames describing how it should behave) or an animated demonstration. This will be very useful for a developer to understand your intentions and perfect the timing.
- Transitional Interfaces by Pasquale D’Silva
- The Year of the Looking Glass by Julie Zhuo
- My article on Animating with Physics
iOS is quite capable of support for custom font rendering, which is great news for type geeks. The default “System” font on iOS is (mostly) Helvetica Neue, but there is a wide range of built-in fonts available. Every iOS major update seems to add wider font support, so perhaps with iOS7 we’ll see even more packaged internally.
Customising tracking, leading and kerning in an iOS app is more difficult than on the web. While iOS6 has brought improved text control, it’s not something done easily within an iOS app. If you would like complete control over these parts of your design (especially with dynamic text) you should talk to a developer about the implementation details required.
When using custom typography it’s important to purchase a seperate license for use on iOS. At the moment this can often by quite difficult and depending on the seller these licenses can be prohibitively expensive. I’ve had success going directly to the foundry, but this won’t always work. To get around licensing you may be tempted to export all your type as images. This is not a very scalable approach, and is very inflexible to small copy changes. It can also significantly damage the usability of your app for users with poor sight.
- iOS Fonts a listing of default fonts
- App Fonts on Fontspring
- How Much Does It Cost To Use A Font In My iOS App on Dinosaurs With Lazerz by Craig Rozynski
Using your Tools
While every graphics tool is different, following are a few things you’ll need to remember no matter the software.
User Interface elements (like buttons and icons) are best created with vector based tools, however at some point those vectors must become bitmaps . When eventually rendering to a screen vectors need to be approximated to their pixel representation. When ‘rasterising’ vector lines which do not perfectly sit on a pixel boundary appear blurry or faint. Pixel fitting is the act of making sure horizontal and vertical lines sit on pixel boundaries. Properly aligning shapes with pixel boundaries can make a huge difference in polish, something you may not realise until the difference is demonstrated.
When XCode prepares your assets to be bundled with the app it completely strips any colour profiles associated with assets. To begin with you should refrain from using colour profiles in your documents at all, it’s best to completely remove any colour adjustment your software might add. Colour profiles cause unnecessary bloat in images, slow down rendering and give a false sense of security. The reality is that screens are different and will show colours differently. Rather than trying to fight that you should accept reality and test often on the real device to see how your graphics appear.
When you start creating canvases or artboards for each screen, you’ll be wondering what size to make them. The general recommendation is for you to create a canvas in pixels of the devices’ point resolution. So if you were designing for iPad you would set your canvas size to 1024 x 768 px (although 20pt at the top would be taken up by the status bar). When you eventually need to export resources you’ll also need to create retina resources. Fortunately there are scripts and tools to automatically create two times larger resources, saving you a lot of manual effort. So that this sort of scaling works flawlessly, you’ll need to exclusively use scalable elements and refrain from using bitmaps during design […] .
There is currently a push to switch to using the pixel resolution for your canvas. Depending on your tools this may be more or less difficult. There are a few dangers to this approach, it’s harder to get a feel for the physical size (as your graphics will be quite large) and downsizing resources is often tougher than upsizing. On the positive side, designing at 2x allows you to truly embrace the real pixels in the device. You can draw thinner lines and have more detail where you can’t fit it in 1x. You’ll find more articles and designers using 1x though, so for now I recommend sticking to 1x, but as retina device saturation increases we’ll see more people designing at 2x.
- Pixel Fitting by Dustin Curtis
- Snapping to Pixels in Photoshop by Paul Armstrong
- Setting up Photoshop for iOS Design by Marc Edwards of Bjango
- Pixel Perfection by Meng To
Typically Icon design is a seperate process to the User Interface design, as it is more of an illustration exercise. Albeit with lots of thought going into app branding, metaphors and style cohesion. In terms of style it’s important to maintain consistency by balancing the established iOS style and the style of your app. Even “flat” icon designs tend to include some three dimensional aspect to create that visual link.
By default iOS treats app icons with rounded corners and a gradient shine. The standard way to supply your icons is as a rectangle with no transparency which iOS will then decorate. While Apple does not guarantee consistency with the rounding it is possible to find guides to how much rounding is applied so that you can appropriately design your icon. You are also able to disable the gradient shine by indicating your icon is “precomposed”.
|Description||Retina Size (px)||Normal Size (px)||Optional?|
|App Icon for iPhone||114 x 114||57 x 57||close|
|App Icon for iPad||144 x 144||72 x 72||close|
|App Icon for App Store||1024 x 1024||close|
|Spotlight Search Icon on iPhone||58 x 58||29 x 29||check|
|Spotlight Search Icon on iPad||100 x 100||50 x 50||check|
|Settings Icon on iPad||58 x 58||29 x 29||check|
Above you’ll find the various icon sizes you’ll need to work with. If you’re only doing an iPhone app then you’ll only need the appropriate iPhone resources (the same goes for iPad). Many people get annoyed with the large amount of icons they need to make as each size requires a certain amount of customisation. Instead of resisting this, you should embrace the various sizes and use them as a design constraint. For example the iAWriter OS X icon design progressively discloses more of the word “Writer” the larger the icon size. This allows them to keep a clearly readable type size without losing the balance of the composition.
- Custom Icon Guidelines by Apple
- All the iOS App Icon Sizes by Neven Mrgan
- iOS Icon Corner Radius on Stack Overflow
- App Icon Template by Pixel Resort
- iOS Design Cheat Sheet by Ivo Mynttinen
Testing it Out
While many designers prefer not to do market research (understandably), this doesn’t mean you shouldn’t try out your designs on users. Instead of asking people what they want, show them what you’ve made and see how they react to it. By studying the interactions and tasks they find difficult you can learn more about what parts of the interface need more work. This should often be done early on before you have a fully fleshed out design, so that you can iterate quickly coming up with solutions to the problems you see.
Once you do have a more visually rich design done, remember to test it out on the real device. When you’re designing on a desktop screen elements will not be the same size or have the same colour depth as on a final device. Elements you thought were big enough, may be tough to see and subtle visual cues may instead be completely invisible. Remember to also try out your design in daylight, low brightness and even with colourblind profiles. All of these things will give you insight into its visual appearance in imperfect circumstances.
- A Guide to Mobile Testing on Smashing Magazine
- Brief App by Martian Craft
- Skala Preview by Bjango
- Live View by Zambetti
A very important and often neglected part of the design process is the provision of resources for development. It is best that the original designer (that’s you) is the one who packages and outputs resources from the source design file, they are the one who understands the design best and so will be the best for “cutting it up”. An accurate, complete, consistent and well documented set of resources significantly reduces the amount of back-and-forth needed with developers and you’ll get end results much closer to your vision.
At a base level you’ll need to provide a set of images in PNG format. Each image will represent an individual piece in your UI. For example you might have a generic-button.png and icons to be put on top of that button like add-note.png and hamburger.png. You’ll also need to hand over things like fonts, font sizes, dimensions and colours.
Retina Resources (@2x)
For each image resource you export you’ll be creating two images. One is the @1x resource and the other is the @2x (retina) resource. The retina resource must be exactly two times as large in each dimension as the normal resource. So a 44 x 88pt button will have a 88 x 176px retina resource. The retina version of your resources have the same name as the original, but you write @2x on the end. So for a button you’re exporting you would create button.png and email@example.com.
When an iOS app opens it immediately displays a pre-defined image while your app is starting up. To make it look like your app has loaded quicker than it actually has use a blank version of your UI as if no data has loaded yet. You’ll need to create a version of this for each screen resolution your app supports (including landscape on iPad), minus 20pt at the top taken up by the status bar. Try and avoid using a marketing splash screen unless you think it aids the user.
To prepare your user interface for exporting you should create a seperate canvas which will exclusively be for exporting. Rather than trying to chop up the design in place, pull it apart piece by piece and lay it out on a grid. You should make sure all similar resources have the same dimensions and are padded to the right size where appropriate. For example all your tab button icons should have the dimensions of the tab button (so you get to choose where on the button they appear). Consistency and predictability with resources helps developers avoid adding hacks to push resources around that are misaligned, which makes your design much easier to update.
One of the more important reasons for having a Slice Sheet is that it’s very easy to update, tweak or correct resources. By having a single place where all outputs happen, where everything is named correctly and no layers need to be hidden or shown to correctly output the right elements you make your resources very easy to re-export. Re-exporting is likely to happen if certain icons aren’t quite working or small parts of the aesthetic change. Keeping a Slice Sheet reduces the effort of exporting and allows you to make changes to your design up to the last moments of testing.
Interface Implementation Document
Simply handing over a package of image resources to your developer is not going to cut it. It would be like playing a very complex game of jigsaw, they’re bound to miss pieces and get things wrong. To aid their effort in recreating your brainchild you’ll need to detail quite accurately the various User Interface elements in your design and how they should interact. I’ve seen this done as a PDF document, as a Webpage and as a Keynote presentation, whatever you feel comfortable making – as long as it’s accessible. […]
Normally this document will go through the app screen by screen detailing each different piece of UI and how it should be reproduced. Including
- Dimensions the measurements and gaps between UI elements
- Constraints which parts of the layout are allowed to stretch and which aren’t
- Colours colours of typography, borders, backgrounds etc – give each a name + RGB and/or HSB (not hex)
- Fonts what font each button, label etc uses – include weight and size
- Resources where they’re used and their names
The more specific and detailed all this information is, the more likely they are to get it right. Creating something like this seems like a momentous job, but it reduces significantly the amount of time you’ll need going over your designs with a developer. Plus you’re much less likely to be annoyed by incorrectly implemented UI. Make sure that whoever receives this knows they can still ask more questions, as it’s likely you’ll accidentally leave things out.
The Full Package
To make sure you haven’t forgotten anything, here’s a list of things you’ll probably want your developer to have.
- Fonts – Any fonts you used in your design in TTF format
- Image Resources – All the individual UI images @1x and @2x in PNG
- Icons – All the icons (and retina versions) for your app in PNG
- Splash Screens – Appropriate Splash Screens for the devices you support
- Storyboard – A big diagram of screens showing how to get from place to place
- Dimensions and Constraints – Diagrams explaining dimensions of UI elements and their layout constraints
- Animation Details – Timings, videos, frames and diagrams explaining how animations and segues should work
- Colours – An exhaustive list of the colours used in the app as RGB or HSB, it’ll help to name them
- Resource Diagrams – Diagrams explaining which bits of the UI are made up of which resources and what those resources are called
- Font Labelling – Label all UI elements with the Typeface, Weight, Styling and Size
Exporting Tools & References
I’ve tried to cover a full range of topics as an introduction to iOS design. If you think I’ve left something out or you have questions and commentary – I’d love to hear from you. You can Tweet or Email me.
If you’d like more content like this
- Sketch – Professional Vector Graphics (my tool of choice)
- Adobe Photoshop – You know what this is, most iOS designers use it
- Briefs – Tell the story of your UI
- Slicy – Export PSD elements based on layer names
- PNG Express – Fast, precise and repeatable PSD exporting
- Color Snapper – The missing colour picker for Mac OS X
- Skala Preview – View your designs on a real device
- Quartz Composer Install Guide – Very Big at the Moment
- Tumult Hype – Create HTML5 Animations (useful for explaining interactions)
- Kaleidoscope – Text file and Image difference tool
- Red Pen – Get Feedback on your Designs
- Cloud App – Share files simply and quickly
- Colour Contrast Check – By Jonathan Snook
Sourced from Ben Taylor