Daren David Taylor



Lessons learned from the London 2012 Olympics

I’d just finished celebrating the new year when I received a phone call from a London based digital agency, the end client was Samsung, they needed to develop a mobile charity running app. as they were the official sponsor for the for the London 2012 Olympics in July.

6 months to design, develop, test and deploy an app that thousands of users will use each day is a tall call for anyone. Even a company as large as Samsung. I happily took the work on as the lead for the project. There was one thing that was clear, the deadline wasn’t going to move so we had to make it work.

I’d worked for years with teams that released apps late, trying to squeeze in features at the last minute and in general no one having an overall idea of the end goal. This really is the norm when creating apps, someone has an idea, and without testing the market they hire an experienced developer. The developer will have no full picture of the product that the founder is looking to create and the founder, often unable to grasp a clear picture gives vague instructions to the developer. What makes matters worse is if the founder has decided that she doesn’t want to understand how its made once the project is handed over it almost impossible to move forward with it.

Anyway, back to 2012 I had read the lean startup as I had been looking for strategies to improve my effectiveness in creating apps, fortunately I was in good company as the design team chosen by Samsung was a good one and had created a complete set of detailed designs and also wireframes which showed every journey that a user could take through the app.. this was a revelation to me.

In 12 weeks as the lead I went form a series of wireframes to a complete app ready to test and get the marketing machine in motion. I don’t know if it was fear of failure or just the good design, but I do suspect the design played the larger role. The app was released on time and on budget and was advertised on national media by Footballer David Beckham.

From this project onwards I’ve been fascinated in the effectiveness of creating apps, from the initial stage of turning a problem into a set of features to create an app to fine-tuning a process whereby a carefully chosen development team can be provided with exactly the information they need right at the beginning of the project and be happy and highly productive, rather than a back and forth process that causes so much frustration on both sides and eventually the costs spiral out of control.



People love their phones and apps, and each app is used in a different way depending on what its use is. Later when you design an app you will have to take this into consideration as an app that’s going to be used for 30 seconds needs to behave completely different to an app whereby the user spends a long time and isn’t in a hurry.

App use cases

  1. Demand – Typical use of a phone, on a bus 30 seconds, looking for a night out or somewhere to eat etc.
  2. Productivity – generally developed by larger companies hard to compete with, if you are gonna go down this route try to make something niche so that you can do one thing well.
  3. Entertainment – Lying on the couch, watching a video or playing a game.

What makes a successful app

  1. Solve a problem for people willing to pay money or used for promotion of another service or product, possibly a free app.

what makes a bad app

  1. An untested idea. Do not develop an app on the basis of an unproven idea.
  2. Social Apps. While many people have made money in the social space there are millions that have lost literally… millions, there are two major problems with social apps, firstly they are complex to develop. Secondly, they require traction to give value, Mark Zuckerberg managed to leverage his University to gain traction with Facebook, but to get beyond that he required major investment. Facebook did not start making money for 5 years. Thirdly as so many people have tried there are already plenty of social apps to go around.


Find a problem in a niche space and solve that problem in a way that is a simple and effective as possible.


  1. Solve a problem.

Ideas don’t sell, solutions to problems do.

  1. Consider the use case of the app in the overall design of the app.

If your user is likely to only use your app for 10 seconds at a time, you probably need to restrict it to a single screen. An app for power users to use all day will be expected to be feature rich and powerful

  1. Give the user a nice user experience.

You wouldn’t want to drive a car that while getting you from a to b had no air conditioning and the seats hurt your back.

  1. Use lists (Table Views)

Where possible present data in lists, with detail views when the user selects an item. This is the killer UI pattern in most mobile operating systems. Use it where possible.

  1. One operation per screen

Keep things simple, this isn’t an Apollo Rocket, if there is something complex that you need to design the app to do, split it into multiple screens.



In this section, I’m going to try and show the varying levels of complexity of an app and the cost to design and develop an app.

2-1-1 A Simple App

Many of the first apps on the store were really simple and in those days it was possible to make your fortune on novelty or torch apps. These don’t connect to an API or store any data and usually display information or play sounds.

If you are trying to gain brand recognition by leveraging the app ecosystem this can be a good place to start.

For example, I worked with Mercedes-Benz to develop an app that highlights features of a particular model, functionally it did nothing that a paper brochure would have apart form animating various elements of the interface.


Simple branding app

Torch app

Simple information system

Development time

7-14 Days

2-1-2. App with Device Storage

Displays existing data or shows data that the user has entered. The data isn’t backed up or synced with other devices.

With cloud-based no-API systems available such as Firebase available literally for free, it makes sense to use that technique (see synchronised data)


A recipe book

A simple note taking app

Development time

14-28 Days

2-1-3 Synchronised data

This is where most modern apps sit.

The estimate here is for a simple app, but as you can imagine apps such as can take many man-years to develop.

Development time

28-48 Days



Checking out the competition

While never condoning copying a design or style directly from another app, you can learn from the experience of others, and also spot some mistakes and pitfalls that they might have fallen into.

Best of 20

Before I even consider designing an app for myself or a client I use a strategy that I call Best of 20. It’s easy and ULTRA powerful.

First start by identifying the 20 apps that are closest to the result you are trying to achieve, for example, if your app is time management, look at to do lists, calendars, clocks, scheduling apps etc. try and get a broad range of apps that are in a similar genre to your app. If you need to when you download the app, check the category then browse for apps in that category, always use the top apps as your inspiration, not personal preference.

Spend some time on each app and write pros and cons for each of the 20 apps that you find. This will prove invaluable in the next stage whereby this will serve as a solid foundation, also anything that really catches your eye and feels like a good fit print out and paste on to a vision board.


As an app user, you will have seen many types of user interface design. What is vital to understand is that all apps are not equal, and while designing your app, it is vital to choose the correct controls to use in your app.

Apple provides the developer with a rich library of controls to use, such as lists and buttons, and where possible when designing your app unless absolutely necessary, you should try your utmost to utilize them rather than to try and invent something “better”

The reasons are many.

  1. Apple has done all of the hard work.
  2. Your users are familiar with the design.
  3. The control will be supported by apple forever and updated and considered on new versions of the operating system (iOS)
  4. It would be difficult for the developer to produce something better than apple.
  5. Any developer that you hire will have used all of these many times before.
  6. Controls such as lists can interface with the data system (Core Data) directly, automatically refreshing themselves, saving the developer massive effort.


Where possible it is suggested that if you are building an app for the first time, that you keep with just a small handful of what is on offer from the standard controls.

  1. Table Views
  2. Labels
  3. Images
  4. Buttons
  5. Navigation Bars
  6. Tab Bars

This will help in both development and in maintenance.

3-2-1 Bars

3-2-1-1 Navigation Bars

Complexity 1/5

A navigation bar appears at the top of an app screen and below the status bar. Some apps can be created without a navigation bar, but it’s generally a requirement in an app with more than one screen to show.

A title and buttons can be displayed on it and when a view is pushed a back button will be shown on the left-hand side.

3-2-1-2 Search Bars

Complexity 2/5

If you are showing a list (Table View) in your app, you might want to consider adding a search bar at the top. If the list only contains a small number of items its possibly overkill, but in general they are relatively simple for the developer to implement.

3-2-1-3 Tab Bars

Complexity 2/5

Where possible try and keep your Minimum Viable Product limited to one screen, but if your app contains distinct areas of functionality which need to be quickly switched a tab bar is the number one choice, they are super simple for the developer to implement. Try not to be persuaded by a slide-in-menu or any other custom screen switching controls which are readily available, while they might give your app a custom flashy look, they require the user to learn a new behavior but more importantly, you are just deviating away from the apple recommended practice… stick to the tab bar!

3-2-1-4 Toolbars

Complexity 1/5

A toolbar appears at the bottom of an app screen and contains buttons for performing actions relevant to the current view or content within it.

If you think you need a toolbar because you have a large number of actions on one screen try and consider splitting out some of the complexity of your screen into separate screens, or maybe hide the multiple actions behind a multipurpose button that then shows an action sheet.

3-2-2 Views

3-2-2-1 Action Sheets

Complexity 1/5

Action sheets are a great method for hiding a number of actions behind one button. This is much neater than using a toolbar for example.

3-2-2-2 Alerts

Complexity 1/5

Alerts convey important information related to the state of your app or the device and often request feedback.

It can be easy to overuse Alerts, they are designed to block the app completely until the user dismisses. I tend to only use these for destructive operations (like deleting something) for that reason.

3-2-2-3 Collections

Complexity 5/5

Collection Views arrived later in the development of iOS and provided a much-needed method to display varying sized items such as images.

Unless you think that this is a must-have in your app try and use a table view as a table view is much easier to use for the user and its functionality much more standardized.

3-2-2-4 Image Views

Complexity 1/5

An image view displays a single image or an animated sequence of images over a transparent or opaque background. Within an image view, images may be stretched, scaled, sized to fit, or pinned to a specific location. Image views are noninteractive by default but can be used as buttons for creating amazing simple UI.

3-2-2-5 Maps

Complexity 3/5

While adding a map is an easy task for any developer, be careful not to make overly complex, for example, it is possible to add pins, lines, and areas to the map. While initially simplistic they can be a real time sink for the developer. Try and limit to showing the user position and a small handful of pins at most.

3-2-2-6 Table Views

Complexity 3/5

The granddaddy of iOS controls, this is the ultimate method of displaying a list of items to a user, in 99% of cases this is the correct choice. Even if you have a lot of items to show to users they generally don’t mind thumbing through.

Don’t think that Tables are just for small lists, apps like Facebook and are all using a Table underneath and unless you really need to to do something special use a Table to display lists.

3-2-3 Controls

3-2-3-1 Buttons

Complexity 1/5

If there is an action that you need to let the user take a button is the control to use. Try and keep it to a single verb word where possible.

3-2-3-2 Labels

Complexity 1/5

To provide any noneditable text on the screen use a label, considerate selection of fonts can completely transform your app from boring to stylish.

Try and keep them short and avoid garish styles.

3-2-3-3 Pickers

Complexity 3/5

Used mainly for picking dates, a picker can be customised as shown. They benefit from saving the user from having to use the keyboard to enter a value.

Pickers are often used inline in tables and are slightly more complex to develop in that scenario.

3-2-3-4 Segmented Controls

Complexity 2/5

For selecting between a small number of items a segmented control is hard to beat, be sure to test these on smaller devices and keep the labels short on each item.

3-2-3-5 Sliders

Complexity 2/5

A slider is a horizontal track with a control called a thumb, which you can slide using your finger to move between a minimum and maximum value.

Useful for use as volume controls etc.

3-2-3-6 Switches

Complexity 1/5

A switch is a visual toggle between two mutually exclusive states—on and off.

3-2-3-7 Text Fields

Complexity 1/5

A text field is a single-line, fixed-height field, often with rounded corners, that automatically brings up a keyboard when the user taps it. Use a text field to request a small amount of information, such as an email address.

3-2-4 Conclusion

If you are thinking that it’s going to be difficult to design a unique interface with these controls, that’s actually a real positive, you can create a stylish design by changing just a few colours and some smart typography, with a little branding the app will look great, respond well and the users will love it.

Take a look at the Apple contacts app, it’s a pretty bland looking app, and uses a small handful of controls and has been unchanged over the years, it represents the Apple design paradigm, easy to use and clean. If you are relying on a unique experience to gain traction you might be disappointed in the response from users and the time and effort required to design develop and maintain it.


The Trade Event App

I’m going to walk you through how I would create a wireframe for a client.

The app is going to be really simple but will show how complex such things can be once you drill down to the details, which are usually not discussed until development has started which can be really expensive at that point to make changes if required. I will stick to using the stick iOS controls and ill explain why each has been used.

The use case of the app is for a trade show organizer to list their events in an app and to allow the user to browse them, show details, share on social media and to book tickets.

I’m not going to go into details about the technicalities of this app but it would best likely require a server developer to create an API or but could also be done with by an iOS developer using a service such as Firebase.

3-3-1 Launch

Every app on an iPhone has a screen that is shown while the app is loaded. Some apps show an image that looks like their app when it’s been loaded which makes the app appear quicker to load.

For simplicity its often best to show the name of the app with some branding, on the latest devices this will be shown for 1-2 seconds max.

3-3-2 List

The main purpose of the app is to show the users which events are available, that’s why we will make the centerpiece of the app a Table View but we can call it a list.

There is no better UI component to use than a list, and simple text in a stylish readable font will be most beneficial. Remember to not try and be a trendsetter, it’s to no advantage at all to users that are using your app for value.

3-3-3 Detail

We deliberately kept the List screen of the app focussed on showing the list of events, when the user taps on an event (denoted by an arrow) they will be taken to the detail screen using a push transition. From the detail screen the user can do any of the operations they might want to do such as Share, View Map, View Floorplan or Buy tickets. Notice how that all of those operations take the user to a completely new screen. This is an utterly vital design pattern to use. Focus each screen on one thing only, this way its easy to design, easy to use and easy to code….. easy!

3-3-4 Share

Apple was kind enough to give the developer a share sheet to enable us to share things on the various social platforms. Unless we want to do something very specific (like edit a photo before it is shared) its best to just use the standard Apple methods. It’s very easy for the developer to incorporate and as new services are added by Apple such as a new social network, we will be able to take advantage of them with no extra effort.

3-3-5 Map

The user can see a map on the Detail screen but by tapping on the map the user will be pushed to the map screen, again, extremely easy to implement. Just one push pin is needed to be added by the developer. By turning on the ‘shows on position’ on the map by the developer the user will be able to see their own position. As an addition here its very easy to add Apple Transit so that the user can get directions by car or bus etc. But I would leave it out of this first version as we need to get v1 into users hands with as little delay as possible.

3-3-6 Floorplan

Here we are just showing a larger view of an image that is shown on the detail screen. Its as simple as that, just an image provided by the API.

3-3-7 Buy Summary

Before the user is sent to a purchase screen it’s always nice to show them a summary of what they are buying, this gives them a chance to say no, and they won’t feel like they are being thrown directly into a payment screen.

This screen is very simple being just the full title and full address, and possible phone number/website etc.

There is an opt-out button and the Pay now button.

3-3-8 Payment

I have used a modal transition here, that means that it appears from the bottom of the screen, it gives a more formal feel to the process and we don’t really want the back button to be on the navigation bar (which would be the case with a push transition)

Unless you have a VERY good reason not to, at the early stages of an app stick to using a payment provider such as stripe, integration of stripe for the developer can often take as little as 30 minutes, with a little more time required for the founder to create the account.

There is no UI for the programmer to develop here, again, like when choosing only to use the built-in Apple controls, by using Stripe when Stripe update their services you get all the changes for no developer effort.


You can see how every button on the app (apart from the back button) has been connected to an arrow and the developer can now see exactly how the app is to function.

Now when the developer sees this they will know every scenario and have no reason to misunderstand your requirements.

Additional Benefit

This wireframe can now be used to go back to your customers to validate your idea. They will have a far clearer understanding of your offering once you organize your ideas and create a Wireframe as we have here and it doesn’t take that long at all using the correct tools.



To get a clear understanding of a Wireframe ill show an example of an app that I specced for a client in 2014 for a kids social app.

The awesome thing about Wireframes is that there is no strict standard, the key though is to ensure that YOUR thoughts are passed on to the DEVELOPER or CUSTOMER.

It is then possible to show the customer to iterate on the design, or to give to the developer.

Login Flow





Sometimes it can be useful to show a client a few options that are available, it allows you to take a direct comparison between different implementations.

This is really nice to do with wireframes, it saves a lot of of development cost doing any design iteration during the wireframe stage.



You might have heard words such as coding, development, and programming and wondered what it all means.

The good news is that you don’t really need to understand what it means, just that its all the same thing, its the process of creating the app.

If you have done a good job in creating the Wireframes a developer will be able to take them and without too much involvement from you, build your app.



  1. Wireframe review

Ideally, you will be able to hire your developer to help you with your wireframe, if that’s not the case when you do hire your developer make great effort to go through each screen and action on the Wireframe with the developer to ensure that she understands everything to the last detail. Time spent here will pay you back 10x and the developer might offer suggestions or shortcuts.

  1. Development

Depending on the complexity of your app this will take anywhere between 2 weeks to a few months. Try and get the developer to give you a daily build (suggest an automated process for the builds) this will help you see progress and spot any deviation from the Wireframe.

  1. Fixing bugs

This will be an ongoing process but you will possibly see that towards the end of development this will become more frequent. Try and understand that this is a completely normal part of creating an app, and don’t try and lay blame on the developer. Bugs can be the fault of the developer but are often due to problems with iOS or a third party library, so try and understand, but it is possible that you just won’t be able to understand and might just have to sit back and let the developer do their job. That’s why it’s vital that you find a developer that you trust or has been recommended to you.

  1. Deployment

The final hurdle has arrived. If you have followed my advice on using standard iOS UI patterns where possible and you app is responsive and bug free your submission to apple will almost certainly go through unchallenged.


As in any trade, when hiring a developer you will realize the vast diversity of skills in this field.

It’s also a very closely knit community which might seem a little difficult to penetrate.

You will have the most success using linked-in you can simply post a job offer, however, this generally results in an oversupply of low-skilled offers, which you would possibly find difficult to select from.

A better technique is to network within the industry, Try asking around in the founder and CEO forums for recommendations of developers from founders whose app you know and trust. Try and be specific in what you are looking for, that is a developer who is capable of creating an app from a series of wireframes and manage her own time.

With regards to rates, paying low will get you low-quality talent, and given that you won’t be able to offer technical guidance that’s possibly not the best choice.

A lesser skilled developer will also take longer to complete the job, often many times longer.

I recommend that you just choose the person that impresses the most and ask what her rate is. It’s just the same as if you are looking for a builder to work on your house, you can try and negotiate a little but remember that these guys are highly skilled in a very technical discipline.

I am freelance UX and Developer for iOS apps
UK: 07590 216276

Previous articleStandard Controls Content


Please enter your comment!
Please enter your name here