mobile-apps, prototypingIs there a way to validate an idea of mobile app in wireframing / design stage. What would be a mobile app alternative of validation through “landing page” for other services.
Before you start, immediately search for a wire framing app that allows you to transition between screens if yours doesn’t do that already. There are many - e.g. Basamiq.
Now, the first thing you need to do is to let go of what you’re currently doing by yesterday. Just stop. There’s a genuine probability that what you have done so far belongs in a bin, so don’t dig yourself into a deeper hole by continuing while expecting a different result.
Your next step will involve you locating end-users. Try meetups, your connections, trade shows, what have you. You’ll want to schedule face to face meetings with them. (Later on you can stick to using apps or sites like opentest.co to record user experience tests, but for now you really want free-form face to face meetings as much as you can so you can collect raw, unfiltered information, straight from the horse’s mouth, complete with body language.)
Poke around with probing questions. Let them talk. Your goal is to determine how close you are to the following scenario: “Oh my! This thing that is causing us problems is so screwed up. It’s so bogging us down that we’d kill for a solution. Really? You actually have a potential solution for it? Shut up and take our money!” (Ask how much in passing and ideally get a pre-order.)
The middle ground of that same dimension looks like this: “Yeah, it’s kind of a problem, but you know… We’ve kind of been making do with it so far, and… Yeah, it needs fixing at some point. Oh? You can fix it? For that price, you say?… Cool. We’ll reach back later.” There’s a huge graveyard of startups that were working on “nice to have” solutions to problems that exist but no one really cares to fix - and certainly not at a high enough price. Pivot if that describes your app - you’ll get nowhere in the current direction.
Now that you’ve identified a problem people are very keen to pay for to solve, your next step is going to be to work out the minimum set of features that will get them to buy - the so-called MVP. Keep interacting and meeting more users until you identify the requisite set of features and your hungriest buyers. By the time you’ll know this you’ll also know where to find them and what arguments sway them best - which are useful to market your app.
I’d like to insist on that “minimum set of features that will get them to buy” bit. If your users aren’t desperate to pay for your initial set of features, you’ll end up building an MP (“Minimum Product”) or an LTBVP (“Long To Build Viable Product”) rather than an MVP (“Minimum Viable Product”). Buy is ultimately more important than minimum, but minimum will make the difference between you shipping or you going broke.
Upon having made good progress on this you can at last start designing your app. Wireframe it complete with interactions. Put would-be end-users in front and run user experience tests. Iterate on the interface and the interaction flows. Don’t skip this step under any circumstance. There’s a huge graveyard of startups who found a good problem and built something that made their end-users puke on their screens.
As you do this, put marketing in marching order. By now you should know the copy you should be using, for who, why, where, when, etc. Cook up a landing page, start building a launch mailing list, and so forth.
When the interface and the interaction flows are simple enough to use, you can finally start building your app. Continue building your launch list as you do, and give it periodic updates to keep your end-users excited. Build momentum as you near completion date by e.g. emailing your list more often, being more active on Twitter, giving early access to active promoters to an early beta, etc.
All content is licensed under CC BY-SA 3.0.