From Web to iOS
A learning experience in interface design
--
This past January, I experienced one of the biggest personal and professional upheavals of my life: I packed up my bags, quit my role as partner and designer at a graphic design practice, said farewell to family and friends, and moved across the Atlantic to London, England.
This change of residence also brought with it an admittedly less drastic (but no less exciting) change in profession — after spending years as a graphic designer and front-end web developer, I was taking on the role of interface designer for Future Workshops, a digital agency specialising in mobile app development.
Though I had been wanting to get my hands dirty with native app design for some time, I have to say that the shift from graphic and web design to native UI was a bigger challenge than I had ever imagined it would be. I came into my role at Future Workshops thinking I already knew all I had to about interactive design — what could possibly be so different about designing for apps as opposed to designing for the responsive web? Well, as it turned out: a lot. A hell of a lot, actually.
I’m now five months into my role as an interface designer, and I’ve managed to pick up a fair bit of knowledge about both the broader and finer points of designing for native apps (particularly for iOS). Although I’ve still got a lot to learn, I’d like to share two key insights that I hope will prove helpful to any of you who are making (or wanting to make) the move from graphic/web design to native app design.
Know thy operating system
The first important lesson I learned in designing for iOS apps was this: the HIG is your friend.
As someone who has a strong history in graphic and web design, I came into my new role thinking (rather naïvely and arrogantly) that I pretty much knew it all. This was an incredibly inaccurate assumption. While web design as a medium has its own set of standards and best practices, it is incredibly open in terms of what works and what doesn’t. iOS, on the other hand, is somewhat more prescriptive in terms of how an app should function and even look on foundational level.
Case in point: information hierarchies in iOS are almost always presented in a left-to-right order of descent. When you “drill down,” you always load a lower level of detail from the right side of the screen; accordingly, moving up (or back) in an information structure always takes you to the left of your current view (modal views are a bit different). Conversely, my first (blissfully ignorant) set of wireframes at Future Workshops depicted an app in which you drilled alternately left, right or down depending on the path you were on. You can imagine how well this went over with the developers.
After a short series of blunders not unlike the one described above, our director gave me a friendly but strong recommendation: to read Apple’s iOS Human Interface Guidelines (HIG) front-to-back. Initially, I wasn’t terribly keen on this task, because I thought the HIG would simply tell me how to make an app “look like iOS.” I wanted to make my app designs look completely unique — I didn’t want some silly manual telling me how to design. (Yes, I’ve been known to hide inexperience behind brazen over-confidence. I’m working on it.)
What I realised, however, was that by not getting to know the iOS ecosystem in extreme detail before designing for it, I was completely ignoring the imperative for design to suit its context. Just as an architect should get to know details about an unfamiliar site’s climate and culture before designing a building for it, someone designing for a digital environment should know what patterns and paradigms exist before creating an app for that environment. A building designed for a geologically stable foundation might topple over in a region prone to earthquakes, and an interface designed for the web might make zero sense within the framework and expectations of a mobile OS. Collapsed buildings and bewildered users are never a good thing.
As it turns out, the HIG is a goldmine for those just getting familiar with designing for iOS (even if you’re already a seasoned app user, as I was at the time). Within a few short reading sessions, I picked up all there was to know about properly implemented navigation bars, tool bars, tab bars, and segmented controllers. I learned the difference between activity views, collection views, table views and split views, and when (and when not) to use alert views and modal views. What I did not learn was how to make stitched leather calendars or reel-to-reel audio interfaces, as I initially thought I would (I’m facepalming myself as I write this).
The HIG, for the most part, tells you only what you need to know in order to make an app fundamentally usable and logical for your users. The aesthetic design of the app is still up to you for the most part, but absorbing what the HIG has to say means that you can design those aesthetics in a way that plays to the strengths of iOS’ inherent paradigms, not against them.
Take it from one who balked at the task: read the HIG. And take copious notes. It will ease your transition more than you can imagine.
It’s dangerous to go alone; take a developer
If the HIG is your friend, the developer is your wingman. The amount of times a developer’s input has critically altered my design for the better is beyond counting. If you’re the Fresh Prince, think of the developer as Jazzy Jeff (just google it, kids; and buy the box set while you’re at it).
I consider myself incredibly fortunate to work in a company composed primarily of developers — at present, we have a staff of 14, 4 of whom aren’t from a development background (and only 2 of whom, including myself, work on the design side of equation). This means that, on any given project, I’m working alongside at least one person (usually more) who knows what works and what doesn’t within the technical space of iOS better than I ever will.
Working closely with developers makes me a better designer, and serves to make each product we build inherently better. I can always count on my developer’s keen eye to spot a part of my design that just won’t work (or will at least be a potential challenge to implement), or to point out how the design might be exponentially improved. A developer can provide you not only with input that is one step more removed from the design than your own (always good to have), but also with technical knowledge and insight that one simply cannot possess without diving deep into Objective-C (or whatever programming language is being used for the project). I’ve noticed that the longer I work with our developers, the fewer flawed designs I create; instead, I’m beginning to craft designs that the developer is excited to work with.
Of course, the relationship between you and your developer needs to be a two-way street — you both need to help each other. One very important way to give your developer a hand is this: stop giving them PSDs (or .sketch files if you love Sketch as much as I do). It’s no more the developer’s job to wade through your comps and cut out assets than it is your job to refactor their code and fix their bugs. (What? Of course developers don’t write buggy code, what are you talking about?)
Be a good wingman and provide them with production-ready assets, or colour swatches, type specs and pixel measurements when your assets can be recreated in code (and, for that matter, learn to design assets with code-based recreation in mind).
I make it a priority to provide my developer with what we call a “UI-development guide” on every project. This document is essentially a living collection of 1:1 renderings of every view I’ve designed for the app, with notes indicating file names of assets (or specifications for codified assets), relevant information about typography and layout, and breakdowns of dynamic elements’ behaviour (like transitions or other animations) when I’m not able to create prototypes to demonstrate. This will go a long way in creating a positive working relationship between you and the developers you work with, along with providing a valuable, ongoing product reference for QA specialists and clients alike.
Conclusion
Designing for context and working collaboratively across disciplines are two key principles for design in any medium, no less so in the realm of digital interface design. Of course, there are lots of finer, medium-specific ingredients for creating a successful native UI, and while they’re beyond the scope of this article, I’d like to leave you with a few key technical resources and articles that I’ve found particularly helpful over the past months. You’ll find them at the bottom of this article.
I hope that the topics I’ve discussed here prove to be helpful in your journey into the world of designing for native apps; if you’d like to discuss these points (or any others) in greater detail, feel free to get my attention on Twitter or via my website.
Best of luck!
Additional reading:
Sizes of iPhone UI elements — a great reference chart for common UI element dimensions.
iOS Design Cheat Sheet — similar to above with additional device specs.
iOS Fonts — a list of system-provided fonts, organised by major iOS releases.
Transitional Interfaces — a great primer on animation.
Designing for the Empty States — easy to overlook, critical to consider.
Pixel Perfection — an informative guide to technical asset creation.
