I often hear from friends who have an idea for an app, but aren’t software engineers. They want to know how they make progress without having to learn a whole new set of technical skills or fund a development team. They know I’ve worked at Apple and Google, and built my own app for Jetpac, so they’re hoping I can offer some guidance.
Happily there’s actually a lot you can do before you have to dive deep into engineering, so here’s my step by step guide. This based on the process Cathrine, Julian, Chris and I followed at Jetpac, so it’s actually the same process I recommend even if you do have engineers!
Powerpoint
The hardest part of the development process is figuring out what your app should do. This may be hard to believe when you’re staring at a mountain of technical challenges, but understanding in detail how your app should behave is essential to getting it built. Changing the requirements once you’ve partially built it will cost you a lot more time than you expect, so trying to get as much feedback from users as early as possible is key.
The quickest way to start is to begin a new Powerpoint or Keynote slide deck. On the first slide, put a rough draft of the first screen a user will see. Don’t worry about making it pretty, just put in words for all the buttons a user can press, and any welcome text. If you want to get fancy, download blank iPhone graphics from Apple and put your content inside those frames. One the second slide, put what you expect the user to see after they’ve taken their next action. This can be a whole new screen, or just some change in the first screen. Keep doing that until you have at least one example ‘workflow’ showing the screens someone might see if they use the app for one session.
Now comes the most painful part. Find someone who you’re hoping might want to use the finished app, who’s part of your target audience. Try to make sure they’re not a close friend, and if you can don’t reveal it’s your app, what you want is as honest an opinion as possible. Start off by asking them if they’d be interested in downloading an app for ‘X’, where ‘X’ is your short description (e.g Instagram could be ‘an app for taking artistic photos and sharing them’). If they say no, or seem unenthusiastic, you’ve either got a problem with how you’re describing the app, they’re not actually part of your target market, or you need to rethink what your app does. If you can’t pass that basic test with at least one person, you will not get any downloads!
Assuming you’re at the point where your description has them interested, show them the first screen, and then walk them through the day in the life of the user like you’re telling a story. Have them ask you questions as you go about anything they find confusing and make notes. At the end ask them if they could see themselves using the app?
Once you’ve done this with a few people, go back to your description and Powerpoint slides, and try to address the problems that came up with new approaches. Then go back and do it all again with new people!
Don’t expect to get positive answers to any of these questions at first! It’s almost certain that you’ll have to keep repeating this process for weeks or months until you’ve truly understood what your users are looking for. Don’t feel like you’re being dumb, everyone has to go through this pain, and in fact not having an engineering background helps you because you’re not tempted to spend time writing real code that’s solving the wrong problems. Learn as much as you can from your users as early as possible, and you’ll get to a successful app much faster.
This is a trick that Cathrine and Julian came up with, so I can’t claim the credit, but it worked very well while we were prototyping Jetpac. The app was all about showing people gorgeous photos, so once we’d got through the slideshow phase, we needed a prototype that didn’t require much engineering, but looked really good, or we wouldn’t be able to gauge user reactions very well.
PDFs can contain links to other pages, and so by creating a series of screens as individual pages and having button images link to different ones, you can fake up a very attractive simulation of your app where users themselves can actually tap to make things happen. There’s obviously a lot of limitations, but if you create the PDF and then run it inside a PDF viewer that supports full-screen and links on a phone, it works surprisingly well.
How much visual design effort you want to put into this stage depends on the audience for your app. If it’s a utility and doesn’t have to be pretty, then you can mock up the PDF yourself even if you don’t possess any artistic skills. Otherwise, you’ll need help from a graphic designer. The good part is that you will have a good set of requirements from the Powerpoint process. You can hand over the outlines of the screens you need and then ask for what you need improved visually.
This is the first step where you may need to spend money on a professional. You can try to get away with a cousin who knows Photoshop, but you’re likely to get what you pay for. My recommendation is to either accept that it will be ugly and do it all yourself, or hire a proper freelance graphic designer and be prepared to pay their usual rates.
Once you have a PDF running on a phone, try handing it over to potential users and watch what they do. One approach we used was to put the phone flat on a desk and have another phone in a clamp recording video from above. We’d ask the person to describe what they were seeing and thinking as they tried to navigate the app, and then all watch the results afterwards to understand what did and didn’t work, and what confused people.
This is another stage you should spend as much time on as possible. Fixing problems now is far, far cheaper and faster than once decisions are baked into code.
Mobile Website
Wait a second, isn’t this a guide to building apps, not websites? You’re right, but I actually recommend prototyping using the mobile web as an intermediate stage to help you design your product. It’s much easier and cheaper to find web developers and designers, there are much better design tools, you can actually do a lot of things yourself with minimal technical skills, and the development environment lets you get things done much faster. There’s also very few technical things that you can’t do from a website on your phone. You can even take photos, grab GPS locations, and run advanced WebGL graphics in a mobile browser these days, and most of these features work across both iOS and Android, so you don’t have to develop different apps for both operating systems. The main downsides are that you don’t get native buttons and other UI elements, and things like page loading and animations can easily look bad.
Depending on what your app needs to do, you can try a variety of different approaches to development. If it’s a fairly simple set of content that you want people to be able to browse and search, you can even use an off-the-shelf website builder like Wix, Squarespace or WordPress that has good mobile templates, and just create the pages you need yourself. For anything else, you’ll need some engineers and designers to help.
The good news is that you should have a very clear idea of what you need after going through all the prototyping, so you can present a project with a very well-defined scope to any teams you’re evaluating. Having a good set of requirements will help them come up with realistic cost and time estimates, and greatly increases the odds that it will actually be completed on schedule and within the budget. Hiring and managing an engineering team needs a whole different article (or maybe even a book) to do it justice, but they key points to remember are that changes in requirements have way more impact than you can possibly believe, and you should expect to see work in progress at regular intervals, don’t let them ‘go dark’ for too long.
There will be two main areas of engineering effort. The backend is all of the cloud-based work you’ll do on servers, using something like Amazon EC2, and which holds all of the shared data for your app. For example, this is where all the photos for Instagram are stored, and all user account information. The frontend is the user interface that people see, so it includes building all the buttons, text and screens that make up the visible part of the app, and the Javascript code that uses an API to store and retrieve information from the backend servers.
Again, try to get whatever you have into as many users hands as possible, to catch any problems and improve things as early (and cheaply) as you can. I’m a big fan of UserTesting.com, since they were able to get the app to users almost instantly, and get us a 20 minute screencast video of the testers using the app and describing what they saw and thought, all for around $40 a session. The feedback we got from that was invaluable.
PhoneGap
Once you’ve got a basic mobile website working, you can use the PhoneGap tool to wrap it in native code so it can be downloaded from the app store and installed just like a fully-native app. This may seem like a cheat, but it’s possible to polish a mobile website until it feels very smooth and native. We were even featured by Apple, despite our app using this approach, since we worked hard to make everything feel ‘native’. It does require a lot of engineering and design attention to detail to get to that level though.
Native Development
I would only consider native development once you’ve started to get real traction with the faster and cheaper approaches I’ve outlined above. It’s still a major engineering effort to support two different operating systems, development will be slower, and you’ll need more specialized engineers and designers to handle the work. You’ll also be a lot slower at shipping updates, it’s tougher to get statistics on how people are using your product, and techniques like A/B testing of changes are much harder to do.
Anyway, I hope you find this guide useful. If there’s one thing I want you to take away from this it’s that you can make a lot of progress without writing a line of code, the first and hardest work you’ll do on your app is figuring out what users actually want!
Pete Warden's blog 