So you’re thinking of making a mobile app…

We’ve built and launched hundreds of mobile apps for partners since 2008 (when it first became possible!), and over that time many things have changed – the power and capability of the devices and operating systems, and the ubiquity of mobile devices in general.

In some ways, things are so much better – the opportunities for sophistication in the experience we can now deliver is incredible, but it is just as difficult to deliver a great product as it ever was. So how do you go about approaching making an app in 2023?

What are the bounds?

I’ve heard people comparing the range of options with app development to cars. In other words, “it depends whether you need a Rolls Royce or a Mini” and so on. But I personally don’t think that cuts it. The variability just isn’t big enough!

I think the real analogy is actually “what mode of transport do you need”. Do you need a jumbo jet, a rickshaw, a surfboard…?

My point is that it’s actually not even always about the money (though it’s absolutely the case that there are several orders of magnitude difference in cost between those items). It’s about relevance and alignment to what you want or need to do.

What’s the process?

Let’s take a look at what actually goes into making an app.

Discovery

This is vital. Preconception is the mother of many disasters, and so the first thing we need to do is understand the world as you see it.

• What does your organisation or startup do?
• What problem are you trying to solve?
• What outcomes do you want to achieve?
• What solution do you think you need?

Explore. Refine. Reduce (always, always, reduce).

We’ve found the best way of doing this phase is by involving all areas of our team in the discussions – design, UX, development, operations, delivery.

Brainstorm. Workshop. Collaborate.

These are just words, and if you’re not careful they can be thrown around so much that they lose their real meaning. But ultimately, it’s about talking. And the reason we’re talking is so that we can answer this fundamental question:

What are your core user needs?

Going back to the mode of transport analogy. It’s important to make the point that knowing which mode of transport (or maybe even modes of transport) you need is actually (in the context of it being the process of creating an app) a specialist task.

Think of it along the lines of a very involved tour or trip to some amazing distant location. Sure, you can have a go at organising it yourself, but unless you really know what you’re doing you may well become very unstuck and be left wearing nothing more than Bermuda shorts and a t-shirt, in Ittoqqortoormiit (Eastern Greenland, population 345 in case you were wondering), holding your roller skates and hoping the next bus will arrive soon.

It’s not unheard of – but I would go as far as to say that it’s rare for a partner working with us on a product, to completely know what the best solution is for the idea they have in mind. Most people will have part of the answer, but more often than not those ideas need refining and adjusting.

The nature of change

Change is inevitable. It’s so inevitable that it’s built into the process we use to build our products. I like to think of digital product creation a bit like the ‘fog of war’ you find in some games:

You can see some areas very clearly, and you can potentially see the whole landscape to a lesser extent (and, on very rare occasions, this turns out to be accurate!), but it’s only when you actually get closer that the complete picture for that part is revealed, and it may differ significantly from your first impression.

If you are building against a fixed, unchangeable specification, then it’s entirely possible (I’d go as far as to say – likely) that you’ll get to the end and release a product that doesn’t achieve your initial requirements – that of fully solving your problem or achieving the specific outcome that you wanted.

This is the territory where products go to die, and it is catastrophic from almost every angle. Not just for you – Time. Effort. Money. But for us too – No-one wants to work on a pointless product.

The answer to ‘change’

The answer to the problem comes by approaching the process differently – it’s about prototyping (akin to having a quick look at the darkest areas of the map before you get going properly) and an iterative release cycle (we typically run on 2-week ‘sprints’ of development activity) where we show & tell the current state of reality and allow that to inform the future reality.

We’re open with problems, questions and suggestions because we want to make sure we build the thing you actually need. Effective communication is something we place a huge priority on, because without it you easily destroy a product before it’s even released.

Design

We describe our company as a ‘design-led’ agency. But what does that really mean? What is design anyway?

In a famous, oft-repeated quote by Steve Jobs, he said:

“Most people make the mistake of thinking design is what it looks like… That’s not what we think design is. It’s not just what it looks like and feels like. Design is how it works.”

It’s a great quote, but the word ‘just’ is important, and often ignored – it absolutely IS what it looks and feels like, but at least as important is the ‘how’.

For mobile apps, that is massively true. You need to consider:

• How a user will flow through your application, making sure it is easy to perform the core activities
• What interactions they will have available or use (mobile devices give you a vast array of options here)
• What experience you want to deliver at each and every point in the users’ engagement with your product.

We call this the UX (User Experience) and it’s something that provides the basis and reference point for every product we build.

Elements of design in the app development process includes things like:

• UX (the ‘how’). This may be delivered as low and high-fidelity wireframes, small interaction prototypes, micro-interactions and so on
• Devices and platforms. How does the product differ on different devices and platforms (e.g. what is different between iOS and Android; how does the experience change on tablet)
• Designs. Accurate visual representations of key screens and elements of the app. This may just be key representative screens, or it may be fully worked up across the entire product
• Brand. What is the visual language; the App Store icon, splash screen/animation, App Store info-screens and so on, what is the tone of voice of copy?

Development

Development is the wide description to include all the software development activities that are required to turn the design and UX into a living breathing reality.

But what does that cover? Quite a bit as it turns out:

• App development. This is probably the thing you first think of. Building the app so that it looks, works and feels like the design. We typically deliver ‘natively’ on iOS (iPhone/iPad), Android (smartphone & tablet), tvOS/watchOS (Apple TV/watch). There are also a number of new products on the horizon that we’re starting to experiment with too – such as the Apple Vision Pro headset.
• Backend development. This covers a multitude of elements, including APIs, integrations, cloud services and so on. In the early days of mobile, apps would frequently be stand-alone. This is very much no longer the case – almost all apps now deliver sophisticated experiences by connecting to other systems or storing and sharing content online. To achieve that, you’re going to need an API and (likely) a backend website to manage the experience or content for your user base. You also often find management dashboards and other admin-level systems that are needed for controlling and configuring the final product.
• Web app development. Not all products exist solely as a mobile experience – some will exist as web experiences too. Bringing consistency across the entire product is important to make sure users can seamlessly move between platforms without losing their way.

There will often be sophisticated interactions between these various parts – users may have more than one device, and may want, or expect, data and content to synchronise across them, or they may want to adjust some settings via a web experience and have that be realised in the mobile app. You will certainly want to consider what happens in offline states, or low-connectivity situations, and make sure users are not left hanging.

Testing and QA

This is absolutely not something you leave to the end of the process. Like development, and in conjunction with it, testing is an iterative process and covers a wide range from technical (automated unit testing, automated UI testing), user testing, smoke testing, performance testing, manual QA testing and everything in-between.

Particularly on mobile, it’s important to test on both simulators and real hardware. Simulators are fantastic and getting better all the time, but some problems will only ever show up on the physical devices.

We’ve built a huge library of current gen and older devices to give us that capability, and it’s saved our bacon on numerous occasions.

Launch

Obviously, the whole point of building a product is to launch it! However, your approach to this phase will be different depending on the kind of product we’ve made for you.

• If it’s consumer product of some kind (e.g. a product like Airbnb or Netflix etc) then there is likely to be a very defined marketing plan involving numerous marketing channels
• If it’s a product designed to be released within an enterprise then the approach will be almost certainly be very different – typically involving internal training and release management
• It’s possible you’ll want to ‘soft launch’ in a single territory, or with a defined set of users

Suffice to say, that the actual ‘launch’ bit is not something you just wake up and decide to do – it needs to be organised and planned – sometimes months in advance of the actual release.

Post Launch

When we were building our first apps in 2008, post-launch planning wasn’t really a thing. You launched, and… that was it! Done & dusted. Ad-hoc feature updates were the norm.

Consumers were so blown away by what was starting to become possible, that expectations (compared to old-style feature-phone apps!) were lower in terms of sophistication, interaction and user experience.

Those days are long gone (which is a great thing!).

Users now have a high and ever increasing presumption of products that will not only delight them, but that will continue to evolve, develop and improve over time – things like:

• Responding to user feedback with positive changes in-app
• Quickly fixing any issues
• Ensuring compatibility with latest OSs and devices
• Iteratively adding new capabilities, features and sophistication against an identified roadmap
• Refreshing the design from time-to-time to delight users and ensure adherence to the latest manufacturer interaction guidelines

Uniqueness

Of course, the reality is that every app is different. Apps aren’t cars, snowboards or roller skates. They are individual expressions of a need, with a mission to be useful, interesting or entertaining.

Or – if we’ve got anything to do with it – all three at the same time.