The longer you work, the more you will find that drawing prototypes is a necessary but not the most important skill for product managers, it is only one of the links to achieve the goal of product success. The core capabilities of B-end products are commercial route architecture capabilities and business architecture capabilities. So we need to learn how to prototype efficiently and then spend more time growing our core competencies.
For the B-side, it generally takes enterprises/economic organizations and related business roles as the core service objects, so the business logic and processes are relatively more complex, and it often requires multiple products to cooperate to promote the development of B-end products, which will also involve product teamwork-related content.
In the process of drawing prototypes on the B-end, we often encounter the following common problems:
- Where to think of where to draw, there is a lack of overall awareness
- Not knowing which component to use, always reinventing the wheel
- I have to draw prototypes and write PRDs, and transformation takes a lot of time
- The team style is not uniform, which affects the output effect
In response to these problems, I have summarized several coping methods, which I believe will be useful to you!
1. Do a good job in pre-prototype preparations and complete it in one go
Before entering prototype design, we must first conduct requirements research and business analysis, and we need to realize that only when this step is solid can we draw prototypes in an orderly manner.I even think that as long as we do a good job of requirements analysis, we have completed 80% of the prototypes; On the contrary, if the requirements work is not done well, the later prototype will most likely need to be reworked.
To achieve these three challenges, product managers will only continue to appreciate
Good product managers are very scarce, and product managers who understand users, business, and data are still in demand when they go out of the Internet. On the contrary, if you only do simple communication, inefficient execution, and shallow thinking, I am afraid that you will not be able to go through the torrent of the next 3-5 years.
View details >
Therefore, do not start drawing prototypes after getting the functional points of the requirements or understanding half of the requirements, think while drawing, and draw wherever you think, such as whether the business process is like this, what is the next page, and what content should be on the page, which not only affects efficiency, but also often does not think comprehensively to increase the amount of rework.
So what should be done? First of all, when you get the requirements, we need to clarify the three elements of the requirements: target users, core pain points and solutions, that is, to figure out who our target group is, what problems they encounter, and how we can solve their problems through products (or services) to finally achieve customer satisfaction.
Secondly, frame the scope of requirements, draw the business process, output the business process diagram, and ensure that you have a correct understanding of the business scope and process, so as to minimize the thinking time so that you can complete it in one go.
2. Build and accumulate your own component library and quickly output prototypes
When it comes to rapid drawing prototypes, you can definitely think of using the component library, after all, the prototype is actually built from a variety of basic components, if you haven’t used the components yet, I recommend you must try it, find a lot of them on the Internet, and no one who has used them doesn’t say good.
After all, we may not meet the front-end specifications when we paint ourselves, or we may not be as beautiful as others after spending a long time painting, and since there are seniors who are willing to share the fruits of labor, there is no need for us to remake the wheel.
But I need to remind you that you must build the component library you are used to!This component library can be one, it can be multiple, you can organize it or keep someone else’s, provided you are familiar with these components.Ensure that you find the most suitable component as quickly as possible when you need to use it.There are so many resources on the Internet, if you don’t convert them into your own, you will find that you will be extremely entangled in the process of use, which is contrary to our original intention.
At the same time, it should also be noted that if you join a new unit, it is best to ask your seniors if they have their own component libraries, or ask about the frameworks used in the front-end, you can build and enrich your knowledge base according to these two directions. Each major manufacturer has its own component library, such as Tencent, Ele.me, JD.com, Youzan, etc. have established their own component library, and our company uses Ant Design more often.
3. Use PRD structural thinking to achieve efficient transformation
Both prototype diagrams and PRDs are aimed at accurately conveying requirements, but prototype diagrams focus on visual transmission, allowing team members to verify whether the entire requirement can be effectively solved at the same time through page elements and logical organization. The PRD document focuses on requirements guidance, that is, “aligning” all the relevant people in the team so that the product manager can also have clear guidance and reference when he is not around.
Do you have such a question, which one do we write about prototype drawings or PRDs? Do you need to write it? How to write efficiently? I used to write these two things separately, until a developer suggested moving the PRD to the prototype, and I started to reflect on this approach. In fact, we will find that developers will choose a more time-saving way, they either only look at the prototype drawing, or only look at the PRD, there are very few people who read both, plus the prototype diagram and PRD need to be read together, which invisibly increases their reading difficulty.
thereforeMy suggestion is to take this graphic combination of “embedding PRD documents into prototypes”From this point of view, then our prototype should add revision records, professional terms, product overviews, function lists, product flow charts, detailed function descriptions and exception handling to the prototype in the form of text comments, so that the development can directly see the prototype, and we can also directly extract the content from it when writing PRD. After all, in the era of agile development, high efficiency is king!
4. Use unified components and styles to ensure the unity of the team
B-end products generally have a product team, thenThe first thing is to choose a prototype tool that everyone sharesFor example, our team uses axure, and a colleague used sketch before, which leads to an additional conversion when the final draft or sharing, which is very troublesome. Now we have a lot of prototype tools available, and most of the software is becoming more and more mature, the original axure, to the current copying RP, mockplus, ink knife, pixso, etc., just choose one that everyone is familiar with.
Secondly, it is important to establish the components and style of the team, which can be done together with the interaction designer/UI designer.We didn’t pay attention to this before, until the customer pointed out this problem to us, the overall problem seemed unprofessional, after all, the B-end is the enterprise/economic organization we are facing, and it is very important to maintain a professional image. Therefore, it is necessary to unify the overall prototype style, preferably with a set of mature components, such as overall layout, color size, pop-up window, general class interaction, etc., so that it can be fast and good.
The above points are based on personal experience, and I hope that there will be more different opinions and exchange and grow with everyone.
