7 things I’ve learned about designing iPhone apps

Over the years of designing iOS (iPhone) apps for myself and for clients like Cisco, Apple, Pocketsuite, Wyshme, Planzio, Instaviser and other startups. I’ve learned a number of things along the way, below is a list of seven. I hope they will help you on your next app design project.

#1 Start with a sketch
This might sound obvious but it is worth making this point first on the list. Always, always get away from a distracting screen and sketch ideas on paper. It’s surprising how much progress you can make just by doing this alone whether it’s a simple app with fewer than 10 screens or a more complex app with 100 or more. Sketching gives you the opportunity to take a breather from pixel perfection and focus on the flow and story you are telling with your app. This is an important step with conducting good research and market analysis. There’s a lot more to say about the importance of sketching but that will have to wait for another post.

I recommend using plain old white paper or a sketching template, a thick black marker and a fine point black marker, the main thing to keep in mind at this stage is to focus less on the details and more on the flow of your app. If you’d like to download the iPhone sketch template I created sign up for my free email newsletter and I’ll send it to you! I’m not against digital sketching, for example Paper from FiftyThree is excellent, but I don’t think it is a good first step, especially if you have limited mobile design experience. The main issue with starting the process in a digital medium is you’ll make it too fancy because the tools allow it and at this stage you want to avoid spending too much time on the details, fancy will come later.


#2 Keep the context in mind

A common problem we can get in to as designers is spending too much time creating a screen without considering the larger story and context that each screen fits in to. For example, if you’re designing a news app it’s like designing an article page without first defining the structure of the other pages. Sometimes this can be a good starting point but it’s generally more helpful to create your structure across your app first and always consider the context that each screen will fit into. Even worse is designing an element of the screen without looking how that element will actually work within the context it will be seen.

Using the news app example below, this is like designing how a headline for your news article without considering other elements that will be seen in the article.

Example 1: Get as much of the flow outlined in your app as possible. When opening up Sketch I create a series of artboards like this and start dropping sketches and simple text to help me get a picture of the broader flow.

App flow

Example 2: Design each screen with all of the elements you’ll need to consider

nyt-example

A few suggestions:

  • Create a text outline of your app
  • Whiteboard out the most common flow of your app
  • Create a mind map
  • Create a flow of your app – Sometimes creating a bunch of blank screens in Sketch with simple text to represent each screen is enough help me define the flow. (shown above)

#3 Create prototypes
Prototypes are invaluable because they help you keep context in mind, work through a flow and tell a good story. Without actually experiencing a prototype of your app it’s going to be very difficult to understand how it’s going to work without jumping in to code. Neglecting prototypes can also be very expensive and take you down the path of building the wrong thing rather than the right thing. This not only adds to technical debt and design debt but also lost time as well.

For your first prototype I recommend starting with the most common path that you recommend users to take. Consider the following using the news app example:

  1. Open app – It’s common to show a splash screen to users here despite the iOS HIG guidelines to show the chrome of your app without content to make it feel like the app loads faster. Here are some examples of launch screens from the pttrns website
  2. Initial app tour – generally two to three screens showing the user what the app is about, this is where you have the opportunity to pitch the value to the user
  3. Sign Up/Login screen – Make the sign up and login flows as simple and straightforward as possible so the user can get in to your app. There are some exceptions but generally you want to keep these flows simple.
  4. First time experience of your app. Example: a list of recent news articles
  5. First action that you would like the user to take. Example: article screen
  6. Detail of that first action. Example: promoting the share options as a first time experience to the user
  7. Share actions. Example: when the user taps on the sharing option showing the share sheet or custom share actions to the user
  8. Sharing successful. Example: after the user shares an article showing a “successfully shared” screen.
  9. Follow up screen. Example: recommended articles based on what you’ve shared or return the user to the article screen

The above outline is simply an example and will hopefully serve you as a spring-board for your next project.

An app that I use daily to create prototypes for clients is called Invision, check it out, it’s excellent and very easy to learn. Other prototyping apps that I’ve also used include Flinto and POP.

 


#4 Keep the focus of each screen narrow
As screens get denser and larger for mobile devices the risk is thinking we can show more on each screen. Don’t fall in to this trap, please. Your users will thank you if you can keep the focus of each screen as narrow as possible. Research shows that we can only process a few things at a time so don’t try and be too smart by cramming a bunch of stuff with hidden meaning into a small mobile screen, your users won’t get it.

Steve Krug in is book “Don’t Make Me Think” says:
We’ve all seen pages— especially Home pages— that just have too much stuff. The net effect is the same as when your email inbox is flooded with things like newsletters from sites that have decided that your one contact with them has made you lifelong friends: It’s hard to find and focus on the messages you actually care about. You end up with what engineers call a low signal-to-noise ratio: Lots of noise, not much information, and the noise obscures the useful stuff. When you’re editing your Web pages, it’s probably a good idea to start with the assumption that everything is visual noise (the “presumed guilty until proven innocent” approach) and get rid of anything that’s not making a real contribution. In the face of limited time and attention, everything that’s not part of the solution must go.

Krug, Steve (2013-12-23). Don’t Make Me Think, Revisited: A Common Sense Approach to Web Usability (3rd Edition) (Voices That Matter) (Kindle Locations 634-641). Pearson Education. Kindle Edition.

The same goes for app design, when the main screen of your app is flooded with too much stuff the result is a low signal-to-noise ratio. When you’re creating your app I recommend following Steve’s advice, start with the assumption that everything is visual noise and get rid of any concepts or elements that are not making a real contribution.

Bonus:

An article that I often site is from Luke Worbloksi called Obvious always wins. This article helps you to keep in mind the importance of simplicity and keeping critical information visible.

 


#5 Start with conventions
Okay, you’re a designer and you want to flex your design muscles. I understand. But following well understood conventions that exist from the iOS Human Interface Guidelines will actually help you be more creative. How is that so? Glad you asked. The conventions from the iOS HIG gives us are a great starting point and in most cases help us to create more intuitive experiences for users. Given that we can use conventions where appropriate is frees us up to create very meaningful and innovative experiences where it really counts for our app and our users. In other words, being special is great but your app doesn’t need to be special in every way, just in the areas that really count. Check out the iOS Human Interface Guidelines to get a sense of how to use existing conventions.

A few additional resources to get you started

 


#6 View your designs on device

 

unsplash-view-on-device

Image by Jonathan Velasquez

This step is essential because looking at a design on your laptop or large cinema display is not the same as looking at it on your device.

Here are a few tools and methods you can use for this

  • Sketch Mirror
  • Send your designs to dropbox
  • Send a png to yourself in Email or Messages (this still works great btw)
  • LiveView – this is the tool I used to use before Sketch Mirror
  • Skala preview

The method doesn’t really matter that much as long as it doesn’t take you much time, just do it. It’s amazing what can go overlooked as you design on your laptop without any consideration to what the final design will look like on your device.

 


#7 Test and refine
You’ve worked hard getting your app to the point where it’s ready to be tested with real users. This is where the learning really starts and frankly, it can be very exciting or even a bit frustrating. If you’re interested in creating something usable you should be interested in how people are going to use your app. If the initial feedback isn’t positive, don’t fret that just means there’s a lot of opportunity to make it better. Try to get as many people to test your app or prototype. As each user is testing your app ask them to verbally express their thoughts and issues when they run across them and make sure to take notes. Invisionapp.com is also a great resource for this and allows you to comment on your app prototype screens, insert dev notes and even tour points.

Subscribe to my free email newsletter and get your free iPhone sketch template!




When you subscribe to my newsletter you’ll receive my best advice, resources and tips on designing iOS applications, about once a week. I promise to never spam you and you can unsubscribe at any time.

#appdesign#ios#iphone#process