Building an app is a complicated process, there are lots of skills and specialities involved. Unless you’re a big established company, it’s likely that you will be trying to start this as cost-effectively as possible, and you will want to put a lot of this together yourself.
We have gone through the step-by-step building process that you can follow for as long as possible, but remember to seek support where you need it to get the most from your app idea.
First off you need to define your idea;
By the end of this, you will probably want to the answers to a few key questions, like;
There’s a whole host of different research options, ‘Desk’ Research, Market Research, User Interviews, Surveys and more. They all help you answer questions, some of them more quantitatively and others more qualitatively.
At a minimum, you should consider doing the following
These don’t have to be incredibly complex, but ideally, you should send them out online to people outside of your network (who might have rose-tinted glasses). This will help you gauge interest in the product, and also feedback on which features are more or less important than others.
If you have time it’s also worth doing research about the Market. On top of what products are out there, also look at;
No matter how great your idea is, if you are building it on a shoestring budget, you need to make a plan for what to prioritise.
First off, define all of your key features, some of them will be small, medium, large, or extra large. The first step is understanding;
Would you be happy with a White Label product off the shelf that you have to pay a little for per month instead of building the messaging functionality from scratch? This will save you money on the Development but have an ongoing cost that might scale with your users and have some limitations related to your feature wants and needs.
Once you’ve done this for all of the potential features, you then want to prioritise them so you can understand what is a ‘Must Have’, in version one of your app, versus something that is a ‘Could Have’
We tend to use MuSCoW prioritisation;
Must Have
Should Have
Could Have
Won’t Have
You can find definitions of how to do this from the Agile Business Consortium here.
Image: Agile Business Consortium - link.
Up until now, a lot of this can be done yourself, although it’s often much easier to do with an experienced facilitator or Product person.
As you move into the later stages of building an app, that’s when it’s really important to have domain experts involved
Design comes in a few different parts, User Flows, Site Mapping, Wireframes, and HiFi’s.
People often get excited (in our opinion) about the wrong part of this. Sure, the HiFi’s are the bit that looks great and is nice to show off, but the Wireframes are the section which really steers your app, how it will work and how people will use it
So when we say ‘Wireframes’ we’re generalising a little bit, there’s more to it than that, this is where we plan out a Site Map and some of your intended User Flows.
For the user flow the goal of this is somewhat like a flow chart, and is to look at how someone gets from Landing on your App and Site, to completing a given task.
For the Site Map, once you have completed a few user flows you can start to plan out what the navigation of your app might look like, you will be more familiar with seeing Site Maps for Websites but they are incredibly important for Apps too.
Once you’ve completed all of the above, you’ll be ready to begin creating some Wireframes. This is a really important step, this is when you will finally start to get a feel for how the app would feel to use, it’s the blueprint for your product. There should be minimal colour and little to no branding.
If you’re doing it yourself you can start out on paper, and it looks as simple as something like this
Eventually, you will want to transfer them into an industry-standard tool, something like Adobe XD, or Figma. Sometimes these are referred to as mid-fidelity, but it should still be pretty basic, and use placeholders to represent things like icons, pictures and videos, and you will eventually end up with something that looks closer to this.
Before you finish up with the Wireframes it’s good to pass it around to some friends and family to get some initial feedback. See if you have thought of all the edge cases, have you included all the screens people will land on, have you thought about modals, or pop-ups, error messages and more.
High-fidelity designs are static designs of your final website or app. Here you focus specifically on the visual aspects of the design, such as layout, colour, typography, and images to help create an aesthetically pleasing final product.
If you already have branding and a style guide your Designer should be able to create a Design System to implement this across your app, making sure to set up things like
Brand Colours, (Primary, Secondary, Tertiary), Logos, Icons, Typefaces, Font Styles (Headings, Text, Links etc)
Source: Fortnight work on Simba Sleep
Next up is the development of the MVP, version 1.0
There are some important decisions to be made here, and you might make them yourself, if you have the technical expertise, or you might leave them to developers to help you out.
Once you have answers to the questions above your Product Manager, should also have a list of Features or Epics (the major parts of the app) broken down into User Stories or Tasks. In turn, the developers will estimate each of these items, and you will start planning the work for the upcoming weeks. Some teams like to work in Development sprints, so this might be a ‘Sprint Board’ of the work that can be achieved based on the estimates, in the upcoming two weeks.
Throughout the process, there would be regular updates from the Development Team and Product Manager as they build and test functionality. In a matter of weeks, there are likely to be small parts of the project available to be tested.
As you work through a number of sprints nearing completion your Product Manager will talk to you about getting App Store Connect, and Google Play Console accounts set up to deploy the app, and set up any payment information that may be required if the app isn’t free.
Once you are happy with the product you can submit it to the app stores for approval, a process that can take up to two weeks to complete, but is usually much quicker. Shortly thereafter it will be available and ready for download.
There are loads of optional steps that follow releasing version 1.0 of an app.
You can continue to work with your developers to iterate and make improvements. A good option is to review the analytics in your app and identify users' pain points, or areas you can help your app deliver a better experience.
Other things to look into are Marketing and Promotion, App Store Optimisation, Surveys and User Research to get feedback, Customer Support perhaps getting ‘Investor Ready’, or start looking at what makes it into version 2.0.
Good Luck!
.png)
