Designing Mobile Apps: A Beginner’s Guide

Part One: Ground Rules

Until fairly recently, design took a bit of a back seat in app development. It was generally thought that if you wanted to make an app, you could learn Objective-C in your bedroom, throw some code together, put it on the App Store and make tons of money. Ta-da!

Realistically, it’s a lot different. Great app design is fast becoming something that is coveted — app design agencies, that have until recently been overcrowded with developers, are now hiring UI and UX designers like there’s a global shortage.

So what does an app designer actually do? You might be surprised to hear that coding is only one part of making an app. There are lots of other things that need to happen before the coding even starts.

I work within the engineering division of a global broadcaster, and it’s my job to create a nice experience for our internal mobile applications. These are the apps that we use for everyday business; things like managing schedules on the move, or our corporate directory. I design the user interface, the iconography (and in many cases ad-hoc graphics) and I’m responsible for creating the overall experience.

I’m also responsible for going out to the business to seek out good ideas and evaluate how we might take that idea and make it into an app. You could say I look for great apportunities. *groan*

I’ll try and take you through the major parts of my role in designing an app. It’s worth mentioning up front that we make our apps using iOS as the majority of our apps are built for the iPhone and iPad. There are quite a few steps, so I’ve separated this across four sections.

Back to ground rules though — designing an app starts with some concrete principles to keep in mind. For us, they are:

Absolute simplicity.

The simpler, the better; they’re more likely to work across the iOS devices and less likely to crash on an Apple update if they don’t stray beyond developer guidelines. The Apple Human Interface Guidelines (HIG) outline basic app standards that we stick to. We only ever go off-HIG if absolutely necessary.

No instruction manual necessary.

The minute you need a handbook on how to use an app, your app has gone astray and you need to go back to the drawing board.

Always think of the user.

It’s all well and good making a beautiful product and being proud of how shiny and clever it is, but if it doesn’t fulfil the basic needs of its intended user, then it’s a failure. A successful app doesn’t even have to be pretty.

We keep these in mind at every step of our journey, through from concept to release. Designing an app encompasses the germination of an idea, to tweaking and rethinking it, to the end product. In most cases, our end product is only the first version; we have roadmaps for many of our apps to help us manage future versions and intermittent releases.

Part Two: Before The Pen Goes To Paper

Step 1: Determine your audience

By audience, we mean the people that will be using and interacting with the app. The majority of your audience will be the everyday users, but you may need to take into account those looking after databases you might want to tap into. Making sure an idea has lift is the most important part of making an app; if it can’t exist, then it won’t exist. Examine who might interact with it, then once you know that the potential and interest is there, make a start.

Talk to your intended future users, or current users of an existing app, should one already exist. How do they use the app? What features do they rely on, and how easy is it to accomplish the task at hand?

Step 2: Gather requirements

‘Requirements gathering’ sounds like a fairly boring paper-pushing exercise. However, it is absolutely crucial to the success of your app. If you don’t know what you are setting out to achieve, you will end up with a sprawling web of ever-growing requirements that will force your app to detour to some weird places. Ask yourself: Is this feature necessary? Or is is just a nice thing to have? If it’s absolutely necessary, put it on your list. If it’s just pretty — add it to a list of ideas for future releases. You can discuss it when you can evaluate how much value it might add to your users.

Your list of requirements should under no circumstance get bigger. I know this sounds a bit weird, but the best advice I can give to any designer out there is that you should start with that huge list of absolutely everything that the app could possibly do. This allows you to engage with any stakeholders and make sure you’ve thought about absolutely everything. Then go back through and cross out anything that you don’t need, or can’t do yet. Keep crossing out, and moving the ‘not yet’ things from the current version specification to a list that can be considered for future versions.

A really simple first version is easiest to build, and features are easier to add in once you’ve got the foundations sorted. Don’t try to do everything at once; this will normally end in disaster.

I quite often find it a useful exercise to describe the app and what it should do in no more than 15 words. That way, you can focus on the core feature/s. More than 15 words, and the idea probably hasn’t been refined enough; perhaps consider splitting the features into a number of apps and build them separately.

Step 3: Find a technical solution

Always look for the easiest solution — for the user. Then work backwards.

Remember that the technological underbelly should be invisible to the user — if you’re connecting to a number of systems, don’t make it obvious. Most of our apps pool results from a number of systems through the use of clever APIs, but displays them as if they were all from the same database — a user wouldn’t even give the data sources a second thought. All they see is all the information they want, at a glance, in the same place.

Don’t try to be an expert in systems and technologies. Talk to the people who are, and work with them to understand what can be done. It is almost always a compromise — or rather, a balance — between the user, and the technology. Talk to the right people to understand what is and isn’t possible to do, and use this to consider the best way forward for a user. Always put yourself in the user’s shoes; if it doesn’t give them what they want, then is it worth doing at all? Is there a less efficient way of doing things, and if so, would an app be the best format? Would a website be more effective? Are you solving problems, or just adding to them?

Step 4: do your own research

Great! So you’ve got an app idea, and you’ve found a way of doing it. Now what?

Well, now you have to consider the best way of going about your app design, and for that, you need some inspiration. Start by thinking about user journeys, and perhaps map them out. User journeys are a list of scenarios describing a hypothetical user, and how they would interact with your app.

Analyse the app store for ideas on what you should and shouldn’t do; download and play with apps that already try to achieve your objective. Look at the reviews and see what other people think about it. Read tech blogs. Check out interaction design work on dribbble and Behance. Identify what works, but be critical — note down where you find designs that aren’t self-explanatory. Look for the simplest solutions to complex problems.

Most importantly; read the Apple HIG from back to front. This is your new best friend. Print it out, buy highlighters and those teeny Post-It notes, and mark sections with basic layouts and navigation patterns you can reuse.

Part Three: Wireframes and Prototypes

Step 5: List out primary functions

Once you’ve got some ideas, and a feel for what might work, you can begin to put it all together. Identify core features, and high-level page structures. From there, you can put together a hierarchy. Does a simple table view work better, or perhaps a split view controller? (For an explanation of terms and iOS jargon, have a look at the HIG.)

Take out the unnecessary. It might become clearer, as you begin to piece things together, that something isn’t as vital as you first thought. Keep in mind that version one should be the absolute minimum viable product. If there is anything that can be taken out, move it into next versions.

Do ensure you aim for the minimum; this means you can focus on laying the foundations for a really good app that delivers for your user and fulfils its basic requirements. You can always add new features later.

Step 6: Sketch things out

Begin to put things down on paper, or on screen. There are a number of ways you can do this; I prefer using a combination of Balsamiq and good ol’ pen and paper. Besides Balsamiq, there are a range of products out there, some free and some not, that I recommend investing some time experimenting with, including:

Even if you don’t end up using them, they should give you ideas on outlines and elements that you can put into your designs.

Use a simple structure. Once you have an idea of how you’ll move between screens, add the detail in Balsamiq — or any decent wireframing tool that creates basic images you can link together and click through. It’s halfway to a working prototype.

Once you’ve got an outline, play about with it. Get other people to play about with it. Check it works; put yourself in the shoes of someone who has never used your app before. Remember that UI should never get in the way of your user’s experience. If it’s too complicated or not obvious, something has gone wrong. At this point, try taking features out. Make sure primary functions (like ‘OK’ or ‘cancel’) aren’t too close to each other; if they are, try a different layout. Keep moving things around and playing with it until you’re happy that it does what the user might require.

Step 7: Feedback

At this point, go back to your future users and get some feedback on your sketches — remember, a user should never question what something does. If it isn’t obvious, consider a redesign regardless how much you love it. A good designer must be willing to let things go.

Keep repeating steps 6 and 7 until you’re confident it’s ready. At this point, you may wish to use a full-blown prototyping tool such as Axure, or even use Xcode or HTML/CSS to create something a bit more professional-looking.

If you’re delivering something quickly, it may be more wise to begin with development. This is quite good if you’re working alongside a development team. Quite often, we move straight into development once we’ve outlined exactly how we expect our app to function and look; this way, we can get things made much faster. It’s easier to tweak once you’ve got a first version to experiment with.

Part Four: Build and Test

Step 8: List out icons and glyphs

At this point it’s useful to make a list of all the graphics that might need to be included within the app, including a logo for the app store. If these don’t exist, draw some. I use Illustrator, as it’s vector-based, and I move finished artwork across to Photoshop to output in the correct size and file type. Whilst the Abobe suite is industry practice, there are free versions of these tools available that you can use instead.

Remember to keep everything very simple, and design for the size of the glyph or icon. This is where vector drawings are useful; you can scale them to the size you need, without the pixelation that happens when attempting to scale images in programmes like Photoshop.

Icons and glyphs can be made alongside development work, if you’re building in-house. Quite often it means you can try out a variety of glyphs to find the one that works best for your app. I output all my drawings as PNGs or SVGs but keep source files as EPS files, which allows me to open them in Illustrator and re-tweak sizes and shapes if necessary.

Another piece of advice; always back these up. I currently use Box to sync all my files. A few months ago, my work laptop was stolen, and along with it Ilost all the original pieces of art work i had created over a six-month period. It was a very sad day for me, but taught me the important lesson that everyone seems to learn the hard way; always, always, always back up your files. Always.

Step 9: Hand over to the development team

If you haven’t already, hand over your designs, graphics and (if you’ve got one) a specification document outlining how your app works. As development progresses, keep across changes and ensure you input on colours, padding, buttons, font sizes, and all other elements. If something isn’t working, or there’s a better way of doing something, then suggest tweaks and changes as the app is being put together, so you can experiment and see what they look like.

This is far easier with in-house development teams, but daily builds allow us to see how the app is shaping up.

If at this stage you have an idea to make the app better, but it is quite a significant change, add it to the list of features for the next version and review once the first version is complete and you’ve had a chance to see it fare in the wild.


Design isn’t just about the initial workload; it’s about being critical enough of the product to understand what’s crucial for the next version, or the next build. Look at elements; test the navigation to ensure it’s logical. Double-check the box sizes and outlines for consistency. Be critical of font size, touch-target size — absolutely everything. If it’s easier, pretend you are criticising someone else’s designs and look at what you’d improve.

Test again. Test even more. Just keep testing. You cannot underestimate the importance of making sure everything works as it should. It helps instil confidence from your users. The last thing you want is to hand over something to a user only to find a crucial piece doesn’t work properly — the person who will look (and feel) a bit silly is going to be you, whether you’re responsible for it or not.

Step 11: Release and engage

Once development is complete and the app has been pushed out, or you’ve put your first release into beta testing, talk to your users. See how they feel using it. If something doesn’t make sense to them, or they don’t understand something, make a note about it and ensure it’s addressed in the next update they receive. Strive for absolute design invisibility. You don’t want anyone to even think about how they’re using their phone. You just want them to do it.

Once you’ve got some notes — it’s time for the next version! Go all the way to step one, and start again!

And that is essentially it — my 101 on designing an app.

There are a lot more tools, methodologies, and ad-hoc bits involved, and designing the user experience can involve a much more immersive processes, but within our team we try and get things done quickly and efficiently. We use Agile methodology, and track progress using tools like Trello and Slack. Our process from zero to first version normally takes around two to three weeks in total.

From a collection of internal blog posts, originally published in 2014.

Caz is a product designer, currently working for the BBC. Follow her on Twitter or, if you’re that keen, you can find her on LinkedIn.