Design and Requirements Documentation
New month, and a new issue that has kept on making its appearance on multiple discussions that I’ve been a part of. Product Requirements — where do they come from, who should be responsible for them, and what role(s) does the Design discipline and designers, in particular, have in its creation, management and execution. It’s a topic that more often than not, generates a heated conversation, due to the fact that it touches multiple roles and responsibilities and something that concerns a wide variety of professionals.
The goal of this article is, much like my previous ones, to shed light on the topic, by demonstrating real-life situations I’ve been met with, how they marry (or not) with the more academic aspect of Design/Product Design and lessons that I’ve been able to distill from these projects/case studies.
1. Product Requirements
According to Wikipedia, Product Requirements document “is a document containing all the requirements to a certain product. It is written to allow people to understand what a product should do.” Product Designers have come to expect for documentation to be provided, upon the genesis of a new product or feature. It’s traditionally been the typical process — the Product Owners or Business Analysts, compile a document that states the expectations and functionalities that a certain product or feature is supposed to exhibit. These are a distilled narrative, one that encompasses a marriage of customer feedback, business goals, competitive analysis and hopefully, usability testing. This is, of course, an expectation that has been progressively morphed into something else, particularly as organizations have embarked on Design Thinking processes, ones that include in the “Understand” chapter of this process, the components of Empathize and Problem Definition.
As Designers have taken a role that isn’t so receptive, but progressively more focused on being catalysts of change, the documentation, and specifically the requirements that are produced, should reflect that. This article comes primarily as a result of witnessing a constant tug of war that seems to occur in a lot of organizations. The question that always arises from these situations is: should designers wait for requirements to be produced, and then start merging these in the Design Thinking process or should they be more pro-active and engage beforehand based on research that is compiled from multiple sources? I’ve experienced, with different types of teams, both scenarios — I’ve worked on products where the requirements were extensively produced before the Design Thinking process was even a part of the equation, and when indeed this one was considered, those requirements morphed throughout the process, in order to contemplate different factors that were the result of the discoverability exercise that was taking place. In this particular scenario, it was relevant to come to the sessions with the results of all research (as stated before, that included competitive analysis, both direct and indirect, but also customer support group feedback, web metrics and analytics, usability testing sessions results, business and resource allocation considerations, to name the most striking and immediate ones).
The documentation produced evolved and became a more relevant representation of the product that was being built, since it also married a lot of different sources of input, while still maintaining, to a certain extent, the initial considerations built by the Product Ownership team. I’ve also witnessed and experienced the opposite scenario to the previously described one. An application that was being built, had no actual documentation to sustain it, other than a verbal pitch of intent. The requirements were actually to be produced and documented as a result of the Design Thinking process, one that invited multiple stakeholders to participate, and surfaced all the enumerable factors that were already described earlier. During these sessions, where Product Owners, Business Analysts, Development Teams, Designers and other Stakeholders were brought together for the merger of efforts, there was a mapping that basically unfolded marrying all these different expectations, from empathy with users, to business expectations, technology and innovation concepts, to feasibility and functional planning. It’s a testament to the Agile methodology, that through this process, as documentation was being produced, the aspect of being flexible, responsive and hopefully, lean in the approach, allowed for the process to run smoothly.
Do I believe one of these scenarios functions better than the other? In my experience, they are both worthwhile and simultaneously produce better team engagement, integration and collaboration. With any of these cases and situations, Designers have to be prompt in their process to be able to educate other teams members on expectations, on activities, and of course, deliverables. These scenarios, and the quality of what is produced only works effectively if everyone understands what the path is, and what the expectations are.
2. What Comprises Product Requirements
Interestingly enough, a lot of Product Requirements Documents, have a lot of different formats and ways of being written. There are countless articles being produced these days on how to write for UX and for Product Design, and while those are all fantastic and well suited, they fall outside of the scope of this article. The crux here lies in how do we write the documents that are at the genesis of what the product should behave like, who is it for, technical feasibility and expectations, the journeys the user embarks on while using it, and the general expectations that are being drawn for the feature and/or product. These documents don’t pertain and don’t register user stories, which again, can be written in a series of different methods (and that can be addressed in a different article). The goal here, is detailing what exact elements to register on this document, and how they can and should be useful for designers, developers, analysts, senior stakeholders, product ownership — a document that becomes a living watermark of how the product/feature was conceived.
The most successful documents that I’ve both utilized and produced contained the following items (I’ll list the chapters that I consider relevant):
- Purpose;
- Document Conventions (which includes terminology being addressed in both the document itself and the application) and Focused Users (including User Journey Identification, respective marriage to empathy maps that have been produced, characters being focused upon);
- Scope Delineation (which focuses on the multiple cases tied with the product/feature, dependencies);
- Functional Requirements (primarily focusing on the scenarios, and what are the expectations of behaviors for all of these);
- Platform Identification (this actually is relevant in how products should be designed with the intent of having omni-channel experiences that are consistent, and therefore with a level of seamless integration between different form factors).
Again, these documents can be as scrutinized and strategically divided as much as teams deem necessary, with some of them actually incorporating the feedback/revision components that the requirements experience throughout the Design Thinking process (much like Basecamp for instance, where you integrate feedback and comments in a sort of timeline), but the goal is to register and produce documentation that is relevant, credible, sustainable and informative (I’ve also previously written about Documentation, in the article “The Importance of Documentation to a Successful Design Process”).
I’ll summarize this article by first stating that Designers should be flexible, but also insightful. It’s not our role to be expecting everything in a manner that is immediately perceptible and digestible. If anything, Designers should be forward thinking, advocating for process adoption, and providing recommendations on how they see the flow of the Design Thinking exercise evolving. The times for Designers to wait for clarification are gone — these days, Designers are catalysts, but also trailblazers, in the sense that through educated process establishment, and documentation definition, we can provide a more successful Product Development Journey. I’ll conclude by quoting Charles Darwin — “It is the long history of humankind (and animal kind, too) that those who learned to collaborate and improvise most effectively have prevailed.”