Jason R. Anderson

Software Engineer & UX Designer

Tips for Mobile UI Design

I’d like to leave a message for all the aspiring UI designers out there. I understand the booming app industry has carved out a new sandbox to play in. It’s breathed new life into the industry for us developers as well. But, for you new-comers — as well as you seasoned veterans of other design disciplines, mobile UI design is like nothing you’ve dealt with before. Even if you have experience designing UI for web applications, the complexities in mobile software merit taking a step back and unlearning what you know.

Each platform we build for, has its own design guidelines, rules for interaction, and recommended best practices. For brevity, I’m going to focus on iOS, but understand that even though the specifics may differ from one platform to the next, the basic principles should remain the same.

Before you jump into a blank Photoshop canvas and start throwing controls up on a screen template (thank you, Teehan & Lax), take some time to get to know the platform. In the case of iOS, Apple have provided the HIG (Human Interface Guidelines), a detailed explanation of how UI elements should be used, how content should be presented, and how these components interact with each other on screen. You need to learn the HIG inside and out. Not because it’s the only way to build an app, but because if you don’t understand the rules at play, you won’t know when it’s ok to bend them — or break them — when the time comes. The HIG is kind of like a fake book for designers. If you know the basic melody, chord progressions, and words, you can improvise the shit out of your solo. If you don’t know the HIG solid, your solo might technically be music, but it won’t represent anything remotely useable as an app. Did I mix those metaphors up well enough to thoroughly confuse you yet? Let’s talk about the process — at least, the process that works for me.

Understand the Flow — aka: Forget about Photoshop for just a minute

When I was a strapping, young designer, I used to think I was saving time by sketching out my ideas in Photoshop. The problem with that approach is, you end up focusing more on the pixels than the design. In other words, you’re not designing the UI, you’re embellishing and that can lead to incredibly beautiful…pieces of shit. Before you can put pixel to canvas, you need to understand the app from all angles. And, I mean you need a deep understanding. Like, go to the developer and talk through the data model. Understand what bits of data are going to be generated on the device and what bits will come from the cloud. This is important stuff. If you know the data you’ll be working with, you’ll avoid throwing useless fake data as placeholders (which inevitably end up in the final design and have the developers in a fit because — “Those metrics aren’t being tracked! Why the fuck are they in the design? It’s not part of the spec! What do you mean the client already saw these and approved them!?!”). You also know what data goes in and what’s expected to come out, so you can ensure all bases are covered in your design.

You should break up every feature of the app into individual, discrete interactions. This will help you create a logical taxonomy and section off content for basic navigation. Think about where the user was, how and why they arrived at the current screen, and what they are expecting to do. Limit the interactions available on a single screen. For example, don’t make data editable directly inside a detail view. Instead, make a discrete interaction to put the view in edit mode (either by changing state of the current view, or bringing up a new modal interaction view). Otherwise, how do you cancel out of changing that data when the user goes back to the previous list view? At what point do you save the changes that were made?

Sketch Your Ideas — aka: No, leave Photoshop the fuck alone

While you’re pondering the finer points of interacting with your app, you’ll start to catch glimpses of how you might approach screen layouts. This is good, but don’t get too hung up on those visions before you’ve finished understanding the whole app. Some yet uncovered nugget of information may completely negate the interesting layout you thought would work a moment ago, so best not to get too invested in those ideas just yet.

There’s also nothing wrong with good old fashioned paper and pencil. The point is to try and stay away from anything that will temp you to dive deeper into the details just yet. I like to have 53’s Paper open on my iPad while I think through the interaction flows. I can quickly sketch out any ideas that come to mind and get right back to daydreaming about the app’s high-level behavior. Again, focus on behavior more than style, and let form follow function.

Time for Wireframes — aka: Nope…still not time for Photoshop

Although wire-framing templates and layout guides exist, the problem with doing your wireframes in an app like Photoshop is you don’t ever get a look at the big picture. All of your designs and everything you know is limited to viewing one screen at a time. I prefer to do my wire framing in Omnigraffle (either on my iPad or my Mac). Use a single canvas to layout multiple screens to show progression from one screen to the next. Show as much UI detail as possible (not pixel fidelity detail). This means show the state of your buttons as the user would interact with them. Does the interaction invoke a popover or an action sheet? Use some handy iconography to demonstrate user gesture interaction and overlay it on your screen layouts.

Prototype, yo — aka: Ok…you can use Photoshop now…a bit. You can use it a bit.

Prototyping should communicate behavior and flow at a higher level than the wireframes without investing the time in coding out an actual app. There are a lot of tools out there for this kind of thing, but I really like Apple’s approach the best. At last year’s WWDC (World Wide Developer Conference), they had a session called Prototyping: Fake It Till You Make It. With a combination of doctored up screen shots from apps with similar UI components and Keynote, they are able to create a rather rich prototyped experience. The real benefit here is the use of animation in the transitions. You can start to give the developer a clue on how the final app will play out.

On to Production — aka: Sure you could use Photoshop, but honestly…there are better tools out there

Now it’s time to take what you’ve learned in the previous stages and really build out those designs. Your UI positioning and component selection has already taken place, so at this point you should be looking at embellishment. I prefer to use Sketch for this phase, because it has great templates for high-fidelity layouts and the asset export features are second-to-none. You can also take advantage of symbols to re-use UI elements throughout the file, so making changes becomes a nice edit-once-update-everywhere kind of experience. Pro tip — export your assets for iOS as PDF at the 1x point size and use them in Xcode asset catalogs to have Xcode generate the necessary @1x, @2x, and @3x versions from a single vector file.