One to the topics amongst many that often dominates conversations when it comes to Software Design in general (and Product Design in particular) is of course, Requirements. Typically that topic is forever associated with Product Requirements which are written by Product Owners or Business Analysts the latter working under the guidance and tutelage of Product specialists (and this aspect of course also shifts depending on the Organization itself and how they distribute their resources). One aspect tied to the Product Design journey that doesn’t get quite as much prominence and discussion however, is Design Requirements. And while that typically is associated with the fact that Design has for the longest time played a service “fiddle” to Product, the fact still remains that Design Requirements (or DRD, Design Requirement Document) are just as important and relevant as the ones stemming from Product and Development. I have actually written on the topic of documenting requirements previously, but from a product perspective and how it informs the Design process itself, which you can read about here .

Requirements — The platform Wrike and their content producers define Product Requirements as such: “A product design requirement document (PRD) is a comprehensive document consisting of all the necessary information a product development team needs to deliver a successful product. It guides the team in creating a product with the end-user in mind. A PRD uses a top-down approach that is commonly utilized in the Waterfall project management model. Nowadays, PRDs have evolved to be operational in Agile environments, making it easier to align the product manager, development team, and other stakeholders around product development and delivery within set timeframes.” Product Plan defines it this way: “A product requirements document (PRD) is an artifact used in the product development process to communicate what capabilities must be included in a product release to the development and testing teams. This document is typically used more in waterfall environments where product definition, design, and delivery happen sequentially, but may be used in an agile setting as well.” Many other definitions float around in different blogs and publications, but essentially, product requirements documents define the expectations of what a particular feature or product is going to do and behave, and how users are expected to interact with it. It also assumes at this point, and that’s where the typical Waterfall project management process (and even Agile to a certain extent), has already figured out through the Design process, what essentially works and doesn’t and what needs to effectively be built (either across an MVP perspective, or within whatever product lifecycle an organization actually is). However, while these requirements outline a series of expected behaviors, they don’t necessarily translate the Design requirements that actually stem from running a human centered design process.

To follow suit from the previous definitions, a Design Requirement Document (DRD) or set of Documents, consists of a distillation and summarization of what was uncovered during incubation, iteration, testing and refinement of a particular feature or product that is going be implemented. This document typically indexes and lists a series of artifacts in order to support its integrity, including prototypes, design systems references across components, interactions, content, motion, accessibility standards, to name but a few, all with the purpose of removing ambiguity in the execution of a particular feature/product. If done effectively, a DRD should provide a clear roadmap for what is going to be implemented across all variables that may be contemplated, and potentiate the PRD with all the information that it needs. On a different note, an effective DRD is also actually of great use not only for Development teams, but also for Product teams, since it allows those partners to have a holistic view of the entire journey itself, succinctly documented, giving them an opportunity to create stories that are that much more relevant to the sprints ahead (and that much easier to parse through). Just as importantly, DRDs also function as a great tool for other Design teams to learn and understand a particular process, be ingrained in the types of artifacts that are needed to be delivered for the efficiency of that process and also onboard new team members that join the teams. Effective DRDs can potentiate and speed of the entire development process, independently of being crafted in a Waterfall or Agile environment. While PRDs are essential for teams to understand how they’re going to build something, the DNA of these documents, and of the product itself is tied with the DRDs. When it comes time to assess the quality of what’s being delivered, the quality control needs to be conducted on multiple levels, since a product experience doesn’t exist in a vacuum solely driven by one particular point of view.

The Shape of Requirements — The DRDs can actually be shaped in a variety of formats. Since they typically index a series of artifacts, including prototypes, design system references across the different components which will be utilized (and the Design system should of course have the necessary tokens), well defined copy (the UX writing is included as well), all this information should be as clear as possible as to avoid any ambiguity when consumed. As a necessary callout, the Design System indexation should contemplate everything which substantiates the development teams’ needs, from an atomic perspective through the templates they may need, while also including details on aspects such as micro-animations and interactions, transitions, localization and accessibility considerations, literally everything that substantiates what will be built. How teams share this information really depends on their own internal project management arsenal of tools. In the past I’ve used Atlassian’s tools such as JIRA (with all the indexation of assets and information being placed as part of an epic story), Trello, but I’ve also used Invision’s Boards, leveraging their ability to have different chapters, and also Mural, Miro and even Basecamp. All these tools serve the same purpose of allowing for easy share-ability, collaboration and multi-platform consumption. There are of course plenty of other tools which also allow for this sharing aspect to occur, such as Notion, Asana, Wrike, to name but a few. One additional note on this topic. If and when situations occur where a Design system isn’t crafted, it’s important for the DRDs to index the prototypes, but also their corresponding handoffs, properly organized, so that all the teams understand how the feature or product is actually shaped by all the different components. Always make sure to properly identify the items on the handoff, since they shape what the teams are going to: 1. Build their stories around; 2. Consume assets in order to be effective.

Design Requirements are typically not heavily discussed since they get lumped under the Design Process itself, and are at times associated as part of a Design review for instance. However a DRD goes far beyond a design review, and it’s actually a great exercise teams should reflect upon. It forces them to compile what is essential from a Design perspective for a feature or product release to be considered successful, including the KPIs they are also measuring their output against.

As Benjamin Franklin stated:

“For every minute spent in organizing, an hour is earned.”