Product Requirement Document
(PRD)

This block is designed to store all links to project resources: SRC (a Google Drive folder which keeps all project materials in one place), links to prod and dev servers, admin panel, link to wireframes and mockups (logo, style guide, brand Identity and UX / UI itself), a link to the REST API documentation (OpenAPI standard), links to other resources necessary for daily work on the project. This allows all project participants to quickly find what they need.

Initially, this is a brief or a task statement with which a client approached us. However, as the Discovery Phase progresses, we update it with relevant information. On large projects, the brief can take 20-50 pages and have its own subsections. This is necessary so that the client and the development team can see the real direction of the project all the time.

This is one of the most important sections. The Discovery Phase starts immediately with 20-30 general questions. Then, as more and more details are clarified, our team completes the brief and builds the Project Structure.

• Again, questions are an essential part of the PRD. The reason is that the main task of the Discovery Phase is to find as many pitfalls of the project as possible before the estimation stage. Asking the right questions allows the team to become familiar with the specifics of the project. The client, at this time, gets acquainted with the technical features of web development and terminology
• The questioning phase only stops when the PRD is complete. A project can have from 50 to 400 questions
• As we say: The worst question is the one that was not asked

This section contains a complete list of all the core terms of the client's project (medical, legal, technical, industrial). This section allows all project participants to quickly understand a term, technical slang or just an abbreviation that is used in the context of a project description.

This section describes the common UI / UX features to the system as a whole, the principles of page behavior, blocking data when saving, saving rules, sorting, filtering and other features which will apply to the entire project. What allows us to describe each individual functional block below and to simplify the information while avoiding repetition. Which allows us to only describe differences from the standard behavior of the system in some cases.

If the project involves the use or connection of physical equipment, this section will describe it.

• For example, fiscal printers, fiscal registrars, cameras, document scanners, scanners for barcodes and QR codes, and other additional equipment
• This section can also describe the technical features of the work environment of company guys if we are developing a management system (ERP, ERM, CRM). For example, screen size and resolution, touchscreen or normal, Windows or MacOS
• Additionally, the requirements for the work environment of guys or customers can be described. For example, the cashier work environment: there is from 30 seconds to 2 minutes to serve one client so that there is no queue at the medical center (capacity is up to 500 people per day)

This section often takes 1-4 pages and contains a complete list of all technologies, APIs, libraries, and best practices that will be used in the project.

This is the main part of the PRD. This block describes detailed information about each button, page and user interaction. Historically, this section has been called the project structure, because this section describes all the project details. Let's see what is included here.

This section describes all the seeders that will be needed during the development of the project. Including with test data (as close as possible to real and satisfying our QA regulations).

• In the case of reference information, listings or other data, the sources are clearly indicated or content files are uploaded to the SRC.
• If we need to migrate data from tables or an old database, this section describes in detail the rules for migrating and transferring data to a new database.
• For the project to work, it is necessary to fill the database with some information in advance. For the project to be viable. Both at the development stage and at the launch stage. Therefore, seeders can be marked for a dev server, a stage server, or a prod server.

This section contains a description of all system notifications. It is important not to lose sight of the fact that a project can send 20-50 different notifications according to events in the system (purchase, like, subscribe, unsubscribe, complaint, feedback, product received, order processed etc.).

Here we describe not just a list, but also the conditions for the occurrence of an event for sending a particular notification.

Conditions for remarketing and reminders, as well as educational notifications.

• Email notifications
  • Bulk email service is selected (described in technologies)
  • Wireframes are created for each letter with the specific text of each notification along with the sending conditions
• SMS notifications
  • Bulk SMS service is selected (described in technologies)
  • The text of each SMS is described along with the conditions for sending
• Push notifications
  • The text of each push notification is described along with the conditions for sending it
• Browser push notifications
  • The text of each browser notification is described along with the conditions for sending it
• Project notifications
  • The text of each project notification is described along with the conditions for sending it

This section describes all the features for authorized users, for the private part of the project. Every action, every button, every background process must be described. The more accurate the PRD is, the more accurate the deadline will be. We always work as transparently as possible. We don't need too much. Therefore, we strive to give the most realistic and honest estimate.

Below is a list of items that may be included in the private part of the project excluding specific elements of each particular project.

• Authorization
  • Can be split into roles
• List of CRUD directories
• List of Documents
• Reports
• Data exchange (import/export)
• Function block list

This section describes the back office of the project, the admin part, CRUD, directories, documents, reports, printables and much more. Admin panels can be complex systems with multiple roles, permissions, locking data on save, complex business logic and background processes. Everything should be described in detail up to every button and every action of the user and the system.

Below is a list of items that may be included in the private part of the project excluding specific elements of each particular project.

• Authorization
• Registration
• Settings
• List of other pages

This section stores a complete history of all answered questions, so that if necessary, the client can always return to them to refer to the answers. Each word in the Discovery phase is captured and saved. This way, open, transparent and trusting working relationships are built. Work relationships like that can last for years, we have clients with whom we have been working since 2007.