Wondering how to make an app? Let's start with the MVP, or minimum viable product. Fundamentally, the MVP is the most basic product that you send to market which will test your idea. However, when you're building an MVP, it's hard to know where to start. First thing's first. You'll need to validate.
Validating your product
It is important to ask yourself a series of questions to understand the assumptions you've made, and then see if you can test those assumptions with your market.
Who is the customer (market)?
Why do they need the product (perceived value)?
What is the product (definition)? Do our users even have smart phones? Do you need a mobile or web app?
The truth is that unless you have endless cash to burn, it will be very hard to validate your product - projects fail not because the idea wasn't good, but because of other factors like it not being marketed to the right audience, not having a large enough market fit, not having the right messaging, etc, etc....That doesn't mean though that there aren't things to validate. For example, it's easy to validate your addressable market size. And the questions you should be asking yourself are: Is your market actually big enough? and does this market need what I'm building?
Another common problem with a lot of apps is that they fall into the "feature app" category. A good litmus test to see if you're contemplating building out a feature app is to see if it can easily be tacked onto an existing product.To some extent, there's a bit of faith that goes into making a product, and certain assumptions are needed to move forward, but at the end of the day know that it's easy to validate an idea, it isn't easy to validate a product.
While you can use current systems such as surveys, prototypes, or focus groups to help out with that creeping insecurity, they aren't answers, they're really more like guides to idea validation. In addition, users can have a hard time explaining what it is that's wrong or right with your app, and even if they say its a great idea - the "Heck I can't wait to use this!" - just doesn't translate from prototype to real world. What it does let you know is if it's a concept worth pursuing. So what can you do? I generally recommend speaking with consultants or doing some research to better understand the startup landscape as well as your specific market. Though overall being an entrepreneur is fraught with uncertainty, and if you can get other people to believe in you and follow you, that says something about your market too.That said, while execution is entirely what makes a business successful or not, initial validation can prove whether or not an idea has legs.
Define your strategy
Every product has stakeholders and their needs should be accounted for, even if that's only you. Is the goal to make money right away? Is the goal to acquire users? Is the goal to have 2 thousand conversions per quarter? How will you determine success of the product or implementation? What tools, marketing techniques, and product strategies are you going to use to on-board users?If you're building a product that lets users print their cat photo onto muffins, and then mails the muffins to the users - maybe create a portal for users to share those photos, or let them share their creations with friends through social media/email. The money is still only made in the printing and mailing, but the sharing and community aspect allow new users to be drawn in. These all need to be considered and then implemented into initial scope. Also remember that you won't be able to do everything all at once, you are constrained by both time and money. Defining your strategy is about prioritizing what comes first and what scenarios it can then lead to.
Create Information Architecture & Define Scope
People often mistakingly believe that once you've validated your idea the first thing to do when designing your app is to start with wireframes. While a common misconception this can also kill your customer experience.What information architecture (IA) does is it beings to break down the function and capability of the app. Is there a login? Once the user logs in what actions can they take? If they take action #2, what happens on their screen, what happens in the database, are there any emails sent? With IA a map is created that defines these rules - no layout, no design - just a series of actions that can take place. A developer could take this map and begin to create the product, most of the answers are here.
Design for the User Experience
User Experience (UX) is the humanized layer. This is where we create wireframes - visual maps of the information architecture previously defined. But since we aren't systems, and not always logical as people, this is the moment to infuse empathy into the app. With UX we re-wire the IA logic based on a different set of logic. For example, you really want your user to click the "sign up now" button but the UX designer understands that not everyone will do so, so they've also added a "learn more" option next to it. The UX designer at this stage should create a weighted hierarchy that "pushes" users to immediately register the first action as more positive and the second action as a backup that's a safe alternative.
Align your Visual Design with Brand
This is where the brand, the style, and the vision are infused into the product. It's also another chance to see what's working and what's not working. Mood and sensibility is created at this stage. This is more than 'just a skin,' or at least it should be. This is the area where specific goals are executed upon. For example, the Über mobile app blurs the background of their app when a user is typing in information. This helps the user focus on their immediate task. It is a very important design choice that creates a comfortable app experience, in turn resulting in a positive brand experience.Don't rule out the significance of visual design (said the designer), even with something as simple as changing colors around to pop certain actions more - this can greatly enhance user conversion. We had a client for whom we changed the color of a button from red to green and saw an increase in clicks by two-fold. (As a soft rule I'd recommend staying away from red buttons.)
Build It a.k.a. App Development
It's not really that simple. One of the main concerns here is in scalability and future add-ons. There's two ways that the development team can approach the build - the startup approach, and the enterprise approach.
A startup approach requires a product that is meant to be an MVP. An app that is created to validate a product market fit. This type of approach requires developers to be able to change courses quickly, rapidly iterate, and "patch on" new aspects to the product when they are required. The assumption is that the core will eventually be re-built from the ground up once the product is validated and funds are raised. This is the quick and dirty approach, but even here it's incredibly important that your app does what it's supposed to. Just because it's a startup approach doesn't mean there's room for bugs or certain things not working as they should.
The enterprise approach is concerned with long term health of code and scalability. Developers do not need to rapidly iterate but focus on building strong foundations and architecture. This takes much longer to do and results aren't immediately seen.MVP's are built with the startup approach, and this makes sense. There's a huge price discrepancy depending on how a system is architected and built, and it doesn't make sense to build out a healthy scalable system when you don't know the success of the product.Let your developer team know your priorities, and more importantly, which aspects could be compromised on, but if you choose to go the long-term route, don't be surprised with price tags consistently above the $200k mark.
Remember that strategy we discussed? Well, if you listened and implemented it, then the marketing will follow along with the original strategy. Marketing is the stage that moves you from no one knowing about your app into a healthy stream of user growth. There's two main aspects to this, inbound and outbound.
Inbound focuses on analysis of the product performance through user acquisition, user retention, and user conversion through funnels like a contact form, signups, social media, etc. Once your product is out, it requires constant monitoring to see the user flow in action and optimize for product goals. Depending on the specific situational needs, the marketing aspect determines where and what to optimize for the full user acquisition opportunities.
Outbound is focused on understanding the target audience and how to engage them with your product, it is a precise effort, focusing on the ideal users or institutions who can help propagate your systems use. This is closely related to sales.
Congrats, you've made it and your product is now in the market - thats so cool! But now you must ask yourself, how is it performing? Did you or are you AB testing? Are there blocks in the funnel? Are you collecting analytics? Are users coming to your site but not converting? Did you meet your business goal? This is the moment to re-assess and fix any false assumptions - this is the moment to really test if it will work, by having actual users. And if it does? Congrats! Time to re-build and start the process over again.While the process of how to make an app isn't a science, there's definitely a methodology to it. Following the path laid out here will help you stay within budget, and place you on target to a successful application.