App design is an exciting process to be part of and has been a highlight for me while working at Hitcents. Designing mobile apps should be more than just slapping a slick interface on a set of controls but a process that explores the user experience. Part of what makes designing apps a neat experience is the process and each designer will have their own approach to app design. One designer's workflow may not work for the next, but I would like to share some of the processes I use as I design apps here at Hitcents.
Establishing the Scope
When our creative team at Hitcents is working on designing a website for a client, one of the first things that the designer will need to fully conceptualize the site is a good site map or flowchart clearly delineating the process and functionality of the entire site. I found that as we moved into app development that sometimes this step was left out and that can make the process more difficult. I recommend strongly that as with any other interactive project, that you develop a solid flowchart for your team to to be able to work off. Not only does this provide a solid reference point, but it helps you to create a better working knowledge of the app by forcing you to lay out the functionality and how it relates in reality and not just in your client's mind. Working through this step will often raise important questions about the functionality and scope of the project that need to be answered now rather than discovering things farther down the road. This process really gets to the heart of what app design should be, a thoughtful development considering the user experience overall. As a designer this may not be your final call, but it will be beneficial to you if you can make sure that the scope of the project is established from the beginning. It is hard to properly fit in functionality that was not there from the beginning and often by the time these additional options are added you will have reached your creative tipping point and be tempted to just slap these new features on, which doesn't do your design justice nor does it produce the ideal final product. Save yourself and your client some tough times in the future, get everything laid out and agreed upon from the early stages.
One of the things that should be established in this step is deciding what mobile platforms and devices this app will be available on. Building apps to be cross-platformed is one of our specialties at Hitcents we can build an app and deploy it not only to iOS, but also Android and Windows 8 while saving time by sharing some of the codebase. Building cross-platform apps though requires a lot more work on both the designing and coding end. Each platform has its own distinct user interface (UI) that will need to be individually designed and programmed. Even if you are just limiting your app to one platform such as iOS you still need to consider whether it is for the iPhone, iPad or both, while some graphic assets can be shared between these you will need to create separate layouts for both of these devices.
Getting Some Background
Research is an important part of working through the functionality of a client's app. Familiarizing yourself with existing apps that have a similar purpose and noting the solutions that they came up with and problems that they have yet to solve is a great way to get inspiration and to experience what works and what doesn't. When building native apps it is important to understand some of the basic differences between the major platforms to create a unique and tailored experience for each one. iOS, Android, and Windows 8 each have their strengths and weaknesses and to apply one layout across all three would provide a very poor user experience. Users expect apps on iOS to act like a typical iOS app and they will expect a Windows app to act like a Windows app, part of providing a good native user experience is being able to decide when it is a good idea to follow these standard controls and when it is better to break away from the standard navigation. It can be tempting to veer from standard controls in an effort to be unique and innovative, but that desire needs to be tempered with the overall user experience, if the new navigation is too difficult or unnecessary the design may actually backfire and make your app less enjoyable to use.
Another valuable step to help sort out the functionality of the app and work through the navigation process is wire-framing. I have done this with a couple of recent apps and have found them to be a good way to communicate to the client the functionality and scope of the app. Wireframes do add extra time to the initial project, but the value that they add can save you time in the long run. Recognizing and correcting core navigation and feature issues early, has the potential to greatly improve the overall quality of your app. Taking the time to wireframe the majority of the screens beforehand again allows you to get back to the heart of the app – the way that the user will interact with it, not just what it looks like on the outside. It is easier to iterate different versions at this level before getting too caught up in what the pixels look like, and this also allows for more exploration and problem solving without wasting time on creating pixel perfect designs that don't end up being used. There are numerous applications and websites out there for creating wireframes, but the tool I've settled on for now is Adobe Fireworks. A couple of the advantages for me is that it is software that I already have, not an additional service to purchase, and since Fireworks is a fully featured design application, there is no limit to my wireframes. Fireworks also has an extendable common library with a number of pre-made assets to speed up your wire framing and supports 9-scale resizing for symbols allowing you to use one symbol in multiple ways. The biggest benefit for Fireworks over other fully featured design software like Photoshop is the ability to create and export interactive wireframes.
For an app I am currently working on we were able to mockup clickable HTML wireframes exported directly from Fireworks. I was then able to use a free little app called LiveView to screencast it to an actual iPad and let the client navigate the wireframes by tapping on the iPad. This process provides a better deliverable to the client and helps them get a feel for what the actual app would function like without getting caught up in the visual appearance. Interactive HTML wireframes can also be uploaded easily to a server and then quickly shared with remote clients to review on their own time. With the help of Adobe's PhoneGap it is possible to even package those HTML files as a standalone app that you could then demonstrate on a mobile device. Porting your HTML with PhoneGap is very easy to do for Android, however it is a little more complicated for iOS due to required signing keys. Providing this type of interactive deliverable to your client not only demonstrates the thought behind the app's design but allows your client and opportunity to discover what will work best before we invest time in the design or programming of the actual app.
After impressing the client with interactive wireframes and making them feel comfortable with the functionality of the app, it is time to establish the overall visual appeal of the app. Note how much work can be done and the groundwork that can be laid before we move to designing the actual app's interface. It might be tempting to just skip directly to this step without doing any of the wire-framing and thoughtful development, but working through this beforehand will allow you to solve problems before you get emotionally tied to your designs. Typically I've mocked up a sample screen to show the client, when I'm exploring the appearance of an app. I think another method that is worth mentioning is the use of Style Tiles which is somewhere between using mood boards and creating high fidelity mockups. It may not be appropriate for all projects but it may let you work more freely than you would with a full blown mockup.
Starting the Design
I mentioned that Adobe Fireworks is my tool of choice for wire-framing but when it comes down to working with the actual pixels in this stage of the project I primarily use Photoshop. There are designers on both sides of the Photoshop/Fireworks battle and some, when it comes to designing for web, advocate eliminating the software and just designing in the browser. All of these approaches have their advantages but it comes down to what you personally use best. Fireworks probably can do much of what I use Photoshop for and some of it it does better, however I move more quickly and accurately in Photoshop and Photoshop fits in with my workflow for exporting the final graphics for the app. While I think it is important to be willing to expand your toolset and maybe even helpful to make some drastic workflow changes like designing in the browser when working with web, keep in mind that just because one tool does some things better it does not mean that it is the right tool for you.
You can start building your app from a blank white canvas but what I find useful in most cases is to get some sort of framework to build off to save yourself some time and provide healthy guidelines. There are some really good tools to get you started, Teehan+Lax provides some free GUI PSDs, I particularly like their ones for iOS. Android provides helpful stencils and icons on their own developer site that can be downloaded and Windows supplies some basic PSDs of design assets for designers working on Windows Store apps. Exploring these assets and using some of the elements as a starting point for your app will help you maintain consistency while developing the design for the app. Spend some time with the design guidelines that these company's provide on their developer sites it will help you understand the individual platforms better, and if you are like me you might actually enjoy it.
An important aspect to understand when you are beginning to design the user interface elements is the number of different resolutions that your app may be displayed on. Unless your app will be strictly limited to a very small set of devices, to ensure that it displays correctly across the mobile universe you will need to package multiple sets of resolution images for display. If you design for Windows 8 that OS could be displayed on anything from a tablet to a large TV screen or monitor, however due to the aesthetic of Windows 8 it does not rely heavily on images and will have more flexibility and require fewer images provided by the designer. Android complicates the situation with not only multiple devices that have a wide range of size, but also different screen densities that require separate sets of images for the interface. To get a better grasp on screen size and density for Android check out Teehan+Lax's tool and Android's own documentation. Designing for iOS is a little more straightforward because the number of devices the app will run on is limited but that continues to grow as we see with the addition of the iPhone 5. There are essentially five sets of images potentially required for iOS: iPhone (320x480), iPhone Retina (640x960), iPhone 5 (640x1136), iPad (768x1024), and iPad Retina (1536x2048). Apple conveniently doubled the resolution when they made the retina displays which makes it easier to provide assets for both devices. Though Apple took grief for the iPad mini not being a retina display, if they were not able to squeeze a 1536x2048 display into the 7.9” device they did the designers a favor by keeping it the same resolution as the original iPad rather than introducing another resolution somewhere between those two that would require yet another separate set of images. Since both Android and iOS require multiple sets of images it is good to understand this from the beginning so you can prepare your files accordingly and are not finding yourself desperately searching for a way to double the resolution of all your images at the end.
For my workflow in iOS I start designing for the retina (@2x) display and then scale those images down for the non-retina (@1x) devices. It is usually easier to scale images down than it is to scale them up and there are some excellent tools available to assist in that process and steps that you can take to make sure your PSD files scale appropriately. Vector shapes in Photoshop are invaluable tools overall and also play well when you need to scale whole elements up or down, but you need to make sure from the beginning that they are aligned with the actual pixel grid. Photoshop allows vector shapes to create half pixels that will not output well, to keep that from happening turn on the transform to pixel grid if you are using Photoshop CS6 (Preferences>General>Snap Vector Tools and Transforms to Pixel Grid) or make sure snap to grid is active (underneath View) and set your grid under (Preferences>Guides, Grids, Slices) to 10 Gridlines and 10 subdivision (or any other equal set of numbers) this will give you a grid to snap your vector objects too. You will reap the benefits later when you output PNGs that are crisp and scale well.
When designing for iOS at the retina resolution, keep in mind that when you export images you will need to create actual size (@2x) and halved size (@1x) therefore it is best to deal with even numbers with your dimensions and layer style settings so that they divide easily. When it comes time to export your actual graphics there are a few different methods. We used to just export the @2x image from Photoshop using the “Save for Web” dialog box and then export them again but scaling them by 50% to create @1x images, this produced a decent file size but was not consistently sharp and would sometimes create odd artifacts in the halved images. To deal with this we started using a command line script called ShrinkPNG that generates @1x images but with sharper scaling and resolved many of those issues.
Since then though I have discovered a great little app Slicy that I have been impressed with. Not only does it scale just as well as ShrinkPng but it allows me to name my images and set export boundaries all within Photoshop, all I have to do is drop the PSD on the icon and it automatically cuts my images out independently of each other (they could be overlapping in the actual PSD, but Slicy can export layer groups individually) and can scale them up or down to produce the proper @2x or @1x image. One drawback is that Slicy does not have adjustable compression settings yet and creates rather bloated PNGs that are larger than either Photoshop's “Save for Web” or ShrinkPng's files. This brings up another useful command line tool Smusher that provides lossless optimization for PNGs, you can run this on all your exported PNGs to reduce their file size without losing their quality. This is a good idea to do on your image set even if you do not export using Slicy, because Photoshop and ShrinkPng do not create fully optimized PNGs and can afford some slimming down themselves. As a designer don't be afraid to explore new tools or even branch out into the world of command line, there are some great tools out there. If you don't understand it at first (I have trouble sometimes getting my command line to work right) go bug the programmers to show you these things, combining and overlapping knowledge between the design and coding world can end up providing even better solutions.
9-patch is a good example of how understanding a little of the coding world can help streamline the design and implementation process. 9-patch images allow you to divide an image into nine sections and will automatically stretch specific portions of the image while leaving the others uniform. This enables you to create one image, such as a button, but use it at different sizes. This saves time for both the designer and developer, creates a more uniform UI, and slims down the size of the app by reducing the number of images required.
When I designed my first app I jumped into it without understanding this and due to that we ended up having to create separate images for almost every single button in the app. We tried to keep the number of images down a little by keeping some of the popups in the app the same size, but if I had from the beginning designed buttons and popups that could be scaled using 9-patch it could have provided an app with a smaller footprint and taken us less time. Not all elements can be made with 9-patch images and will require separate images, but the fewer images you use the more realistic it will be to modify an entire UI. For example, I'm currently working on an app that will potentially need to be branded for different universities. If a particular button is used throughout the app and I have created multiple images to accommodate the variety of widths in which it appears, when I need to do an overhaul to the color scheme all of those images will need to be replaced, but if it was built using 9-patch images I can change the color of a button throughout the entire app with just a change to the one individual 9-patch image.
Android and iOS however handle 9-patch images quite differently. iOS doesn't require any modification to the actual image itself, all it requires is a list of four numbers that create invisible guides so that it knows where to start stretching the image and knows to double those number for the retina display. iOS even handles the “stretchable” area by repeating the pixels rather than just stretching the information, this allows for repeatable patterns and textures to be used. Android, rather than operating off coordinates requires 1-pixel black lines on the edge of the image to indicate where the stretchable areas are and will just stretch the information in those sections rather than allowing it to repeat.
Having to add one pixel black lines makes things difficult when exporting multiple resolutions for Android. Android provides a visual editor in a small app “draw9patch” in their SDK that you can download and use. It will automatically create the extra pixel around the edge for you to draw your border and let you preview what it will look like when stretched out and save it with the appropriate extention filename.9.png. For one of the cross-platform apps I ended up drawing the black lines directly in the PSD and then scaling my entire PSD with the different GUI elements (created with vector shapes) up to the higher resolutions (see Teehan+Lax's tool for dealing with multiple resolutions) and then cleaned up some of the half pixels that were created. You will also have to adjust or redraw the black 9-patch lines so that they are only one pixel. This makes creating 9-patch images for Android difficult to do at multiple resolutions and can potentially be time consuming. Using 9-patch images though can really help cut back on repetitive images and make both the designer and programmer's jobs easier.
Exploring app design is a great opportunity to expand your skill set and knowledge base. If you are not programming the app yourself, don't be afraid to work closely with the developers. Take special care to run functionality by them during the wire-framing stage to make sure it is reasonable, it will help make the process smoother. Remember that designing a good app is more than just creating a sharp looking design, it is a thoughtful process that considers the user experience.