This is the first part of a series of articles we will be writing about how you should choose between mobile first, mobile only or mobile later when creating the MVP of your mobile product.
It is quite difficult today to build a compelling product without a mobile component. But when does it really make sense to go with mobile only, or start with mobile first, or skip mobile until a later stage?
Components of a mobile product
If you are going to have a mobile app for your product, eventually your product will consist of the following sub-systems that serve different needs in different contexts. Let’s analyze the components/sub-systems required to build a “serious” mobile product.
A combination of:
- web application + API + Storage, or
- API + Storage (further explained below)
is usually referred to as "The Platform".
The platform is a server-based, central location, nowadays usually running in the cloud, where most of the ‘important’ things usually happen. The platform acts as a central communication node that serves connected clients (your own mobile apps or integrations with 3rd party developers) and in sync.
The platform is responsible for many things, among which:
- durably and reliably storing data
- processing the data as going through to achieve some purpose (this is usually referred as ‘business logic’)
- making it available to humans (through graphical interfaces) and machines (through API’s)
This is the web interface that allows users to perform actions by using a web browser. In most cases, this is what you interact with after you get to the login page on a site, and most times it looks something like this http://app.yourmobileproduct.com.
Normally, this interface is designed to be used on a desktop browser (think at least 13” screen or bigger). The usage scenarios that are possible on the desktop are rarely possible on mobile devices. For example, let’s take into account importing a CSV. This is easily done on a desktop browser, but not so easily on a tablet or mobile device. iOS is particular: since applications are sandboxed, you cannot select a CSV file you may have prepared with an app.
Take note that the web application can be accessed by any web browser on any device, so this can mean smartphones and tablets as well.
At a minimum you should make sure that the web application zooms in a decent way and is at least usable if not responsive. This is the most cost-effective solution and it is usually good enough for an MVP.
A good idea is often to create the user experience and graphic design of the web application ‘mobile first’. This means designing the user interface for a 4” smartphone, where the constraints of the size will force you to keep the user experience simple, and scale out to higher resolutions. For example, on a smartphone a list of items can be displayed, on a 8” tablet the list can be made multi-column, and on a 10” tablet or a desktop advanced functions like filtering or sorting can be activated.
The API( Application Programming Interface) is to other software systems, simplistically, what the web application is to humans. So the API is a different kind of ‘user interface’. It’s a kind of user interface that machines can read, use, and talk to.
The API is an important component of your system and it needs to be designed with the same care as the web application. However, the concepts that apply to designing an API are different, because in this case a technical design is key. API development is challenging: whereas in the case of a graphical interface humans quickly infer the meaning of a message or lack of action to mean ‘error’, for the API this needs to be specifically coded in a way in which another machine can do something with.
Therefore, if in the case of the web application we would carefully design the page for displaying a certain error message, in the case of the API we have to imagine the possible error messages that might occur. Afterwards, we make sure we include them in the list of potential responses.
The API is usually accessible under this URL: www.yourmobileproduct.com/api/v1.
Storage is quite important because it enables all the information in your system to get stored durably, for later retrieval and achievement of the business purpose.
The Android, iOS, Windows 8, Windows Phone or any other mobile application that will be connecting to your platform through the API.
On par with your own mobile application you might decide to open the API to outside 3rd party developers. This means the mobile application can be developed by your team, as well as by an outside 3rd party developer.
The public website is usually a loose component that is generally not too tightly coupled with the web application, API or mobile application. The reason I wanted to bring it up is this:
- especially for mobile products it is extremely important to have a good website for marketing purposes. One of the biggest problems with mobile products today is discovery and marketing. Market places don’t offer very advanced options for making your product visible, which is why it is important to have good marketing channels outside of the app stores.
- once the product matures, you will probably want to bring information from the platform onto the public website. Instances that you’ve probably come across are: “number of transactions since...”, “number of songs played”, “over X performed since 201x”, and so on.
Product architecture strategies
The combination and extent to which you develop each of these components as part of your Minimum Viable Product depends on your business strategy. So,
- if you go for ‘mobile only’, you can probably skip the web application altogether
- if you are going to sell your mobile app only in the App Store you can probably skip the presentation site. There are plenty of highly successful products to support this strategy. The trick is that the App Store has such a good reputation that people will download (and pay for it) to see what it does.
- if your product has a very strong mobile component you want develop the API in a way that all functions of the product are made available through it
... and so on. In practice, a combination of all components listed above is usually needed.
There are two big strategies for architecting your platform and we will briefly explore the Pros and Cons of each. In a future post we will detail the circumstances for choosing one over the other and the cost implications of each strategy.
Full API support
Basically, every single function provided by your product is also available through the API. Your web application can practically run ‘on top’ of your API. From the perspective of the API, this means it will act as if it were a mobile app (for example). This strategy can open a lot of options for future development, but due to an increased effort, the costs and complexity are higher.
- High flexibility: Your mobile product can be as capable for your web platform
- Discipline: Forces discipline in adding features due to higher costs and technical effort
- Cost: Higher cost for development
- Complexity: Higher technical complexity
Partial API support
When you know for sure that in the future you will not need to have all the functions of your product available on mobile, you can decide to develop the API as a component of your web application. The big advantage here is lower cost, but it can be frustrating when you realize that even ‘simple’ functionalities cost a lot to add in your mobile app.
- Cost: Smaller cost
- Speed: Web development can go a lot faster because it does not need to be supported by APIs
- Flexibility: Reduced flexibility for future functionality on the mobile side
To be continued...
In the following articles we will explore:
- How to decide which strategy is suitable for your product
- Cost implications of choosing one strategy over another
- The risks of mobile first or mobile only approaches
YOU MIGHT ALSO BE INTERESTED IN
The Essential Role Of Trust In Product Development
As you get ready to build your product, you'll need a team you can trust to take the best possible decisions.