“Strategy without tactics is the slowest route to victory. Tactics without strategy are the noise before defeat.” — Sun Tzu
The first post in this mini-series went over both a generalized outlook of planning a project.
This post applies methods that I use in particular when piecing together ideas for code and will be in reference to my final Flatiron project.
Coming up with the right idea is where the real heart of the vision lies. You want to make sure your idea is both viable and possible with the resources at hand. Otherwise you are bound to fail in its execution, with no pressure.
Let’s look at how this process can be approached.
Is there a gap in the market?
This is how most ideas start in business, and this applies to development as well. It all starts with a foundation that’s either hard to find elsewhere or has plenty of room for improvement.
You can also find a good starting point by finding a problem either generalized or personal and making your project the solution to said problem.
Consider the scope
This aspect has two sides. One of which is how grand in scale is the idea? You have to be realistic here and not attempt to solo a project that would benefit from a team-based approach and vice versa. The other is that 99% of dev projects will need more work to carry on the flame after the first version/M.V.P is completed. Hence, we are called developers. Keep that in mind when assembling ideas.
Directing the vision
This is where you will start to piece together the ingredients of the idea, so it all makes sense and has its own direction. If you do this well, you’ll find moments when the idea even directs itself.
How would you categorize your app? What frameworks and libraries might you need? What features are essential and should be prioritized?
As you can see, depending on the scope of your idea, a lot of thought will need to go in o this aspect of brainstorming, but you don’t have to write it all down. Provided that the vision is clearly defined, it can end up working itself out.
From this point on, I’ll apply the previous concepts to my final Flatiron project. We’ll start with the third point from above, seeing as it combines all the other concepts as well. First, let’s look at an app breakdown template that I swear by. Feel free to use this with your own projects.
Aim
Outline the vision and intentions behind your idea. This should only be a short bio describing the general direction of your project is.
Data Models / Entities
Each app will have its own outline of related data. For instance, in a To-Do List app, you may have a model for Users and a model for the To-Do Items.
Main Features
These are the bread and butter macro-functions of your app that help it commit to its aim.
User Stories
From an app user’s point of view, describe what is possible with the app and what the flow of usage may look like.
It should be described like this:
- A user can create a To-Do Item
- A user can edit a To-Do Item
etc.
Stretch Goals
After completing your MVP and your main features and successfully implementing all the possible user stories, what new features can you add to upgrade the capabilities of your app? (This is prone to change).
Considerations
Mention any parts of the project that:
- Needs to be prioritized
- May be difficult to implement or requires extra attention
- Is dependant on a library or module
(This is prone to change)
M.V.P (Minimum Viable Product)
Last but not least is our M.V.P, and I don’t mean the most valued player, quite the opposite actually. The minimum viable product is the bare-bones build of your app that includes only the most necessary aspects and features required to commit to its aim, essentially amounting to your first completed version.
Concerns -optional-
Here is where you would detail any problems you are currently having with your project and need to be addressed. Some devs prefer to have this section in a separate file within their codebase. The choice is yours.
I made this design draft in Figma. While my website never actually ended up looking like this, it was pretty close, so I definitely recommend sketching out a simple UI interface to help you stick to a design for your app.
Below is a condensed plan for my MotiveRate App.
Aim
A single-page app with the capabilities to make goals that improve personal motivation. There is also the ability to earn points through completing your actions and receiving support from peers.
There will be a focus on strong UI / UX integrations to facilitate better use of the app.
Main Features
Stretch Goals
Models
User
Goal
Update
User Stories
Considerations
Seed Profiles:
MVP
Concerns
I believe that the concepts introduced here are really all you need to make the best start possible and commit to the ideas behind your projects.
More detailed templates and action plans exist depending on the companies and teams you work with. It’s up to you to adapt your style of strategy and tactics to the methods of your work environment.
Code in Peace
Also published here.