An App From Scratch: Part 1 – What To Build

10 minute reading time; ~1700 words

---

Hello and welcome to my series on designing an app!

After spending a few months working on a business plan, I’ve gotten to a point where I have a stack of text files full of data, and they’re getting to be a challenge to manage. Now, it’s time to build the tools to make my job easier, and maybe help someone else along the way. At the same time, I figured I could teach some of the process behind designing and building a customer-facing product.

The steps we’re going to go through in this post are:

Vision → Goals → Objectives → User Stories → Requirements

This process is a guide, not a rulebook, so feel free to adapt it to your project’s needs, and don’t be afraid to change goals or requirements as you learn more about what your project is. If you’re feeling lost in the details, don’t forget to just focus on solving one problem at a time. Every step builds on the last one, so as long as you follow along, you should have no trouble getting to a workable set of requirements.

Without further ado, let’s get started building my business planning tool, Tailgunner!

Note: You’ll find project related content listed under headers that have a red background, separate from the explanation of the content itself.

Setting Vision And Goals

The first and most important part of any project is knowing why you’re doing something, and where you want it to end up.

You should always start off with a vision and goals, but don’t feel you have to be rigidly constrained by them as you work through the next step of figuring out requirements. If as you go along, you find a requirement that doesn’t align with your vision or goals, but is truly part of what you need the product to be, you should come back to the vision and goals, and adjust them.

Below, you can see the initial vision and goals that I’ve brainstormed. As well, some of the goals are listed as stretch goals, meaning we’ll try and achieve them if we can, but they’re not critical to our initial success in the project.

Project Vision

Project Goals

Translating Goals Into Action

Now that we have a vision and some goals, it’s time to work out what we want to do to make them happen. We’re going to start with the first goal, and break it down into some objectives, the concrete measures that will guide this part of the project.

Goal: Reduce the amount of manual work required to create and manage data.

I currently have a dozen different files that contain data, research notes, and other pieces of information related to my business plan, used for planning and analysis work. Given the amount of work needed to generate this data, as well as some of the challenges to adding new information types, this is a key point for the tool to address.

User Stories

Now that we have some objectives, it’s time to write user stories. Serving as the bridge to requirements, user stories break down an objective, explaining not just what should exist, but why it should.

User stories also serve to communicate desired functionality in a way that all stakeholders in a project can easily digest, enabling better collaboration and understanding of the desired result.

In larger projects, you would define user profiles to go along with each user role, but in smaller projects, or MVPs, you can get away without them.

The usual format for a user story is: As a [user role], I want [feature or action] so that [goal or benefit].

Along with user stories, you should also write some acceptance criteria, which define what needs to be completed to say that a user story has been implemented successfully, from the perspective of the user. These acceptance criteria guide feature plans, detailed requirements, and testing plans.

Objective: Implement templates or predefined forms to standardize data input.

Here we assume two different user profiles, a business owner and a user. The business owner is the person who owns the business, and the plan, and the user is either them or someone who has been granted access to work on the plan.

With these user stories, we’ve started to paint a solid picture of what the user wants to be able to do, and what matters to them to be able to do it. From here, we have anchor points to help us define what we actually need to build, in concrete terms.

From User Stories To Requirements

We’ve spent some time now working through the process, to get to this last step. Where the user stories define the what of the objective, the requirements bring it finally to the how we want something to work specifically, to bring our vision to life.

User Story: As a business owner, I want to create a custom form template based on my needs so that I can capture specific data unique to my workflow.

Validation And Prioritization

Throughout the whole process, you should be working closely with any stakeholders in the project. For something this small, you might be the only stakeholder, but for larger projects or companies, you may be part of a team that involves business users, external users, product, design, QA, or other people and departments. When multiple people are involved, you should be working towards a state where the requirements are well defined, but also validated with stakeholders.

Your quality of work is determined by a triangle of cost, scope, and time (the project management triangle). You can only ever choose two of these factors when picking what you want to deliver. That’s a whole topic in itself, but the basics are:

• Cost: The resources or effort you’re willing to invest.
• Scope: The amount of work you want to accomplish.
• Time: The duration available to complete the work.

As an example, if you prioritize scope and cost, then you may need a longer timeline. However, if you want it done fast, you’re going to have to sacrifice by either having a higher cost or a smaller scope. Every project is a balance of these factors, and they ultimately help inform the prioritization of the work to be done.

Once you have a list of valid user stories, prioritization can usually take place, though that’s not a process that’s complete until you’ve completed your requirements and come to an agreement about the amount of work you want to take on. Even then, it’s something that will continue to be re-balanced as the overall project continues, and the understanding of what’s important changes and evolves.

Wrapping It Up

So, this is the basic process to figuring out what you want to build. Depending on the size of the project, and number people involved, this can be a very short or very long task, but it’s always important.

In this post, we worked on the foundation for building a project. We established a vision and goals, and went through the process needed to develop actionable work, giving us a clear path to building something.

Before the next post, I’ll be writing a more detailed document, which I’ll share at the beginning of that step, to give you an idea of how a full spec can look.

In the meantime, what tools have you designed, or what challenges have you faced when managing projects? Leave a comment below!

Thanks for taking the time to read this, and stay tuned for the next part: wireframing.

Cheers!