app design development and testing

Pocket App breaks down the app development process into four different stages: pre-design, design, development and support. We can take a modular approach and handle these stages individually, but the biggest value-add we can offer is taking a project from beginning to end.

With that in mind, we've created the guidelines below, to walk you through the full process, explaining what each stage is and what clients get out of it.

Pre-Design
Design
Development
Support

Stage 1: Pre-Design

Pre-design is the first stage of the app development process, where we take a project from the initial brief – whether that's one line or thirty pages – into a workable strategy. This means working out everything from what the product's about and who it's aimed at, to what technologies it should use and how we will measure success.

Pre-design makes sure you get off to the right start with the design and development of your app, and ensures a great final product.

What happens during the pre-design stage?

The first part of the pre-design process is identifying the core concept and objective of the project.

To do this, we start with a workshop. This a one – or two-day collaborative session where the clients gets to access the expertise of our entire team, across UX specialists and business analysts, as well as our senior team, who bring their thirty-plus years of experience in mobile to bear on the project.

We advise that clients take a similarly cross-disciplinary approach at this point, and bring members from marketing, legal… any department that will want to have a say later in the project. If it's an internal app, it's also a good idea to bring along someone who's actually going to be on the ground using the app.

This makes sure that all these stakeholders have a voice at the outset, rather than once the process is underway.

The workshop is followed by a research and analysis phase. As part of this, we construct user personas, which help us understand the goals and obstacles of the real people who are going to be using the app.

We also look at comparable apps already in market. This is harder for internal apps which aren't on the app stores than it is for consumer-facing apps – but by looking across industries, at apps which have very similar user objectives, there are always learnings to be found and applied.

What are the outputs from pre-design?

At the end of the pre-design stage, clients are presented with a package of our recommendations, tech considerations, and a roadmap for the project.

The recommendations lay out a creative vision for the project and how we target it at the users, and what the objectives are, from both a user and business perspective.

The roadmap includes a content audit of all the client's suggested functionality and future plans, laying out what will be included in the initial launch and plans for the first few phases beyond that. This roadmap can vary in length, sometimes stretching as far ahead as five years.

Tech considerations are where we identify the best approach for this project. We're technology agnostic, so this might recommend that, based on the functionality you need, you may actually be best with a website rather than a native app. Depending on the client, this might also include deeper details such as a system architecture diagram and data flow for APIs.

Together, this package lays out everything that both we and the client need to know about the project ahead, so we can ensure the best final results. We sometimes refer to it as 'the brief it would have been great to get the first time'.

How do I know if I need a pre-design phase?

People often think they can jump straight to the design process, but this can potentially lead to a bad final result. If the ideas are all coming from one source, who hasn't necessarily done all the research or considered all angles, then this can cause problems to develop further along the process.

Ultimately, it comes down to one question: Is your brief detailed enough that someone could go away and build the finished product? But it can be hard to know that yourself for sure. Consider whether you can answer all of these questions:

Have I established what my users want?
What's the main objective of the project?
Do I know what technologies are best to use?
What is the USP for my product? What is it attempting to fix, change or improve?
Does it need to be an app in itself? Could it be a piece of functionality within something else?
Have I looked at all of my competitors, and similar apps in comparable industries?

If you've already answered some but not all of these questions, be aware that the pre-design phase can grow or shrink to fit each client's needs.

What do I need to know before starting pre-design?

To start the process, we just need to know what you're hoping to achieve with the project.

Ideally, your brief should have isolated what the problem is, what they think mobile could do to help, and worked out a rough idea of the objective – but the bare minimum is simply knowing what the issue you want to solve with mobile.

This is often something you could write down in a single paragraph. It could be as simple as 'we lose loads of money from using a paper-based process for this thing, we want to digitize it'.

We can help fill the holes, but we need to know where they are in the first place. Once we have that single problem, we can start working to solve it.

Stage 2: Design

Once you have completed the pre-design stage and you've got the full recommendation of approach, you're ready to move onto design.

What happens if I haven't gone through the pre-design stage?

Some of our clients do start the app development process at the design stage, but generally we will still incorporate some amount of pre-design.

Sometimes, especially with larger companies, the client might have done all the user research themselves, but it's vital to ensure the concept has been thoroughly validated. Otherwise, problems can emerge further down the line. Commonly, these problems include unrealistically long feature lists; failing to break down functionality between the day one and day one-hundred versions; and a lack of research on other apps already in the market.

Most importantly, you need to make sure that the final product won't just be what you want as the app owner, but what the end user wants. With that established, it's time to start designing your app.

What happens during the design stage?

The design stage is where the UI (user interface) and UX (user experience) design of your app is conceived and iterated upon until you have a final blueprint for the developers to then build.

It's a little more fluid than other stages, because an input from one of the later steps might require going back to the drawing board to implement it. But generally speaking, we go through five steps, in this order: wireframe, concepts, collaborative design, prototyping, and user testing.

We start by creating the wireframe. This is a purely UX-based view of how the app will work, capturing the flow between screens. For example, if you have a login screen, that will also have to branch out to registration and forgotten password screens. The wireframe will show how those connect, and all the places you can go next from those screens.

Wireframes tend to be huge. They might have a hundred screens or more – including functions that aren't going to be rolled out on day one, to make sure we know how they will fit into the overall flow.

They're really useful for showing how many taps it takes to get from one place to another within the app. If it's a news app, for example, and it takes six taps to get to the latest news article – then something needs changing.

Once we've finalized the wireframe – usually through a few feedback cycles with the client – we move onto visual design, creating the first concepts. We generally take two or three of the app's key screens, and explore various ways each could be treated visually.

The amount of stylistic variety at this point depends largely on the client. If they have firm brand guidelines, it's less about color and font – which are likely to be fixed – and more about layout. If it's an entrepreneur or SME, there's often much more room to explore, and we'll often involve multiple designers to get a wider range of aesthetic approaches.

Once these screens are sent off to the client, we begin a collaborative design process. We often find that clients like different parts of each concept – the button from this one, the colors in that one – so we'll try to pull these together and refine them into a unified design, rather than a Frankenstein's Monster of various designs.

This gives us a finalized visual design, which can be combined with the UX flow to create a working prototype. This is essentially a collection of images of each screen, with tappable hotspots that make it possible to move from screen to screen as if you're using the real app. It can be installed on a device, meaning it's accessible from an icon just like any other app, and we often find that people don't realize it's not a fully-functional app.

The final stage of design is user testing. The prototype will be given to users – if it's an internal app, likely the people within the company who'll be using the real thing once it's live – to get their feedback. In particular, we're looking to make sure that users can quickly understand what the app does and access its main functions.

We use the results of testing to do a final, more educated set of revisions, before moving onto development.

What are the outputs from the design stage?

By the end of the design stage, you will have a full UX wireframe; designs for all screens in the app, possibly separate for the iOS and Android versions; and an interactive prototype, which can be installed on any number of devices.

The prototype is useful not only to give a sense of how the app will really feel, and of the flow between screens, before we've built the final product, but can also be used to pitch the final app idea – whether that's to investors, or simply selling it up the chain within your company. Either way, having a working prototype to play with makes it much easier to communicate the concept to stakeholders than a verbal explanation and a few screens.

What happens next?

The design stage ends with a clear brief that can be handed to the developers, whether that's being handled by us or someone else.

It's important that the design you end up with isn't just attractive but something that can practically be built. Because our design team is part of a larger mobile agency, we handle each project as if we were going to build it. This means keeping in mind the budget and how easy it will be to develop, considering things like where open-source elements can be incorporated to streamline the process.

What should I be considering during the design stage?

A little bit of desk research can go a long way.You can quickly get an idea of what else is out there, in terms of similar apps from competitors and in other industries, with a few searches online. This can help firm up what to expect from your own app, establish what might be possible, and identify the gap in the market you're trying to fill.

Learn to separate your opinions from your users.The design stage is where clients often have the most input. After all, even if you don't have any background in tech, everyone has a personal opinion of what an app should look like, based on their own experiences. This is encouraged – after all, this is a collaborative process – but it's also important to detach your own feelings from what the end users will want.

Just because there's a feature you like in a social media app, for example, that doesn't mean it's right for an internal stock management app. If you like a particular color but research shows it doesn't work for the target audience, then be ready to take a step back.

Consider the mobile version of your brand design.Big companies often have solid brand guidelines in place, but they might not have really considered how those translate to mobile. There are certain design elements might look great in print or even on the web, but when you put them on the smaller mobile screen, they just don't work.

To take a simple example: does your logo sit comfortably on the top bar of the device, or in an app icon? Taking the full thing – especially if it has a tagline attached – and just trying to squash it down simply won't work. We can help develop a mobile-friendly version of the logo, or work together with your brand team, if you have one, to establish what your brand looks like in the mobile space.

Stage 3: Development

Having completed the pre-design and design stages, now it's time to actually build it.

What do I need to begin development?

The design stage should have provided you with a wireframe, showing all of the app's screens and how they connect, and visual designs for each of those screens. In our case, we also build an interactive prototype to give a sense of how using the app will feel.

There is one final vital component, which sits right at the crossroads between design and development: a detailed technical specification. This takes the wireframe and annotates in more detail – how it will actually work, as well as how it looks. For example, if one screen is pulling in external data, where is that coming from? Which server is that from?

What happens during the development stage?

Fairly simply: the app is built. In our case, this is done in what are known as development sprints. This is part of the Agile methodology, and breaks development up into periods of around two weeks apiece, each focused on a particular bit of functionality.

At the end of that sprint, a build is released – normally to the client, but certainly internally – for review and testing. A Quality Assurance team checks that the new functionality is working, and that its introduction hasn't broken anything that was already there.

It's best to work transparently, so that clients can have full granular visibility on each stage of the process, and know how everything is progressing.

Once all these development sprints are complete – typically, there might be seven of them in a project – you have what is known as a UAT (User Acceptance Testing) version, for the client to test and sign off on.

At that point, it moves to RC (Release Candidate) status, where all necessary refinements are made so it can be pushed out on the app stores, or the client's website, or whatever release looks like for the particular project. Expect to see a few iterations of this version.

What are the outputs from the development stage?

By the end of development, you'll – obviously and most importantly – have the developed product itself. But we also give clients the full functional specification, and the full source code for the project.

We firmly believe that it is the client's project, not our project. Although naturally it's preferable to keep working together, this enables you to do whatever you want with the app going forward, rather than being locked in to a single developer.

How long does development take?

The full build process, to get to the day-one version of your app, is typically between three and six months long.

Anything more than that, we'd advise breaking it down and doing an early release with some proportion of the full functionality so you can start learning. And it's worth remembering that, even if this isn't the case, the day-one app won't include all of the functionality planned out during design. We capture all ideas during that stage, but as the build is typically limited by timeline and budget, some are held back for future releases.

This is helpful because, once an app is live, there is a lot to be learned from analytics. Perhaps people are using one part of the app more than you expected, and something that was intended as a main feature is largely being ignored.

This kind of discovery can inform your plans as the app develops beyond day one. You might put more resources into the unexpectedly popular feature. It might be worth dropping further development for the underutilised feature – or working to signpost it better within the app. These are considerations for the next stage, support and maintenance.

What should I be considering during the development stage?

Security is important, but exists on a spectrum
We're often asked how secure an app needs to be. The answer depends on the specifics of your project. There's no single industry level of app security, so consider: how sensitive is the data involved?

If it's a recipe app that's just storing a list of what the user has in their cupboard, it's probably not a huge concern. But if you're handling personal data, or it's an internal app that processes commercially sensitive data, then it needs to be a priority. Even if the data isn't particularly sensitive – like names and addresses, which can be accessed through other means – be aware of how your customers are likely to view it.

Dynamic functions require a reliable data source
If you want to your app to pull, for example, a list of nearby restaurants that do a particular kind of food, then you need to consider where that will be sourced from, and how you will gain access to it.

Even if it's internal data, be aware that legacy systems can provide an obstacle. They may not have been designed to handle the number of calls a consumer-based service can make; in older companies, they may even pre-date the web.

In this case, our solution is generally to build a middleware layer, optimised for communication with the app, that sits between client servers and the app itself. This will pull the data on a regular basis and then make it available to users in the app, without requiring an overhaul of legacy systems.

Understand the difference between the first and final releases
Iteration is a big part of the process. So don't expect every version you see to be fully functional. It's better to see those early versions rather than wait until the end, because it enables you to influence development while it's in progress.

Part of the Agile methodology is that, if your priorities change – which they likely will – during the length of project, you can swap out functionality on a modular basis, as long it's switching like for like in terms of complexity.

Stage 4: Support

Having completed each of the stages outlined so far in this guide, you should now have a live app which your target audience has started using. At this point you will move into the fourth and final stage – Support.

The first thing to address during the support stage is any bugs or teething issues. Regardless of how much testing has occurred during the development stage, there will always be something unexpected that occurs, from usage by a very old device, previous OS, etc. These issues need to be addressed as they happen.

The next part of support that can be planned is when major new devices are announced, or an OS update happens. Most minor updates don't cause any problems to an app, but when there are larger, more major changes, these can cause issues. It is important to ensure that when you are preparing your app development budget that you allow resource for these occurrences.

These maintenance updates are relatively easy to manage. Developers receive beta versions of OS updates around one month before they are publicly released. This allows us to plan for them with our clients and make recommendations on the best way to handle the changes or new features.

Another area where we provide support and insight, particularly for B2B or internal apps is by conducting field visits, to see how the app performs in real life, out in the wild, with its intended users.

This form of research can produce some very interesting and valuable results. As an example, we had one client who had built a QR scanner into the app, to help run on-pack promotions at retail outlets. The initial feedback we received was that the scanner wasn't working. We tested it thoroughly in our development studio and everything seemed fine. We therefore arranged a store visit and it was immediately apparent what the problem was.

The shops where these products were sold were small newsagents and the lighting inside by the counter was often quite weak. As a result the camera had trouble focusing. Gaining this insight, we were able to update the app so when the scan functionality was selected, the camera's flash was turned on automatically prior to the scanner operating.

This – literal – light bulb moment would never have happened if we hadn't seen the app being used in context.

The support we provide at the final stage moves into a more consultative role. Based on app analytics, user feedback and our own years of experience, we can produce a report of recommendations for potential updates and enhancements based on current usage patterns, which can feed into your product roadmap.

A product roadmap is something we advise all our clients to produce when planning to build an application and it is something we can help with if you've not produced one before. This document gives you the vision of where you want the app to be in a year's time. However, whilst a roadmap is an excellent resource to help guide the evolution of your app, its analytics can and should influence and amend these plans.

A final thing to consider, once the day one version of your app is live, is the frequency of product updates. A well-timed update can be an excellent way to re-engage your audience; they receive a notification on their device that a new update is available & the majority of users still perform the update shortly after it is announced. They will then invariably open the app again, giving you a great chance to speak to this potentially dormant audience.

It is however important to consider the frequency of your app updates. You need to get the balance right, between introducing new features and not overloading with unnecessary new functionalities too frequently.

When planning the support stage of an app development project, clients often want to know how much budget to allocate. In our experience, we usually find that 15-20 percent of your build cost should be dedicated to annual support and maintenance costs. This ensures you have the budget and resource available to take advantage of new opportunities, address unexpected bugs in a timely manner and plan for the ongoing evolution of the app.

Conclusions

We hope you found the outline of the four stages we recommend for any app development project useful. As you will see, it is more involved than simply having an idea for a product or service that you'd like to introduce by just building an app. However, with the right planning, processes and resource, there is no reason why your app idea cannot develop into a robust and successful solution that serves your audience, whether internal or external, for many years to come.