Planning the development of your application
You just had your EUREKA! moment: you found the product you want to build. You did your research, gaged interest by building a landing page/email list (Learn more about building your Minimum Viable Audience here) and you are ready to move forward with the development of your application. You start looking for a contractor, or a team to work with to develop the first version. When you are not familiar with an industry, finding the right team or person to work with can be intimidating. You have no idea what 80% of the jargon means, you did not develop a trust based relationship with anyone yet so you always take what you are being told with a grain of salt. (That’s how I felt when I needed to rebuild the French Drain around my house. The prices I got quoted were between 4000$ and 13 000$. How can there be such a difference in prices? I don’t mind paying for quality, but I want to know why) Planning the development of your product won’t make you an expert developer, but it will give you a good idea of what the process is like, and hopefully make you feel a bit more confident and knowledgable. It will also reduce uncertainty which will result in a more precise roadmap/estimate from the teams you discuss with and speed up the development, reducing the overall cost. Let’s jump in!
User Stories
User stories are exactly what it sounds like. They are every action a user can make while inside the application. This might seem overly tedious, but it really helps while road-mapping the development of a project.
Examples:
“A user can log in the application via Facebook”“A user can create a post”
“A user can add an image to a post”
Writing down every user story will also help you visualize the different flows of your application. While doing so, you will probably notice that you forgot some things. How can a user access the settings? Should a user be able to change his profile picture? Will the user receive push notifications triggered by some event?Should a user be able to edit his post? etc. Once this is done, take a day or two and then have another look. Go over each and every one of them and ask yourself: Is this really needed for my MVP? (Learn more about building a MVP here). Trim the fat, add what you might have forgotten on your first pass and move to the next step…
Wireframes/Design
It’s now time for your user stories to come to life. I decided to merge wireframes and design in the same step because in the process of building an application, their uses are the same. The only difference is the UX (User Experience)of the end product. Wireframes can be general, barebones drawings of the different flows in your application. It gives the developers an idea of how a user navigates through the product, allowing them to use native components to build the user interface (UI) of your app. Designs are pretty much the same thing, but a lot more polished, and usually made by a professional mobile designer. A designer can help you make sure that your application offers the best possible user experience, as well as giving your company a branding that inspires trust and professionalism. We do not offer design services at App & Flow, we focus solely on mobile development and believe that we do our best work when we focus on one thing. Instead, we usually work with Dullin Jean, a designer specializing in mobile with whom we have worked on products such as Th3rd Wave, Fixit and Mule to name a few. Once you have your wireframes or designs ready, you can then upload them to a tool such as Zeplin (we love Zeplin) so that your developers have a clear idea of what has to be implemented in terms of UI.
Branding, your Domain
Kind of related to design, having your branding locked down before starting development can also be really helpful, especially if you decide to skip the designs and only work with wireframes for a first version. Having a branding will allow your developers to use colours, fonts and other aspects of it to make your application “feel” the way you want it to. Don’t get us wrong, you don’t need a full blown, 50,000$ branding from a marketing agency. Just a name and a logo can give a good enough idea to move forward. Once you have that, you can start shopping for your web domain. A web domain is your address on the web, such as google.com. Our domain at App & Flow is appandflow.com. Even if your product is mobile first, you should at least have a landing page that leads potential users to download your application. You can use a service, such as NameCheap, to look for available domains and buy them. These are important, especially if you want to have a nice, professional email to use when contacting your users or potential users, instead of a generic one.
Metrics to track (Key Performance Indicators / KPI)
Right before submitting an application to the stores, we add analytics services such as Amplitude so that you can have an insight into how your users are using the app. However, every project is different. An application for social media won’t have the same KPI as, let’s say, an E-Commerce application. We want to know what metrics we should track and aim to improve in order to grow our user base. For a social media, retention is king. How many of our users use the app two, three, four days in a row? How many of them only use it once? This is what you want to track and improve. For an E-Commerce application, we will probably want to know the percentage of users completing the checkout flow, and track it to see at what step do we lose most of them. Having a clear idea of what needs to be tracked in order to be successful is extremely important, and should be considered before or at the latest during the development.
Backend, Frontend? What?
Being in a specialized domain such as tech, we often forget that not everyone knows the terms we use. I often ask “Would you need us to work on the Backend as well?” , quickly followed by “Work on the what?”. You know when you use an application in an area where the connection is poor, you often see the infamous loading spinner? Well that is because your app (Which is the Frontend, also called Client) is communicating with your server (Server = Backend). Your app is fetching information from the server, such as the most recent posts on Instagram, your friend list or the location of your Uber driver. All of these information are available because they are being stored in a database (DB), which is on our backend. Most of available applications today are connected to a backend of some sort. An example of an application that does not have a backend would be the Calculator app on your phone. All of the logic, or processing is done on your phone. The Weather app, however, is indeed connected to a backend. Your phone by itself is not smart enough (yet) to know what the weather is like today, so it connects to a service such as Yahoo! Weather to fetch the information for a specific city, and then displays it on your screen. It is important to keep in mind that during the development of your app, there will be some weeks where you won’t *see* any changes. No new screen, no new designs, no new buttons, nothing. However, this doesn’t mean that the team is not working! It means they are working on the backend, or server, that will soon be connected to your application so that it can display pertinent information. Except if you are building a Calculator of course.😅
The goal of this article is to give non-technical founders a little primer on what to expect when working with a team to develop their mobile product. Building software can be daunting. It takes time and it’s expensive, therefore it can quickly become a stressful experience. As developers, it is our responsibility to answer all of your questions, and make sure you are comfortable with the process. By having some knowledge of what the process is like, hopefully it will make you feel a little more in control during the whole experience, making it great and exciting as it should be.
