Building an app is a pretty exciting thing. It’s tempting to just jump on it and start coding, since it could be something you can conquer the world with.
Well, no matter how tempting it is, slow down a bit.
You need to be clear about these basic things before you start building your app. You don’t want to build something no one wants to use, right?
Which is why it requires some planning, validation and prioritisation before you even start coding.
I know, as a startup you can’t really have a road map for months (especially in the beginning), but you need to have at least concrete specifications, a priority list, mockups, and user stories for the next milestone.
In this post, we put together 7 things that you should do before coding your app.
Use these links to jump to the specific parts:
I know, it’s boring.
Everyone says this but with good reason: it’s super important!
Since everything starts from your target users, this is the foundation for your app. You need to know your target users in order to solve their real problems or satisfy their needs.
Here is how the process looks:
You sit down with your team and figure out the ideal user(s) for your app. Write down your hypotheses, assumptions and every piece of information you know about them. You can use this buyer persona template when creating user segments. But you shouldn’t stop here.
With a bunch of assumptions and user segments, the next step is to talk with your target users. The reason is quite simple: we can’t base our app on our assumptions. These need to be validated or invalidated first. These small interviews/talks help you better understand what they think and also uncover pains and needs you can address with your app.
What your users say and what they actually do is very different. You need to figure out if the problem or need uncovered during the interviews is worth taking action.
Once we have a problem or need identified, we need to dig deeper to supply a solution that solves that problem or need.
The minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future development.Wikipedia
A minimum viable product (MVP) consists only of the most crucial features. Its purpose is quite simple: test and validate or invalidate assumptions about your product.
An MVP can exist in different forms, and these allow you to test your assumptions/features in different levels.
What is the most valuable part of your app? Skip the fancy features and focus on those that deliver the key benefits. A great way to do it is by using story mapping:
Once you have the priority list ready, the hardest part is to separate the must-have features from the nice-to-haves. The end result should be a sort of roadmap containing the set of minimum features that help your users solve their most burning issue.
Chances are that your first MVP plan won’t be perfect; usually, it’s far from perfect. You need to get real users who are happy to try out your app and to give you feedback to set a validated direction for you app. See the next steps on how to get beta testers.
You should go through the process over and over again based on the user’s suggestions and feedback. If you learn quicker, you can build a much better product.
User stories are great to capture app functionality from the end user’s perspective. They clearly show what a specific user type can do with an application.
Each user story has to define the following:
But why should you care about user stories? Here are some reasons to convince you:
So what should a user story contain? How does a user story look like? Here is the structure you should follow:
Here is a template: As a <user_type>, I want <his goal> so that <benefit, value>
Example: As a user, I want to add and edit my contact details so I can keep them up to date.
Bill Wake introduced a framework that helps everyone create good user stories. It’s called INVEST:
You have the user stories ready and a prioritised list of features. The missing chain is…you guessed it: design.
There are pretty cool tools out there for creating wireframes or mockups and even prototypes for your app.
I’m sure I don’t have to convince you that creating a mockup or early prototype of your app is a must. You can easily explore and compare design variations and make design-related decisions faster than rewriting the code over and over again.
You can speed up development since your developers don’t have to spend their valuable time on figuring out the design. It’s especially useful when you outsource app development and want to make sure the app will look like and function as you imagined.
I bet, you want to follow lean and agile methodologies during the app development. It means that you have to test and validate app features. That means you have to check it with real users, your target users to make sure you’re on the right track.
Even if you don’t have any kind of application ready or in progress, you still have to start gathering beta testers for your app.
Getting users to your app is really marketing stuff, and not a tech-related thing. But here are some quick tips you can try.
There is a point when you have to decide if you want to do the app development inhouse or hire a freelancer or a software development company to do it. If you decide to outsource software development, here are the most important things you need to clarify first before you decide to go with one.
Technologies/tools they use: Always ask/research what technologies they use. Software development-related technologies and tools aren’t the only things that matter, but also tools used for communication and project management. This gives you a better understanding of their workflow and practices.
References: Does the company have any references showing that they’re doing stuff? Obviously, you don’t have to be a rocket scientist to put fake projects on a website, so here are two things you can do:
Testimonials: Testimonials from clients build trust. You can also take it one step further by getting in touch with the person who was quoted. This way, they can provide valuable information than just a few-sentence testimonial.
Time-zone difference: In many cases, your software partner is based far away from your country (that’s called offshore). Make sure to clarify how you will handle communication and when you have dedicated times for regular meetings and collaboration. Time-zone difference requires flexibility from your outsourcing partner and from your own team as well.
Idea protection (NDA): Chances are your software development agency doesn’t know your market and doesn’t have the necessary resources to make it work. You know your market much better than your outsourcing partner. Just to put a legal protection behind your project, I recommend you make a nondisclosure agreement (NDA) with your software development partner (this is what we do with our clients at Coding Sans).
Signing a nondisclosure agreement doesn’t require a huge effort from your outsourcing partner. Here you can download a free template.
Test projects: Fast results build trust. Do they offer a sample project? If they do, that’s a big, big plus. With a test project, you can see exactly how your outsourcing partner works and how the communication and coordination go. This is the best way to get the essence of mutual work. We also offer a free sprint for our clients, which means that if they’re not satisfied with our results, then the sprint is free.
Code guarantee: Does the company offer a guarantee on their code ship? If yes, how long is that period of live support?
You need to think about app engagement and retention way before you start working on it or start getting new users. Eventually, you want to create an app that people love to use and one that becomes part of their everyday lives.
In his book Hook, Nir Eyal came up with a framework that helps create habit-forming products.
The model is made up of 4 steps.
First impression is often the last impression as this image shows below.
A fair proportion of users abandon applications after the first visit and never come back. 67% of customer churn could be avoided if the business resolved the customer’s issue during their first interaction.
A trigger is when something entices your users to get back and take an action in your app. The question is, what triggers can you apply?
External, for example:
Internal, such as:
Want to make sure your app is engaging? Check out our heavy guide on app engagement.
After a successful trigger, the user needs to take an action. This is the minimum interaction to get a reward. The most crucial thing here is to make the action as quick and effortless as you possibly can.
Here are some action examples:
The reward is the why and the objective for the user.
These rewards can be:
Pro tip: Build variable rewards to scratch the user’s itch, but leave them wanting more.
Once the user gets his reward, the next step is to get the user to invest, setting themselves up for the next trigger, storing value, and creating preference. This investment can be money, time, effort, personal data, and emotional commitment.
How does it work?
1. Investment loads the next trigger of the hook: For example, you receive a new message on Messenger or a notification on Facebook (these are external triggers to get back to the app).
2. Investment stores value: Users get more content on your app, more followers, more friends or information.
Honestly, the hardest part is not building the app but rather figuring out the right thing to build.
Listening to your users carefully will help you stay on the right track. Creating user stories and prototypes (mockups) make your app much easier to understand and iterate on visual ideas, no matter if you work with in-house developers or outsource the process fully or partly.
About the author:
Tamas Torok is a marketer, helping tech companies to grow. He currently leads the marketing operations at Coding Sans and focuses on crafting high-quality, research-based content for engineering leaders. He started publishing the State of Software Development report and supports the growth of the Level-up Engineering podcast, dedicated to engineering leaders.