From web to iOS and Android design - a few lessons learned

I’ve designed apps and websites for a long time; over the years I have learned behaviors and practices that served me well when designing for desktop. The last few years have challenged those practices in fairly significant ways. Responsive web design definitely modified my long-standing practices for web design, and this past year has pushed my process even further as I designed exclusively native iOS and Android apps.

While there are many books and blog posts that discuss designing mobile apps, here are some of the lessons I learned while designing my first native mobile applications.

Designing indirectly is hard - prototyping is essential

When designing for web we don’t give our ability to work directly in the medium of HTML/CSS a second thought. Unless you are a skilled iOS or Android developer, when you design native apps, you don’t work directly in the medium. When designing a native mobile app all of your design work will eventually be filtered through developers; one of the primary tasks is to find the best way to communicate your ideas to the developers you work with.

Unless you are a skilled iOS or Android developer, when you design native apps, you don’t work directly in the medium.

It’s very tempting to design comps in Photoshop (especially for iOS and it’s relatively small number of screen sizes) and kick those out to the devs, but let me be clear: Delivering only static comps to a developer is not an acceptable practice in native app development. I completely admit that I made this mistake at the beginning of my first project. Animations and transitions are central design features to all native apps and must be specified by designers. Moreover, prototypes need to be shown and interacted with on actual devices.

it’s very tempting to design comps in Photoshop and kick those out to the devs, but let me be clear: Delivering **only** static comps to a developer is not an acceptable practice in native app development

Luckily, there are great prototyping tools for us. I simply cannot recommend Flinto enough.

Flinto literally takes minutes to learn, does a great job simulating iOS transitions, and allows you to play with your prototypes directly on your phone.

You might hear other designers recommend Xcode or Quartz Composer for prototyping; while there is merit to using these apps for prototyping, the learning curve is just crazy steep (and with Quartz Composer you can’t preview on a device).

Trust me: Start with Flinto, and when it does not meet your needs, take a look at other solutions.

Learn the lingo

I totally recommend learning the technical names for all UI elements of the platform you are designing. Some great resources for this are the iOS Human Interface Guidelines and Google’s Android Design websites.

iOS UI Status bar description
Status bar description in the iOS Human Interface Guidelines

In addition to aiding communication, it will also help you gain the respect of the programmers. Portkit is a great resource viewing the equivalent UI controls across Andoid and iOS.

You gotta deal with Android’s Back button

Google has always been a web company, so it’s not a surprise that Android has a global, persistent “Back” button similar to web browsers. When the web was simply pages, the behavior of the back button was easy to understand. As apps started to appear on the web, in many instances it was not always clear what the back button should do. This confusion definitely persists in Android; though newer versions of Android have tried to address this issue, in my opinion, it is still more confusing than how iOS handles this issue by only presenting “back” buttons contextually.

Diagram of back button use from Android Guidelines
Diagram of back button use from Android Guidelines

Make sure to read the guidelines about back button usage on Google’s Android Design website. I also highly recommending watching the Android Design in Action series on Youtube. I found the Navigation Drawer episode especially useful in understanding “Back” and “Up” button issues.

Think about user input and software keyboards

In general, the majority of web designers never really think much about keyboard input while designing. As a rule, on mobile try not to present a keyboard at all; I highly recommend listening to Luke W’s podcast on mobile input. When you do need a keyboard, each OS has various keyboards available that can be used for various types of input. Input on mobile devices is more difficult than desktop, so make sure you take advantage of the various types of software keyboards. If you don’t specify which keyboard you want, don’t be surprised when the devs come and ask you (or choose an inappropriate keyboard).

One interesting thing I learned is that there is no numeric-only keyboard on iPad; if you need this, the devs will have to make a custom one:

screenshot of numeric keyboard for iPad
Custom numeric keyboard for iPad

You can also use a popover for numeric input as well. These can work great, but be careful about using then for applications that need lots of numeric input (the issue is that popovers do not appear in a consistent location, so are a bit slower to target than normal keyobards.

screenshot of quantity popover for iPad
Popover for iPad - Spanish-English Dictionary and Verbs version 1.4.3

Wrapping it up

Designing for iOS and Android over the last year has been great fun for me. With mobile being so incredibly important these days, I doubt there are many designers who have not dipped their toes in the responsive web design world by now. That being said, many designers have not had the opportunity to actually work on native mobile apps while working side-by-side with developers. This article was written with you folks in mind. I hope you found this post useful!