Prototyping is the best way for product manager to communicate with RD, UI / UX and website development engineers. So, what can't be done in prototyping.
First, define the role of product prototype. You have to know what product prototype is for, so as to make better use of this skill.
There are two roles of product prototype:
The first role is that the product prototype is the product manager's visual embodiment of the product design plan and ideas. The prototype represents the starting point, idea, concept and logic of the product manager when designing the product function;
The second role is that the product prototype is a reference for other members to think in line with the product manager, that is, the product manager needs to reach a logical agreement with other members in a team through the prototype, so as to avoid misunderstandings and deviations.
Therefore, it can be seen from here that although the product prototype is very basic, it is really important. It not only reflects the thinking logic and business pattern of the product manager, but also reflects the working method and style of the product manager
Next, let's focus on introducing the 5 do's and don'ts of product prototyping. This post focuses on 5 things not to do in prototyping. These are some of the problems I have seen in my work or when I talked with the students.
1. First: don't think the product prototyping is very simple
Many people think that product prototyping is a very simple job. Even some new product managers disdain to draw product prototypes. They think it's just to open Axure and draw a few boxes, arrows and lines on the canvas. What's the difficulty?
If you think so, you are wrong. The prototype design tool is really not difficult to use, even simpler than the visual design software such as Photoshop, but the product prototype never show your proficiency of using the prototype tool. As mentioned earlier, the product prototype is only a visual product of the product design idea, which reflects your product design idea and logic. If your product prototype is a mess, If the logic is unclear and inconsistent, then your product design idea is chaotic and illogical. The products developed according to this prototype are either a pile of bugs or can not solve any needs of users, because you don't know what you are designing, where your original intention is and where your logic is, and the developers don't know, Let alone users.
Some product managers draw very chaotic prototypes, but they think their ideas are clear, but they just don't show it through the prototype. This approach will never work, especially for new product managers. No matter whether you really think clearly about your product logic and design ideas, if you don't reflect them through the product prototype, you just don't think clearly in the eyes of others. No one will believe how great product design will be behind a very low-quality product prototype.
2. Second: don't spend too much time on product prototypes
If the first case is to despise the product prototype too much, the second case is to pay too much attention to the product prototype.
I once had a subordinate who has been engaged in product manager for about 5 years. He works very carefully and works very hard. However, he has a problem. He spends too much time on the prototype every time. The prototype design is very beautiful and exquisite. He will spend a lot of time studying and applying various functions and repeaters. The interaction effect of the designed prototype is very cool, and even exceeds the standard of high fidelity prototype;
In fact, I don't advocate this practice, because we should understand that the ultimate purpose of product prototype is to reflect the product design idea, so that programmers, tester and UI designer can reach an agreement with the design idea of product manager through prototype. It is enough to clarify the logic and design rules of product design and reduce the deviation of subsequent deliverables. Too cumbersome product prototype design will actually put the cart before the horse, allowing you to waste a lot of time on the prototype and ignore the user demand analysis and product feature design that should have taken more time.
3. Third, don't start drawing prototypes as soon as you receive the task needs
After receiving the product planning task, many product managers often start to open Axure and start drawing prototypes at the first time. In fact, this practice is wrong. Because at this time, your thinking is chaotic. You don't start to sort out the needs, analyze the needs, understand the background, and don't simply think about the product process and interaction. Drawing a prototype at the beginning often leads to mistakes, making your ideas more and more chaotic.
People who draw prototypes directly without thinking are basically opportunistic. Why do you say so? Because the product manager's thinking process about user needs and interaction design is invisible, while the product prototype is tangible, these people do not think at the first time after receiving the task, but look for competitive products and prototype templates, and then copy according to competitive products or online prototype templates, because this is the simplest. They don't bother to think about the essence and logic behind the task, but only explain it according to the logic of competing products or templates.
This seems to save time and effort. In some unprofessional teams or companies, you can even get praise for your high efficiency, but I don't recommend you to do so here. It doesn't play any role in improving your personal ability, because you ignore the core product thinking ability of the product manager.
4. Fourth: don't add product feature demands because of prototypes
Adding feature demands to the prototype is also a common mistake made by product managers who are new to the industry.
The essence is that the relationship between the product prototype and the feature demands is not clear. The product prototype is only the visual embodiment of the product manager's design ideas and logic. The product prototype follows up the feature demands. We must remember this.
But many people, in order to pursue the beauty of page layout and the integrity of product features, they begin to add feature demands, which virtually expands the boundary of products and increases the development cost.
For a simple example, I met a product manager before. The demand he received was very simple: design an app login page to support users to register with their mobile phone number and login with their mobile phone number + verification code. However, the prototype he finally delivered has many more features: the feature of retrieving the password, the feature of remembering the password, the feature of user name + password login, and the password must also support three forms of special characters + numbers + letter case. At that time, the background of the project was that the MVP version needed to be launched within three weeks, and the user research shows basic login features was enough to meet the early needs of users.
The explanation given by the product manager is that the page layout is incomplete and unsightly, and needs to be decorated with other features, which makes it perfect. That is believed to be a mistake made by many product managers. If we think that competitive products are made in this way, we must also have such a feature, or if the online product prototype template is like this, we should have it. Or if there is no access to retrieve the password on this page, the layout will be ugly and unsightly;
This kind of behavior of reversing design must be avoided by the product manager: they only consider making the prototype perfect and the layout good-looking, while ignoring the user needs themselves and the actual situation of the project. We must clearly know that the prototype serves the needs, not the needs serve prototype. Otherwise, the product boundary will not be controllable and the product features will not be able to solve the user problems.
5. The fifth : don't stop update the prototype
In the process of development, there are many modifications to the prototype. Sometimes it is because the product manager does not consider clearly the logic and usage scenario of the product, or whether the design feature can be realized. The prototype needs to be modified or optimized. However, many product managers have completed the first version of the prototype well, but after reviewing the requirements, they do not change the prototype because of laziness or too many things, I have seen a lot of such situations, so my first requirement for the product team is to change the prototype in a timely and active manner, and after the prototype changes, be sure to synchronize with all stakeholders and let them follow the latest prototype.
Not updating the prototype will bring a lot of serious consequences, such as team contradictions: R & D and tester did job according to the wrong prototype, which leads to waste time, and easily make the team lose confidence. Therefore, the product manager must update the prototype in time and notify everyone. Sometimes the prototype is only a small adjustment, which takes a few minutes. However, because the product manager is lazy, the consequences are often very serious. Therefore, in the product prototype update, don't be lazy and don't update the prototype.