Recently, I reviewed some product documents from my team, and they were so disorganized and hard to understand that even GPT couldn't make sense of them.

A review that should have taken 10 minutes ended up dragging on for several days, nearly driving me to tears.

So, I spent hours summarizing the 9 key details I use when writing a requirements document: color contrast, size differences, shape distinction, symbol marking, avoiding ambiguity, presenting with charts, dimension extraction, concept encapsulation, and domain knowledge.

If you've faced similar issues in your work, this might help.

1. Color Contrast

Using different shades and color contrasts can help highlight key points in the document at a glance.

When drafting requirements, you can try using red text to mark important content or explanations.

I have a habit of using blue text to indicate links to pages or interactions.

2. Size Differences

In some UI design guidelines, there are often rules about font size usage.

For example, 22px is used for page titles, 17px for list titles, and 14px for list description text.

I highly recommend that junior product managers study one or two design libraries that include specifications for fonts, icons, components, colors, and sizes.

Mastering a component library can significantly improve your aesthetic sense as a product manager.

3. Shape Distinction

If optimizing your document with color contrasts and size differences still doesn’t make the content easy to understand, try adding another dimension—shapes—to further simplify reading.

Think of flowcharts we are all familiar with: rounded rectangles represent starting points, rectangles indicate processes, and diamonds are used for decision points.

4. Symbol Marking

Symbol marking refers to using special symbols to highlight key layers of content and deepen the reader's impression.

I usually like to alternate between Chinese and English, using symbols such as “”【】「」to emphasize certain key points in the document.

5. Avoiding Ambiguity

One common mistake that beginner and intermediate product managers often make is creating ambiguity in their documents.

For example, a list might need to display the "name" field from the clients table. However, that table might also include fields like full_name, first_name, or display_name.

If your document simply says "display client name," this could lead to countless issues during frontend-backend integration and testing.

The developers and testers might spend hours trying to guess what exactly "client name" refers to. Is it the user table, the visitor table, or the client table? And if it’s the client table, which field are you referring to: full name, name, or surname?

With some luck, the frontend and backend might eventually get the output you expected. But in most cases, if you’re unclear about the data logic and details, you might either accept a solution full of hidden bugs or be unable to identify where issues are during testing.

This example illustrates just a basic error related to table data. Imagine how chaotic things would get with more complex financial data! If it matches up correctly, you'd be considered very lucky.

6. Presenting with Charts

A picture is worth a thousand words—use charts whenever possible.

For example, certain complex concepts might take hundreds of words to explain, but with a picture or table, the reader could grasp the meaning in just a few minutes.

I recall early in my product management career, when I had to explain a rather complex order status definition. I first tried using text, which was time-consuming to write and painful for others to read.

Later, I learned UML and managed to create a simple state diagram in minutes, which was clear and easy to understand.

7. Dimension Extraction

Unrefined content is just a mess of disordered information. To transform this into digestible, reusable knowledge, you need to summarize and extract dimensions by finding differences and commonalities in the content.

Then, categorize and organize the information according to these dimensions. This thought process is what I call "dimension extraction."

Teacher Tuobuhua shared a workplace listening method in her book The Method of Communication, where she structured communication topics into three dimensions: emotions, facts, and expectations.

8. Concept Encapsulation

Concept encapsulation is about compressing and simplifying content to make it reusable.

It involves using a simple concept to represent a series of closely related, frequently used, complex content. The advantage of concept encapsulation is that once defined, it can be reused continuously.

For instance, in my requirements document templates, I often use global instructions, terminology definitions, formula reuse, parameter descriptions, common components, and interaction decoupling—these are examples of concept encapsulation in action.

9. Domain Knowledge

How can you quickly improve the communication efficiency of your documents? The key lies in presenting domain knowledge.

In simple terms, when addressing different readers, you need to present professional content that suits them.

For example, since the boss's time is precious, you need to make sure they grasp the key points of the document in just one or two minutes. In this case, your content should be concise and use plain language to explain core concepts.

When addressing business stakeholders, you need to balance simplicity with professional business knowledge to quickly achieve mutual understanding.

For frontend and backend teams, you need to write in a way that aligns with their technical knowledge, ensuring your document is easy for them to understand.

For example, be clear about data handling, exception handling, and complex rule interactions.

Many junior product managers will face a situation where they spend an hour writing detailed documentation, only for the developers to ignore it completely.

This happens because the content doesn’t use the common language of developers, making it difficult to understand.

A better approach is to use a unified modeling language like UML to create a few state diagrams or flowcharts to present your requirements—professional and efficient.

Conclusion

How can a product manager write requirements documents that are both clear and professional?

The key lies in mastering these 9 points: color contrast, size differences, shape distinction, symbol marking, avoiding ambiguity, presenting with charts, dimension extraction, concept encapsulation, and domain knowledge.