Better Documentation And Team Communication With Product Design Docs

About The Author

Ismael has been working during the last 13 years inside design teams in small and big sized companies from many different sectors like news media, design … More about Ismael ↬

Email Newsletter

Weekly tips on front-end & UX.
Trusted by 176.000 folks.

Quick summary ↬ Have you ever struggled to get the green light on your design proposals? Do you feel like your design process needs to be formalized? Is the COVID19 era becoming a challenge for you when working remotely as a designer? Then keep reading to get to know a methodology to document your design process in this article.

The typical process for working as a product designer in a company or startup could be familiar to you: a new product is being developed for which to provide a design solution. Then you work on some design proposals and you pitch them in front of 1–3 people to gather feedback.

Sometimes this process works just fine, but some other times it doesn’t. For instance, some people are busy paying attention to finish their own tasks and do not spend enough time to provide clear and concise feedback for your design proposal.

It may also happen that even though your process is good you still want to formalize the process by writing down decisions, keeping track of iterations, and the design process in general, especially in the current times where we find ourselves working remotely due to COVID19.

Documenting the process has many benefits. For example, it makes your work more visible, creates opportunities to get feedback from many more people, improves the overall communication, and provides a clear picture of how a feature was designed with all the context and considerations around.

The Fall Of The Hero Designer

Around 2018, I was working as a remote Product Designer from Madrid in a company that operates in Latin America, involving in this process other teams from México and São Paulo, Brazil.

Remote map locations
(Large preview)

Before I started working at this company, I had plenty of different experiences in my career working in small and big-sized environments from many different sectors like news media, design studios, a social network, a mobile OS, founded an e-grocery startup, and even did some freelance gigs with other small startups.

During those years I had been following the same approach, you get some people sitting in the same room, pitch your solution, provide some screens, flows, get some feedback, and present it again. After some iterations, your work will be ready to reach the development phase.

However, this very same approach stopped working. Shortly after joining the team, I realized that just pitching my designs on a video call wasn’t enough. I was creating a lot of proposals, but I couldn’t reach final approval from my stakeholders and teammates. I was confused and kept asking myself: What was happening? Wasn’t I designing the best solution possible? Wasn’t I delivering good quality work? Every one of those questions was making me lose confidence in myself. The problem was that I needed to adapt my process to this environment.

More after jump! Continue reading below ↓

As soon as I realized that my process wasn’t working, I started reading a lot of articles about how to work as a designer remotely, the seagull effect (when someone comes into your work, harshly criticizes it and then flies away), how other companies were approaching remote collaboration, and how they formalized their process by writing it down. After reading all this material, I wondered how developers were facing this same issue? How do they collaborate on remote environments in an almost asynchronous manner? How do they come to final agreements? I discovered that in fact, the developer community already has a process that works quite well for them: It is called pull requests.

(Large preview)

Pull requests let you introduce changes in a larger codebase by documenting them and validate your decisions with other people’s feedback. In this way, the changes you introduce mix perfectly with all the standards and connections the code already has in place. This is exactly what I needed to achieve, but of course in a design-fashion approach. Let me introduce you to the Product Design Doc.

The Product Design Doc

A Product Design Doc (PDD), is a document that converts the problems you want to solve, the context, and the final solution into an iteration or stage-based approach.

This means you can document your entire design process into a single document that can be shared with anyone at your company and it will live as a knowledge base for the product decisions you make. Sounds cool, huh? Let’s dig into the details.

Overall Concepts

A PDD can be described in 4 major concepts: Metadata, Context, Stages, and Feedback.

(Large preview)
  • Metadata is just useful information about the document such as the title, date, status, and so on.

  • Context is what other people need to read, for understanding the design proposals you make, think about it like the description, problem, abstract, or goals of what you need to achieve.

  • Stages are the different iterations of your design, commonly starting focusing on the broader solution and in each stage focusing on more specific details. Each stage is based on the previous and addresses the feedback received. This is a structured way of reaching a final point where resolved issues can not appear again.

  • Feedback refers to all the opinions, comments, requests, and recommendations you gather from other people. You can gather feedback from your stakeholders or team members.

With these four concepts, you can create different variations of PDD for suiting your needs, every company/project is different and what worked for me, doesn’t have to work in the same way for you. But if you cover these 4 main concepts in your PDD, it will be likely to work in almost any situation.

Example Structure

After understanding the main concepts, I will share with you the structure that I’ve been using during my time in that company. It has the following sections:

  • Real-life example
  • Key Benefits Of Using PDD

    1. Every decision is documented.
      Meaning that even when you leave your company/project (and that will happen sooner or later), all the knowledge generated around will stick in the company forever, so other people can look at it and iterate from where you left.

    2. Improves communication.
      Getting different people from your team on the PDD to provide feedback helps everyone stay on the same page and being aware of the decisions made.

    3. Limits endless changes from stakeholders.
      Every stage focuses on a different angle of the problem, going from wider solutions to narrow ones. This allows people to focus on a single problem at a time, helping them in the closing stages.

    4. The product is built collaboratively.
      Instead of the stakeholders defining specific solutions, we let engineering, design, and other teams engage with the solution making them part of it.

    Final Notes

    Closing the story about this remote company, I got to work there for some more months and I was able to implement the Product Design Docs at least on 5 different projects. My frustration was reduced a lot and I was able to reach a consensus on my design proposals so the product continued to evolve. Since then, the company has grown a lot and some of the work I did during my time is still being used.

    PS: I started writing this article in 2019, then in 2021 I saw that Abstract was creating a product for documenting the design process, so I decided to get back on track and finish it. Looks like it’s still quite a relevant topic.


    slots empire bonus codes
 Editorial (vf, yk, il)