10 Misunderstandings in Product Design Source

Translated

Image Source: HermanMiller

I. Requirements Collection Phase

1. Inability to say "no"

At the product development stage, teams often face the challenge of evaluating numerous internal and external requests that appear valuable or feasible. Unfortunately, this can lead to accepting all requests without determining their alignment with the product's goals.

Product newcomers commonly face this challenge due to their lack of experience or hesitation to question leadership or customers' requests. They may not have a better plan or fear asking why the requests are necessary, leading to accepting all requests without careful consideration.

To avoid this pitfall, teams should write down all requests and evaluate each request's feasibility and value before making scheduling decisions. Additionally, during research, teams should ask more questions to understand the purpose behind each request and uncover any underlying issues.

Ⅱ. The prototype design stage

1. Haste in creating prototypes

Teams often face tight construction schedules and numerous requirements that may lack clearly defined rules or logic, leading them to rush into drawing prototypes. Although this approach may provide a visual representation of the product, it often results in functional pages that do not address the actual business needs or problems.

To avoid this pitfall, teams must be cautious when encountering such situations and prioritize identifying and solving the actual business problem before designing the prototype. The prototype should be based on the team's thinking depth behind the business and reflect the solution to the identified problem.

It is crucial to understand that the prototype is a surface representation of the product and should not be the primary focus. Instead, the team should concentrate on addressing the business's actual needs and problems.

2. Don't like to ask for help

When facing difficulties in designing a function, there is a tendency to try to find a solution on your own, perhaps to demonstrate your value. While this approach can be effective, it may not be enough in situations where you lack the necessary knowledge or information to solve the problem. This can lead to a waste of time and resources.

To ensure efficiency and results, it is important to seek help when necessary. This could involve consulting colleagues, managers, or other professionals. Recognizing the limitations of one's own cognition, it's possible that someone else's perspective may lead to a breakthrough in solving the problem. When encountering such challenges, it is essential to shift one's thinking, challenge one's assumptions, and proactively utilize available resources to achieve a successful outcome. Ultimately, it's through collaboration and resourcefulness that solutions are found and problems are solved.

3. Obsession with high-fidelity designs

It's easy to get caught up in details such as page colors, button sizes, and font placements when creating prototype diagrams. While high fidelity is visually pleasing, it's important to prioritize the logic and functionality of the design. Showcasing design ideas efficiently and guiding technology development should take precedence over focusing solely on high fidelity.

While high fidelity is great when time allows, pursuing it too aggressively can lead to a loss of efficiency. Therefore, we should carefully consider priorities before beginning a design and always keep in mind what's most important.

4. Tendency to copy and paste lists with identical fields

Copying the same data line by line is usually not a difficult task, provided that the PRD document or other instructions are clear and unambiguous.

However, it is important to exercise caution and strive for clarity in the process. For instance, when dealing with instructions such as "disable/start," ensure that the timing is clearly specified to avoid creating an illusion of development. Similarly, when working with data that is normally calculated on a page, such as the number of members in different categories (e.g., 100 gold, 800 platinum, and 100 black iron out of a total of 1000 members), it is important not to use the total number as a universal value, as this could cause problems during development.

5. Neglecting to include a default page

When developing a program, it is easy to unconsciously focus on the normal situation without realizing it. At first, this may not appear to be a significant problem. However, you will eventually discover that something important is missing: how to handle abnormal situations that may arise.

Fortunately, experienced colleagues in UI and development can often assist in filling these gaps. Nonetheless, it is problematic to design a program that only considers the normal situation. In order to establish a comprehensive logic, it is necessary to adhere to the principle of MECE (mutually exclusive, collectively exhaustive). The default page exists to account for scenarios that fall outside the normal situation and ensure that the entire program is complete.

6. Redrawing the same designs repeatedly

I have friends who have been in the product development industry for years and have amassed a collection of various reusable tools. They have acquired these tools from different sources, including this course and other acquaintances. In short, they have compiled a large set of tools for reuse.

However, when they actually try to use these tools, they often find it difficult to locate and utilize them. As a result, they end up recreating tools that they already have, making the mistake of "reinventing the wheel." They fail to summarize their own set of reusable tools, which leads to wasted time when they have to start from scratch again.

To avoid this, I suggest that those who have not yet done so should develop a plan for organizing their set of tools. They can dedicate some time every day to slowly curating their collection. This will save them time and effort in the future, enabling them to complete tasks more efficiently.

Ⅲ. Interactive description writing stage

1. Writing interactive instructions

When creating interactive instructions, it is common to write them according to one's own writing habits without clear markers. While the instructions may be easily understood by the writer, they may be difficult or confusing for others to follow.

At this point, it is important to consider whether you have fallen into the trap of using language that is too personal. Although you may understand what you wrote, is it consistent with the reading habits of most people?

If the language used in the instructions is conventional and easy to understand for others, then it is acceptable. However, if it reflects only your unique style, it needs to be corrected. Writing instructions in a clear and rigorous manner can help developers understand your intentions quickly and improve overall development efficiency.

Ⅳ. Requirements review stage

1. Self-righteous

When you focus on "managing and controlling" others, and aim to establish "prestige" in the minds of developers in order to better "command" them, you fall into a trap of arrogance.

We are a team. Working together towards a common goal is a cooperative process. The product manager is not a "manager," but rather a team member who positions themselves correctly and collaborates with others to achieve the best results. It is important for everyone to fulfill their responsibilities and perform their own duties well.

2. Blind Acceptance

During the review phase, new problems may arise and colleagues may provide new opinions. Some people may blindly accept their opinions without conducting their own analysis or offering alternative solutions.

This is often due to a lack of clarity or depth in understanding the demand itself. To avoid this, it is best to think clearly when designing the plan, and to have a plan in place before the meeting. If a decision cannot be made at the meeting, it is better to develop a new plan as soon as possible instead of blindly following the suggestions of others.

Of course, if their suggestions are truly the best solution after careful consideration, they can be adopted. However, it is important to maintain a personal standard and bottom line, and not to blindly accept the opinions of others. The ultimate goal is to effectively solve practical business problems.

Ⅴ. Summary

• Inability to say "no"
• Haste in creating prototypes
• Don't like to ask for help
• Obsession with high-fidelity designs
• Tendency to copy and paste lists with identical fields
• Neglecting to include a default page
• Redrawing the same designs repeatedly
• Writing interactive instructions
• Self-righteous
• Blind Acceptance

The prototype page serves as a visual representation of your thorough comprehension of the business product features, but it is also a manifestation of the product manager's understanding of the market. The true value of a product or its features lies in its ability to effectively address the needs and challenges of the users.