There have been times when you think of an amazing project but your mind procrastinates showing it as some unachievable task.
Even if you defeat your mind and start implementing it to the code (directly) after a certain time you might lose track of what you were doing and what you wanted to do and out of frustration you are sure to leave all of it and rm -rf the directory of your project.
Not sure about you but this happens to me quite a lot. Because of this half of the projects i try to build, i leave them in half.
Well then what is the problem here ? — Lack of Proper planning
Yes when you deeply analyze, the root cause you would find it to be lack of prior proper planning of the project.
This is where the PRD comes to rescue.
PRD [ Project Requirement Document ]
Project Requirement Documents known as PRD is a high level document that describes the need, planning and execution strategies of a project. This document is crucial to ensure the success of any project you are doing
While there is no hard and fast rule to what should and what should not be written in the document. Some most to haves and what they refer to is predefined which we will be going through in this blog post.
Let us understand how these high level documents are written and what are must haves of the document along with writing an PRD for a basic todo application.
Steps
The first step of course is defining what the project is. In our case it's a simple todo application.
Objective and purpose 🎯
Then comes the most important part that is the Objective and Purpose of the project. Why most important ? because this is where your project is differentiated from being a product. A product can be considered as a project that has an objective to solve any real life problem ( might be yours or others ).
Since we are trying to build a simple todo application, our purpose here is to ease the user's life and help them keep track of their day activities to ensure they utilize their time wisely.
Scope 🌏
There are numerous amount of features an app can have, ranging from integration of it with AI or connection of it with other apps like google calendar and spreadsheet. So in this step we would determine and limit our project to only what's required.
For the todo application, the scopes would be:
Scope of Project
- The scope of the project is to build a simple todo application that allows users to add, delete and update their tasks.
Features and Requirements ✨
This is where we define the features that are must haves and the ones that are good to have. We can divide the feature in two to three categories as per the project needs:
P1 (Priority 1): Major functionalities for project success.
P2 (Priority 2): Functionalities that enhance user experience but are not necessary for initial deployment and can be added in later releases.
and so on..
For our todo application, the features are:
Features P1 (Priority 1):
Add a task
Mark a task as completed
Delete a task
Update a task
Features P2 (Priority 2):
login and signup
Set up predefined templates for specific days/ tasks
Save the data in database
Set a time for a task
Set a reminder for a task
Features P3 (Priority 3):
Share a task with others
Sync with google calendar
User Stories / Use Cases 📚
This is where we define the story behind the project. How did the project came into existence and the different scenarios in which user can use the application to meet their needs.
For our todo application, the user stories are:
How was the idea of todo application initiated ?
The idea of todo application came when i was struggling to keep track of my time and tasks. I had big goals but did not understand the importance of breaking them into smaller tasks. This is when i thought, of building a todo application that would help me keep track of my tasks and time.
Remember before solving other’s problem you must aim to solve yours
How can the user use the application ?
- Users (including me) can interact with the application through a interface where they can add, delete, update and mark their tasks as completed. This would potentially keep them on track and help them achieve their daily goals.
Technical Requirements ⚙️
This part of the document defines the technology to be used including tech stack, programming languages, frameworks, libraries. This is very crucial as the scalability, security, ease of integration and feature enhancement vastly depends on the technology stack .
For our todo application, we will be using simple HTML, CSS and JavaScript. For storage we will be using local storage as of now.
Design Requirements 🎨
This is purely the design part, UI (User Interface) and UX (User Experience) of the application. Here we define the design standards, the consistency, user experience and accessibility of the application. This is a part defined for the UI and UX team (if any).
For our todo application, we would keep the design simple and minimal. The user should be able to easily add, delete and update tasks without any confusion.
Success Metrics 🫡
This part of the document defines the success of the project. The measurable goals to assess the success of the project. For instance if you are building a backend server, the success metric here can be the response returned and so on.
Since we are just building basic todo application we do not have such success metric right now, but user satisfaction and adoption rate can be one of them ( here user → me )
Timeline ⌛
We as humans are bound not to complete any task unless some deadline or pressure is on us. Remember not studying for exam until the day when exam is conducted. Hence it is very crucial to define the timeline including the key milestones and deadlines for the project. This includes design phases, development phases, testing and final release.
For our todo application, the timeline would be: ( Here it’s done in days because it’s a simple todo application, for other projects it’s usually weeks )
Day 1: Design the application
Day 2: Develop the application
Day 3: Testing and debugging
Day 4: Final release
Conclusion
The Project Requirement Document (PRD) is a high-level document that outlines the purpose, scope, features, and requirements of a project. It serves as a blueprint for the project, guiding you throughout the project and helping you get out of the loophole of not finishing the projects.
By defining the project objectives and scope, the PRD ensures that the project stays on track and meets the needs of the target audience. The PRD also outlines the technical requirements and design standards for the project, ensuring that the application is scalable, secure, and user-friendly. By defining the design requirements, we ensure the application is user friendly and easy to use.
Most importantly we ensure that the project gets complete and is on the right direction.
If you find this blog helpful, feel free to drop a like and a follow