Have you ever thought to yourself "I have an idea for an app," and then instantly became really excited at the thought of building and releasing your own app, only to quickly realize that you have absolutely no idea where to start?
This is the experience of the majority of folks who feel they've struck gold with a great app concept. I've seen this happen to many friends and acquaintances before who have come to me looking to help, but I've always had trouble organizing all of my thoughts on this subject at the moment. This is the first of many posts that I'll be using to cover the core knowledge you need to know to create your own app. In this post, I'll go through a high-level overview of the things you need to do in order to build your idea into a fully-fledged app.
Create a plan for your app concept
The first and most crucial part of starting to create your own app is creating the plan. Mistakes cost the most the longer we wait to correct them. The planning phase is your opportunity to do some critical thinking about your app, what problems you want to solve, how you're going to solve them, and how you're going to sell your product before any time has been invested in building it.
Write your goals
To start, try and write down some of the problems you're hoping to solve with your app idea. It doesn't have to be a fancy or official-looking format, it could just as easily be scrawled on the back of a napkin if you'd like. The key here is to be able to succinctly describe what you want users to be able to achieve in your app with just a few bullets. For example, if I wanted to build a mobile banking app, my written goals might look like this:
- Let users view all their account data from the app (Balances, history, interest rates, account numbers, etc.)
- Allow users to deposit checks via their mobile devices
- Allow users to open and close accounts from their phones -- give them complete control that they would have when using the web app.
Brainstorming
Once you have a high-level list of goals, you're going to want to break that down into a detailed list of software requirements. However, before you do that I would highly recommend taking a moment to just brainstorm what features your app will need in order to achieve your goals. To do this, first just created a bulleted list of all the features that your app will need to achieve the main goals. As you're doing this, try to only think about what features your product will need to make it "minimally viable." In the software engineering world, we like to build things in iterations (or cycles), so we like to start with the smallest possible thing (the minimally viable product) and keep adding to it in small iterations to make it better.
Once you have a list of features to work with, I would recommend doing some sketching of screens or pages in your app. You don't have to be a trained UX designer in order to get value from sketching your product. If you try to make some low-quality sketches of the different screens in your app, the features on those screens, and the flows that users will go through to complete their top tasks, then you'll learn a lot about your product and you'll quickly learn if there are key features you're missing.
Writing requirements
When trying to create an app of any kind (web app, mobile app, etc.), it's incredibly important to think about and record in detail the software requirements. Simply put, software requirements are statements that specify what your software must do in detail. You can write your requirements as, you guessed it, a bulleted list. However, unlike the other lists we've made so far, these may consist of several sentences, although you should aim for them to be 3 or fewer sentences. It's important to try and write down as many requirements as are necessary for your app to be successful if only what was written was built. A good requirements document is the link between what you want to be built and what a developer will actually end up building, or what a designer will end up designing. Circling back to the mobile banking app example mentioned above, an abbreviated list of requirements like this might look like the following:
- The system shall allow the user to view all of their accounts
- For each account, the system shall show the account balance, account number, and transaction history for any date range.
- The system shall allow the user to deposit checks from their phone
- Check deposits shall utilize the phone's primary (non-front-facing) camera for taking pictures of checks.
- The system shall not save any photos of checks to the user's device or to any other part of our server than the mobile deposits API.
- The check photo-taking mode shall provide a rectangular outline to tell the user where the check must be positioned for a successful photo.
- The system shall require the user to log in for each and every session.
- The system shall allow Face ID authentication on iOS.
The above requirements are not a complete list of all the features necessary, but you can tell there's a pattern here, and I want to break that down for you. A few things you should note about the requirements above are:
- Each requirement starts with a subject (ex. "the system"). The subject is the item that the requirement refers to. In most cases, this is "the system," or "the app". However, if you're going into greater detail, you might be able to be more specific, like when I mentioned "Check deposits" as the subject.
- The second part of each requirement is an adverb like shall, must, or shall not, which is used to describe the type of requirement. If you like math or programming, you might even be able to call this an "operator" because it defines the type of relationship between your subject and the requirement.
- The next part of your requirement is a sub-sentence that will describe the requirement itself. What are you trying to define about the system and how it works? Write this down very clearly in this part of your requirement. This may be where you need to introduce another sentence or two in order to be very clear with your intentions.
- Lastly, for extra credit, you can write why this requirement is important. For example, my requirement above, "the system shall allow the user to deposit checks from their phone," could be adapted to say "the system shall allow the user to deposit checks from their phone so that users can save time and a trip to the bank in order to deposit their checks." This adds color to your requirements and allows the designers or developers who will be reading the requirements to know what problems they're solving. In my experience, the closer these types of people are to the product and your customers, the better.
Testing requirements
Once you have a well-thought-out document with all of your software requirements you might be tempted to contact a developer or learn to code yourself and start building your app immediately. After all, why waste any more time?
Well, before you just dive in, I highly recommend testing your requirements. What you've got so far will be great, but it's just a starting point. Up until now, all we've done is speculate on what we think is the best way to solve this problem. But the harsh reality is that we rarely know exactly what users want, or how they want to use our carefully designed systems. If you start building too early, you're heightening your risk of building the wrong solution.
Designing user interfaces
Okay, so we know we need to do some kind of testing in order to be more sure that our solution is right, but what exactly should we do? This is where having a UX designer could be incredibly useful. A lot of people think that software designers are only good for making pretty mockups, but the truth is that good designers are also experienced with UX research. If you have the resources or connections to have a designer help you iterate on your requirements, then that's an excellent place to start. Unfortunately, a lot of folks don't have enough room in their budget for a developer let alone a designer too.
If you can't afford a designer, you're going to half to learn how to do some of that work yourself. I'm not saying it'll be easy, or that you can do as good of a job as a professional UX designer, but you can definitely be a little bit better off than you are now by trying to do some user research (as opposed to skipping this step and doing none).
Unfortunately, I can't teach you the basics of UX design in one blog post. I'll cover this in a future post, however. For now, there are already a lot of resources on UX design on the internet, as well as free tools like Figma that you can use to start building some higher fidelity designs for your app (with more detail than the simple sketches and wireframes that we've done so far).
User testing
Once you have some designs made, you can start user testing! This is an opportunity for you to learn a ton about your prospective users and avoid a lot of mistakes early on. At a high level, in order to start gathering feedback about your app and its requirements, it's really as simple as just walking through a few scenarios with your users. Okay, maybe "simple" is the wrong word. There is really a lot that goes into conducting really effective user interviews. But you're probably not a professional UX designer, and I certainly am not either.
Fortunately, though, you can still learn a lot by designing a few flows and having users look at the designs for these flows. A flow in this context is a set of actions that a user needs to take in order to complete a goal. To conduct a test like this, you'll want to make a few flows that you feel are important to test. These should cover the core goals that your users will want to complete in your app.
When you conduct your interviews, you'll want to show the user a screen and explain what goal you want them to complete. Avoid walking the user through how to use your app. Instead, simply ask them to complete the goal, and ask prompting questions such as "how would start to do this?" or when they are having trouble ask "What would you expect there to be on this page to complete your goal, instead of what we have here?" You want to avoid leading the user as much as possible.
During the interview, pay close attention to what parts of the product are confusing, and what surprises the user or catches them off-guard. Conversely, pay close attention to what really excites your user. These are your major value propositions.
Design Iterations
Your first few user interviews might not be the best, but you'll always learn something, and you'll improve over time. The important part is distilling your user interviews into potential changes to your requirements or design. When you do this, you'll want to update your requirements document and any corresponding designs you have before repeating the process and doing more user testing. If you repeat this process enough times, you'll start to feel really good with your requirements and designs, and you can start the development process.
App Development
I bet when you read the title of this blog post, you expected to read about developing apps a lot faster. The previous parts of my abbreviated app development parts are often overlooked by outsiders to the software industry. That's why I spent so much time talking about them here. But eventually, you'll get to the point where you want to start building your app. If you already know how to code, I have a ton of resources on my blog covering how to build apps. Check out my series on building web apps from the ground up, or my blog post on the cross-platform app-building framework, Expo.
If you don't know how to code, you'll either need to learn how to code or work to hire a developer to work on your project. In the industry today, there are ample opportunities to hire remote workers to build your project. Don't hesitate to take advantage of the vast opportunities that a remote-forward world can offer you. If you do find a developer, you'll now have a great plan and means to communicator your product effectively.
If you've got any questions on this content, please feel free to contact me or leave a comment below.
