If you are a non-technical founder, the path from early-stage idea to a working product can be confusing. Unfortunately, it’s hard to find a clear and concise guide on how to build an app from start to finish. I tried to list all steps that are necessary from my perspective. These steps were derived from my experience working as a developer, CTO and founder of various projects and I hope they will be useful to you. I’m no expert by no means, but I’m an experimenter, and I’ve experimented with building various types of apps for the last 15 years, and this is the process I've learned.
Find out what to build.
One day you realize that you have a great idea that lits fire in your belly every time you think of it. But are you sure that this idea is worth spending time and money on? Even if you are sure, there’s no guarantee that other people will agree with you. The best way to figure out if your potential customers have the pain you want to cure is to go and talk to them.
Don’t look for compliments. You want to make sure that people are eager to commit and pay you to solve their problems. Avoid asking your friends and facility for feedback, because they won’t tell you the truth — they’ll want to encourage you and will always tell you the idea is excellent. Probably except that one friend who always tells you the harsh truth. Choose a highly specific group of potential customers and interview them in person, asking the right questions.
Things to read:
Write user stories
After you have a rough idea of what you want to build it’s time to write down the features your app will have. Your first intention will probably be to write a long list of things of things people told you during the interviews but there’s a better way — writing user stories. User stories are the ultimate agile technique to describe product functionality. Writing them down and working with them is easy.
Define your application’s features one by one from a user’s standpoint. First, you need to write a one-sentence definition in a format that describes both the function of your app and the goal user is trying to accomplish. The format is this —“As a (user type), I want to (desired action) so that (user goal).” For example — “As a user, I want to be able to log in to see the list of my tasks, so that I can check off the ones I’ve completed.”
The key is to define the stories from the user’s point of view. By including user’s intention in stories, you will share your knowledge with developers that will be building the product. It’s also easy to prioritize features based on their value for the user when you know what users are trying to accomplish. User stories should be simple enough to test features after they are built.
Things to read:
Create mockups
Though user stories are simple, writing them might be exhausting. You need to ensure that the language you are using is correct. Otherwise, you will get results that are different from what you expect. On the contrary, creating mockups is much easier since you can draw everything on paper.
Sketching your app on paper by hand is an incredibly efficient way to transition from words to visuals. All professional designers do this in the beginning, and there are a lot of templates they typically use, such as those provided by Sneakpeekit, a project created by Pasquale Vitiello. Make sure to sketch every screen of your app and don’t worry about your drawing skills — manual sketches are just an intermediate step and quality doesn’t matter here.
Once you have your paper sketches complete you can create digital wireframes based on them. A wireframe is a simple low-fidelity mockup of the interface that is quick to create and easy to share with others. Wireframes typically don’t take a lot of time to create since you don’t care about the details — there are no colors, fonts, images and layout details like margins to worry about. Your goal should be to communicate your ideas and share the general concept of the UX flow that you are thinking about. One of the best tools out there for wireframes is Balsamiq, but you can use something as simple as PowerPoint or Draw.io for that.
Things to read:
Show wireframes to customers
To present your wireframes to customers you can use one of the many tools out there, like InVision, Justinmind, Marvel or any other. They allow you to create clickable prototypes and let customers click through the app to get a feel of how things would work.
Creating prototypes is quite time-consuming and is entirely optional. I would encourage you not to do this if you have more than 20 screens — you will spend a lot of time connecting them, and people using the prototype might get confused. You can show wireframes as a slideshow and describe what interactions will be available on each screen. You can organize your slideshow by goals that customers need to accomplish and show them a happy path through the app.
Remember that your goal is to get feedback and learn. It’s easy to change wireframes and adjust the UI to customer needs, doing that at the development stage might require a significant effort.
Things to read:
It was just the first part of my mini-guide, but it covers a lot. These for parts are essential for any product and can take months to complete. One you will have the user stories and mockups ready you’ll be there will be only one step before building the actual product — writing the spec.
