An App Design Document (ADD) is meant to detail the objective, audience, experience, technical requirements, and development milestones for your app.
It is a living document. You should be changing and tweaking it at least twice a week.
Once you have made an ADD, it becomes much easier to visualize everything you have to complete to get your app done and you will be able to keep track of your progress.
Whenever you decide to change some aspect of your app's design or development schedule, make sure to update your ADD!
Use this link to create your iOS app project repository.
In the repository, you will find a document called ADD.md.
There are five main sections: Objective, Audience, Experience, Technical, and MVP Milestones.
Inside of Technical, there are four subsections: External Services, Screens, View/View Controllers/Classes, Data Models.
Inside of MVP Milestones list each remaining week of development.
Time to start writing your ADD!
Explain the purpose of your app in 2-3 sentences.
A simple example:
"PlaceholderName is an app that lets friends send each other photos and videos that are deleted after they are viewed."
This is where you explain what kind of people your app is targeting. What age range, interests, background, etc... characterize the users you expect? How much time and disposable income does this audience have? In what circumstances during the day will they use your app?
Fill in the first 2 subsections here. We'll return to the others later.
External Services: What APIs or external services will you use when making your app?
Screens: Describe each screen in your app and how you get from one to the other. Are there any screens you could remove from your MVP?
Start by describing, almost like you are telling a story, how a typical user will interact with your app. Why will they choose to open it, what will they do when it is open, what is the benefit or outcome of using it, and what should they feel when using it?
Next list apps you think have a similar look and feel to what you want for your app. Refer back to them for inspiration on how to make interacting with your app consistent and rewarding.
This is the section that should get updated the most often. You will list what tasks you plan on completing every week. This is how you will realize if you are falling behind and need to cut more features.
-Add Facebook Login
-Write basic instructions for new users
-Add basic instructions to display first time app is launched
-Test with 5 new users
If you're new to projects this long, you will have to make best guesses as to how long things will take.
Before ordering your tasks on a week by week basis, first list every task on your plate. This should include everything you've listed in your ADD that will be in your MVP and all the non-technical work your app requires.
For every task, estimate how many days it will take. If you think it will take less than a day, round up to a day.
Add all the days together. Multiply by 1.2 to give yourself buffer time for unexpected delays. If you end up with more than 8 weeks of estimated tasks, do not change your estimates. Unless you have significant experience with large projects you should almost never change your estimates to be more optimistic. It is a big red flag if your gut tells you a task will take N days but after thinking about it you decide it won't take as long. You're almost always wrong.
If you have more than 8 weeks of work left, cut features.
If it doesn't hurt, you aren't cutting enough features.
Revise your ADD if necessary if you end up making significant changes to your app's design.
Only once you have a list of tasks that fit in 8 weeks should you start dividing them up week by week.
Fill out the rest of the Technical section.
Views, View Controllers, and other Classes: List all Views, View Controllers, and other Swift classes you will need to make you app.
Data Models: List all Parse data models your app will require.
Go back over all sections and make sure everything is explained as concisely as possible.
Congratulations, you have an ADD!
If you have feedback on this tutorial or find any mistakes, please open issues on the
GitHub Repository or comment below.