Getting out your Minimal Viable App
It does not have to be hard! Or does it?
This is a quick crash-course-roadmap for anyone having an App idea and thinking how to get started. Web App or Mobile App — the principles here apply to both. Are you looking to code it yourself, or give the maximum “non-coder help” to your fellow developer — it should give you insights.
Reposted in its brief version on the Trinity College Dublin’s Launchbox blog.
So you have identified a real world problem, a pain that everyone has, and have an idea of what you think can solve it and change people’s lives. Now you need to make something to show people — a Minimum Viable Product — or — if it is an App — a Minimum Viable App.
Start with the User Flow
Before getting down to dirty details, you need to have a high level overview of what your App does. The details can change as you move on. If you “invest” too much into specific implementation, your time and resources can get wasted. Instead, I found a good approach to start with the User Flow. That means:
- You need to describe how you want your App to be used.
- What are the stages your User has to go through from the start to the end?
Here are Examples of User Flows:
- Google Search: (1) The App shows the search bar -> (2) User enters Keywords -> (3) The App returns the list of results -> (4) User clicks on one of the results.
- Facebook Signup: (1) The App shows Sign-up form -> (2) User creates profile -> (3) User looks for friends/influencers and so on -> (4) Connect with friends -> (5) Read their updates to fill whatever time you have ☺
- Accommodation Search on AirBnb: (1) You enter where you go and when -> (2) The App returns search results -> (3) You click and inspect results you like -> (4) You make a booking (or leave the site if nothing good is there).
Data Exchange
All these Flows have something in common — data exchange. Your User enters data (keywords, profile, search criteria) and your App returns data (search results, friends or accommodation lists). Having decided about Flow, the next important decision is:
- What are your Data?
- What information the User should enter?
- What are the (useful) results returned by your App that make our User scream of delight?
We now have some idea what these Data are. But at the same time, we don’t want to nail them down too narrow. Also because, at this stage, we don’t really know what will work and what won’t. Shall we ask our User for the Full Name or just Email?
Or shall we force our poor User to come up with a unique Username that must have strictly between 7 and 10 characters, and even more unique Password, plus Answers to 5 security questions?
Data Objects
Whatever our Data will be, an Object is a convenient abstract way of thinking about it. For instance, the User Object will carry User’s name, password, data of birth, and whatever else we ever want it to carry. The Search Criteria Object will carry all those criteria or filters our User needs to input in order to get perfect results.
The great thing is — we don’t need to fix the exact structure of our Data Objects now! This is the flexibility we want, that will allow us to change and adapt quickly later on.
Minimal Viable Flow of Minimal Viable Data
Now it is time to revisit our Flow and Data and minimise them. After all, it is the Minimal Viable App we are after. Ideally, we choose one specific goal the App is great at, and focus our Flow and Data on achieving that goal.
So for a Keyword Search, in our Minimal Flow, the User enters a keyword in a Search bar, clicks Search or hits Return (or both), and Search Results come back. We have two data Objects:
- Search Criteria that include the keywords but can also carry more information — now or in the future
- Results Object — carrying all result Data returned by the App
What we should have at this stage, is a Sequence of Flow Steps and Data Objects used at each Step. A Step here, in the simplest case (and we want it simple!), corresponds to a Page in your App.
Page Layouts
It is now time to decide for each Flow Step, what Data is presented and how. Your Page is split into Regions, each displaying specific Data. For instance, Google Search has these Regions:
- Search Bar where you type your keywords
- The Button “Search”
- Google Logo
- Main Menu
and so on. You can see a Region as a single Piece of Functionality. The Search Button or the Logo can be moved anywhere without affecting the functionality. That makes it convenient to think of them as separate functional Regions. On the other hand, the Logo is a single Region, even if consists of several smaller elements — you can’t move those small elements around without breaking the Logo.
Functionality Regions
Each Functionality Region can be designed independently of each other, and furthermore, re-used on other Pages. A nice tool for creating Data-based Regions is provided by the popular AngularJS Framework (JS is for JavaScript).
For instance, to display User’s name in AngularJS, we can use the simple HTML Template:
<div>{{User.name}}</div>Here User is our Object representing our User, User.name is the name variable that carries the name of our User. So we can take any Object “User” that carries name, e.g.
User.name = "John"The double brackets {{}} here are used by AngularJS to evaluate expressions. Our expression is User.name and its value is “John”. So AngularJS takes the above HTML Template, and replaces the expression inside {{}} by its value. The result is
<div>John</div>which is exactly what we want to show to the User. However, we don’t want to put “John” directly into our HTML, unless all our Users are called John ☺.
This way we have a clean separation between raw Data and its Presentation. The Data is the name and it “knows” nothing about Templates and how we want to present the name. The Template, in turn, “knows” about the Data variable User.name, but is completely unaware of the actual value (like John). We can place this variable anywhere in our Template, move it around as we like, use on several pages — all that independently of the actual Data.
Then it is the job of our Framework (AngularJS) to “blend” the Template with our Data.
User Actions
We have used Templates to present our Data as we like. Now we need the User to execute actions such as Get Search Results. For instance, by clicking a button. This is also neatly supported by AngularJS:
<button ng-click="executeSearch()">Search</button>Here “ng-click” is so-called Angular Directive, whose function is to run the function “executeSearch()” as soon as the User clicks on that Button. The function can contain any JavaScript code that executes the Search. For instance, by sending a request to the server or a third party API. The request will return results that we can display to User using Templates as before.
The function “executeSearch()” is completely independent of the Template that is calling it. Again — here is a nice separation of concerns:
- Our Function “knows” nothing about templates where we use it. Its sole responsibility is to retrieve results as Data Object.
- The Template only “knows” how to call the function and handle the results (the latter can be done by another template). But the function implementation is completely hidden.
Now we can use that function anywhere and move it around, without changing the functionality. Independently, we can change the way this function works, without affecting the look of our Pages.
Servers and Databases
Sending request to Database and getting back results can become a separate venture. On the other hand, for a simple Minimal App, we may not need the full power of a dedicated Server. Services like Parse.com can be a great help to avoid all the heavy lifting and focus only on what matters — the Data.
Conclusion
If you made it until here, you now have your Minimal User Flow. Each Step in your Flow is represented by a Page in your App. Every Page consists of Functionality Regions. Each Region is a Template consuming Data. Plus, certain Regions call Functions executing actions.
On the most basic level, that is what most Apps are about. Surely, this is only a brief excursion over the tips of icebergs. Which hopefully can get you up and running faster towards your Minimal Viable App.
I’ll love to hear about the challenges your App is facing, and how this brief crash tour can be improved. Contact Me.
