Planning an Application — From Idea to MVP
The most important thing to do before even writing a line of code is to understand what problem your application is addressing, how does it solve this problem? I’ve never been great at planning things, but I’ve found a sense of satisfaction when planning out a project, it gets you excited about the potential of what the end product could become. Don’t get sucked into a hole of overcomplicating things though, the idea of this plan is to keep things short and simple. The worst kind of plan is one that is bloated with unnecessary diagrams and paragraphs about what colour the background on the settings page will be. KISS (Keep it simple, stupid).
Statement of Intent
Before you open up Atom or set up a repo, have a think about what your statement of intent is. Write down the problem statement and then make a few subheadings, functionally and user groups, under these flesh out your initial app ideas. This doesn’t have to be anything fancy right now, the simpler, the better — bullet point down your ideas. If you’re finding yourself writing countless paragraphs to describe your app, start over. You need to be able to describe it simply, so that when a user asks what it does, you don’t overload them with a monologue you prepared earlier. This leads nicely on to my next point…
Once you have the above summarised, come up with a few sentences that are user friendly, something that would excite and encourage a user to go download your app from the app store or visit your app’s website. For example, I’m working on a super basic Movie/TV Review app, so I guess a user-friendly statement would be something like: ‘Movie/TV Review application that shows you all of a shows ratings, from IMDB, Rotten Tomatoes and Metacritic’. Okay, maybe that’s not going to make you rush to the app store to download, but it gives your users a simple definition of what the app actually delivers. There may be more features, but the core concept should be described in this statement.
User Stories
I like to write some basic user stories quite early on, it gives me an idea of what I want the app to achieve and allows me to break things down into features. If you don’t know what a user story is, it basically describes the type of user, what they want to achieve and why they want to achieve it. Using the same app example I mentioned above, one of the user stories I wrote went something like: ‘As an end-user, so that I can decide whether a film is worth watching, I would like to be able to view it’s ratings.’ Simple right? It just summarises a feature and why a user may want that feature, so quite quickly you’d be able to distinguish whether a feature is necessary or not. This helps tremendously with the next section, when trying to establish what exactly your MVP (minimum viable product) is.
MVP
This is the point where you cut out everything you don’t need, and then cut back some more. The idea of making your MVP is to create a prototype quickly. When building an application, it’s more satisfying to see a finished product and then iterate on top of that. If you start out trying to build the next SoundCloud by incorporating everything at once, you’re never going to see a finishing line, the idea of an MVP and iterating through versions is that you do see a finished version of that iteration. You feel like you are progressing and it motivates you to push forward, instead of getting disheartened and feeling lost in a mountain of code. This creates tighter development cycles meaning you can test features and get feedback from users a lot quicker and a lot more regularly. The other bonus is your code base is usually cleaner, ideally you’d outline the feature, write a bunch of tests that fail, make them pass one by one and, once they all pass, you know you’ve implemented that feature. Then you can iterate through the next cycle, all the while receiving feedback and minimising risk, because you’re doing things in shorter, more focused bursts as opposed to one long, drawn out sprint.
The way I approach this is to get all my user stories up and bold out or highlight which ones I think are vital for the app to function. I then do this again until I’m left with a list that I feel can’t be reduced any further without affecting the core concept of the app. This is the MVP. This is what you need to focus on building and achieving to make the app viable.
When I was writing the user stories for my movie app, I included things like having a history page of what was viewed, allowing users to add favourites, allowing them to share or recommend to a friend, all of these things are great but they are not a part of the MVP. Stripping everything back, I decided to just build a simple one page app that displayed Movie/TV show information. Through simplifying and stripping back, I was able to prototype and build the app in a couple of days, after work in the evenings. Sure, it’s dead simple, but when I add users and other ‘nice to haves’ I’ll be doing so in the confidence it’s built on a solid, working foundation. The core concept is complete and now I’m just enhancing it, one feature at a time.
Wireframing and User Flows
So you’ve got something resembling an MVP and now you want a visual representation of it. Everyone is different, some prefer pen and paper and others prefer a laptop. I’m into both, but whatever you find easy to use, use it. I quickly sketch something out and once I’m happy, I’ll open up Balsamiq (or any other wire framing software) and create my mockups. The advantage of this is that you have a working reference of what you initially imagined the app to look like. This can help if you’ve been staring at code for hours and forget where you wanted the login button to go or something stupid like that. It helps visualise your app and makes things seem more real.
Another useful thing to do would be to try and map out the simple user flows of your app. This is the journey the user takes through your app and everything that could happen at each stage. It may sound laborious, but it helps you consider things that you may not have previously thought of. I know it’s stating the obvious, but it’s good to take a step back and look at the app from an end users perspective. Think what you would want and what journey you’d take through the app to get there. At the end of the day, you’re solving a problem, you should understand that problem and the way in which you want to solve it through your app.
Technologies
The last thing you should think about is technologies and what suits your app best. Like most things, everyone will tell you something different when it comes to what language/framework is best for X. Do some research, look at similar apps and what they’re built on and see what each framework or language offers. If everything is pointing to a language you’ve never tried, so what, give it a go! Don’t stick to a certain tech stack because it’s your life and you love it. Be technology agnostic.
Conclusion
I’ve taken you through my brief process of planning an application from an idea to MVP. This is just the beginning and it’s up to you to decide what direction to go in after the MVP. The nice thing about doing things in an Agile way, means you keep your cycles short; you are only building what is useful and necessary. I’m a big believer in Agile Software Development, it encourages you to be flexible to change and to continually improve on what you’re building. If you’re interested in that Movie/TV app I was talking about, it’s currently on Heroku (hopefully moving to AWS soon), but for now you can find it here.
If you like what you read, please do follow, share and recommend!
