Example: How to design an operational activity H5?

This article can meet the following needs: Want to know the detailed design ideas of the product from 0 to 1? Want to know how to implement the activity H5 proposed by the operation ? Deconstructing a real case? What work is done before prototype and PRD?

Recently, a friend who works in operations wanted to follow up on an H5 event of the company. It was his first time to interface with the product, and because he wanted smooth communication, he asked me to recommend materials for learning about the product.

There is a lot of information about product methodology and design, but considering that it is only a short-term task, I regret to say that there is not much suitable. Yes, classic materials such as iOS Human-Computer Interaction Guidelines, Revelation, User Experience Elements, don't make me think, and Liang Ning's Thirty Lectures on Product Thinking cannot help people get through the rush of the initial semester.

There is very little real systematic information from zero to one, and those that do exist are used to teach courses to make money, and the quality varies greatly.

Even for online courses, when I was studying the three-month Tencent Classroom's introductory practical class for product managers with a lineup of BAT mentors, the question most often asked by my classmates was always the same question: Are there any cases? You can refer to other people's problem-solving ideas in this case and correct your own thinking. But there are very few complete cases, and they are often incomplete. In this case, I might as well write an article to explain it directly.

As a high-frequency demand of operations, activity-related demands have clear planning purposes, a complete life cycle, independent logic, and flexible and changeable forms. When designed, they are close to being a small product and are also suitable for use as cases.

This article will use actual activities to demonstrate how an activity-type H5 goes through many twists and turns from a paper plan to a finished product.

Project Start

Daily products.

The operator sent a word document to me on QQ, saying that he wanted to make an H5. When I opened the document, I saw that it was an activity planning proposal , as shown in the figure below. The point is, this is not a simple activity plan.

For simple activity plans, the operation can solve them by itself with a poster; however, if it involves limited registration conditions, display of personalized user information, data collection, online scoring, real-time data updates, activity status changes over time, user interaction, and multi-page conditional judgment switching, especially when more factors overlap, this kind of comprehensive consideration work should be decisively handed over to the product manager.

In terms of the main process, whether you rely on your own thinking or on reference, if you are careful, you can indeed produce something that is almost perfect. However, untrained people do not even consider or even realize the abnormal processes, branch processes and reverse processes that arise as a result. Leave professional matters to professionals.

Let's take a look at this document as a starting point for requirements:

Event Planning

This document is pretty much the same as the actual one, with only some non-product-related elements removed. For this kind of certain demand, you can save some time on distinguishing true from false demands and focus on the productization of the demand.

What information can you get from reading the text?

At least we know that this is a competition event with active anchors, with audiences collecting tickets and voting; and anchors competing for rankings, choosing prizes, and getting fish and bean bonuses.

Before talking about how to communicate further details with operations, let me first briefly introduce the background at that time and have an overall understanding of the industry, users, products, and functional modules.

Project Background

Our product is a platform-based APP in a niche field. Its user group is leisure fishing enthusiasts, mainly male users. It is a scenario-based service platform for C-end users (similar to Yuepaoquan and GOSIK). It has a live broadcast module for social interaction and is trying out a mall for commercial monetization.

Different from the live broadcasts by ordinary people, our live broadcasts are limited to fishing themes, tend to be outdoorsy, and are more active in spare time. Therefore, the design of the live broadcast room is not particularly fancy, and it focuses on configuring regular interactions, such as: red envelope distribution and gift rewards. Live streaming emphasizes real-time and interactivity, and daily activities require cooperation between the host and the user.

Fish beans are virtual currency. When the anchor receives gifts, they will be converted into fish beans according to their value. Fish beans can be withdrawn into RMB, which is the anchor's business line.

Determine the need

After understanding the background, let’s return to the present. Now that the operation has handed the activity plan to you, what should you do next?

Many people immediately draw a prototype and come up with a plan.

No, don't be silly, the prototype you draw immediately at this point is just a fantasy prototype. When you proudly deliver the documents, all you get is deep contempt from operations and technology.

So what should you do at this point?

You should understand the whole picture of the matter in detail. No one can transmit all the information at once, and even if they could, no one can receive all the information at once.

Don't believe it?

Regarding the loss in the communication process, you can read the previous article [From the underlying logic to practical application, what kind of communication skills should a product manager have? 】

The activity plan only mentions necessary information, and at most you can get some basic understanding, which is a phenomenon. You know nothing about the considerations behind the phenomenon. Therefore, we must strike while the iron is hot and work with the operation department to fully understand the ins and outs of the activity plan, the steps, precautions, and role behaviors...

To what extent do you understand?

The ideal situation is to be more familiar with the plan than the operations department.

1. Clarify the main process

To understand the full picture of things, you should start from the macro to the micro. The first step is to understand the general direction and main process, and the details can be left for later. Because communication does not happen just once or twice, it will run through the entire design and development process.

Understanding the purpose means grasping the general direction and principles in design.

The purpose of this activity is to use active anchors as the main thread and improving welfare as the driving point. In this process, it will stimulate user activity (saving tickets, voting) and conduct commercial trials (anchor gift packages, live broadcast room gift packages).

Therefore, the main process is: anchor registration - audience collects votes - PK on game day - Top 10 anchors are shortlisted - gift packages are selected - gift packages are posted - anchors collect points - rewards are given for meeting the standards.

2. Streamline business processes

This is just a rough understanding of the main process. We will further work with operations to sort out the sub-processes and branch processes of the main process. The advancement of the process depends on the roles, so the key steps of the roles must be determined.

The coordination and interaction between roles can be more intuitive and clear if displayed with graphics. A picture can solve a thousand problems. The host-user task flow chart below organizes the unclear main process into different role lines.

As you can see from the picture, the anchor line is the main line and the user line is the auxiliary line. The design takes into consideration how the scattered auxiliary lines can be integrated into the main line.

Business process diagram

3. Scenario Simulation

The business process can be complex or simple. After drawing it out, you can know that the competition of the event falls in the first half, and the second half is the way for the anchor to make money. If you play out the scenario a little bit, you'll find some unreasonable points.

The anchor can always be driven by interests. There are prizes for being shortlisted for the competition, and they can continue to earn high commissions after being shortlisted. But on the user side, after they reasonably push the anchor onto the list out of a sense of honor, they no longer have any reason to provide subsequent support. After all, watching live broadcasts is an entertainment activity in itself, and talking about making money goes against the original intention.

So, at that time, I suggested changing the event to a two-stage competition system. The shortlisted anchors would compete on the same stage. In order to create a sense of compactness and provide real-time feedback, the list would be set as a weekly list, and fish beans should also be increased on a weekly basis.

Operations quickly accepted the suggestion and implemented the new solution.

Requirements can be changed, but in order to achieve more effective results, it is best to have reasons and solutions. As the person in charge of demand productization, everything is about user experience, and you are obligated to improve the plan for operations.

During the scenario simulation stage, you can use a mind map to sort out and analyze ideas as shown in the picture, recording them without duplication or omission. Imagining their concerns from the perspective of the persona will help you arrange the information architecture.

Demand analysis and sorting

4. Functional structure

Once the plan is given, the requirements, business processes, and scenarios are determined, you can take a break from the discussion with operations and focus on turning ideas into plans.
Different companies have different documentation standards, and different product managers have different working habits. There is no fixed method for a product, but a successful document is one that can basically fully realize your ideas and designs.

Convert ideas into specific functional points, which can be expressed using a global functional structure diagram. Always remember to use the MECE principle to sort them out to ensure logic and completeness.

It can be seen from the figure that the functions of the client are respectively undertaken by the H5 side and the APP side. The APP is slightly adjusted to borrow the existing live broadcast room interactive functions. The H5 side is a page designed from scratch that displays real-life activity information and progress details. The backend cooperates with client modifications to add gift package management and data export functions.

Global functional structure diagram

Some of you may find that the nouns are inconsistent. This is the version after the theme and creativity are determined.

Generally speaking, if operations require it, the activity plan should determine all possible parts before handing it over to the product. But because I am the best copywriter in the team, the operation team felt confident in handing over the creative and copywriting parts to me (the activity theme has always been empty in the plan). I finalized it when I was making the product plan, but for the consistency of the document, the final version is used here.

This is about team members complementing each other's strengths and showing their best abilities. If yes, that’s great; if not, then everyone should do their own job.

Product Solutions

The transformation from abstract functional points to technical executables is achieved through prototypes and product documentation.

After the product plan is established in the form of a prototype, you can go over it with operations and technology. After ensuring that the requirements are met, the technology is feasible, and the cost is reduced, it will be handed over to design, testing, and development. If any problems are found during this process, they have to be modified back and forth until there are basically no objections. Other documents will need to be completed later.

The prototype is the most critical part of the product documentation. Due to the product form, complexity, and development progress, other types of product documents may have some trade-offs, but the prototype is indispensable. It shows the final form and function of the product and is the consensus of everyone's communication, especially in a small team.

1. Overall concept

In this design, the effective action of the activity is the interaction in the APP live broadcast room, while the activity information is on the H5 end. When designing, pay attention to the linkage of information on both ends. The related background functions are omitted here.

The connection point between APP and H5 is the advertising space in the live broadcast room and the banner advertising space on the homepage.

Main interface of App and H5

The home page banner obtains user information, while the live broadcast room H5 page obtains the competition information of the current live broadcast room host. Whether it is the anchor or the user, switching H5 in the live broadcast room will interrupt the current process.

Therefore, when designing H5, information should be highly concentrated on the main page, reducing the hierarchy, ensuring that information is at hand, and shortening the search time and steps. Some information that emphasizes real-time nature will also be reported in the form of messages in the comment section of the live broadcast room, reducing the need for users and anchors to frequently switch pages to view information.

2. H5 event page

The overall framework of the H5 activity page is flat. It follows conventional practices to reduce learning costs, placing relatively low-frequency information, rewards and rules on the second level, and high-frequency rankings and anchor progress on the first level.

Let’s take the anchor information column and the list as examples to explain the design ideas.

(1) Anchor information bar design

The anchor information column has more functions than the list and is the information that users and anchors care about first. In fact, if you understand the two-stage schedule, multiple states, multiple score statistics, and fish-bean ratio bonus, you will know that the design of the anchor must be more complicated, but these complexities should be left to designers and background programs as much as possible, and users should follow the principles of simplicity and necessity at any time.

1) Unregistered - Departure Period

The design of the anchor's status information bar is explained in stages. The first stage is presented first. The order shown in the figure below is: unregistered -> start period - non-match day -> start period - match day - Top 10 -> start period - match day - non-Top 10. (Registration success or failure, reasons for failure are not displayed here)

Design ideas:

1. The status bar shows the host's current schedule, with two states: Hard work to set sail and Long voyage to find treasure;
2. For non-registered users, the prizes, rules and registration deadlines;
3. Registered newbies should pay attention to the current task. Before the competition day, they should canvass for votes and accumulate votes. The rules for accumulating votes are that only Saturday is the voting competition. The rest of the time, users need to watch the live broadcast to accumulate votes. Here, you can remind the anchor and fans at the same time;
4. Pay attention to your own ranking and progress. For Top 10, pay attention to the gap between yourself and your nearest competitors. For non-Top 10, pay attention to the gap between yourself and the tenth place. The display items will be different.
5. There is no need to distinguish between the visible information of the anchor and the user.

Anchor Information Column-Not registered for the start period

2) Voyage period - activity ends

The order of pictures in the second stage is: long voyage period - user version -> long voyage period - anchor version - details collapsed -> long voyage period - anchor version - details expanded -> end of activity.

Design ideas:

1. The detailed information of fish beans is only visible to the anchor, so in the long-distance stage, it is necessary to distinguish between the user version and the anchor version;
2. The focus of the sailing race anchor is all on fish beans, so you can directly see the fish bean rewards for this week;
3. Fish bean bonus is the final result. Based on the fact that our users are very particular, in order to reduce the foreseeable explanation work, the conversion relationship here should be clearly expressed, from the starting point to the end point: weekly score - score fish bean conversion ratio - basic fish bean multiplied by the ratio - reward fish bean;
4. Wherever possible, use charts. One chart can solve a thousand problems. Pay attention to clear visual clues and use partitions to represent data points when there are many data points.
5. Add rule jumps in places where users will be confused. The fish bean mining guide here is part of the original rule description.

Anchor information bar-the voyage period ends

3) Even if the full process of the anchor is used to illustrate a state of the anchor bar, the prototype diagram captured above is only a part of it. The complete process can be seen in the anchor bar page flow chart - anchor version below, which will complete the branch processes and abnormal processes that are not shown in the above picture.

Anchor bar page flow chart - Anchor version

The anchor information bar process is relatively complex, with a large amount of information, divided into role perspectives, and has a complete life cycle. With the explanation of prototypes, page flow charts and design ideas, by now you already know how a small product is formed.

However, the design process is not always smooth. Even with sufficient communication in the early stages, it is inevitable that the demander will change or supplement the requirements when the prototype is reviewed. The next part will introduce the issue of changing requirements by taking advantage of the design of the voting list.

(2) Voting for the Sailing Start List

The anchor information column adopts the form of two lists, because the list is not in line with the anchor's timeline. Qihang and Yuanhang overlap in parallel for two months. It cannot be assumed that users only follow one anchor, so the layout is parallel with two lists.

The design of the first list - the Voting Start List is quite special. It was originally a regular vertical list of this week's list and last week's list. However, when the prototype is being tested, operations hope to weaken competition. The reason is that the last ranking competition caused unhappiness among the anchors, and there was also feedback from the core user group.

Do you remember the purpose of our event? It is not to select the most popular anchor, so it can be changed.

problem:

Although the demand is correct, it is difficult to meet:

1. The weekly Top 10 + 500 votes rule remains unchanged, which means everyone must see the Top 10 directly;
2. Downplay the competitive factor and apparently weaken the ranking of the list;
3. Streamers and fans must see the real-time rankings to decide their own actions;
4. The list is not based on a passing system, but a ranking system. It is impossible to determine which contestants are the winners until the last minute...

In essence, in a place where lists and real-time rankings must be presented, the requirement to weaken the rankings is a bit like colorful black, isn’t it?

Solution:

The final solution is to move the ranking gap between the anchor and the fans concerned about it to the anchor status information column; and the list will be changed from a vertical ranking of all anchors to a horizontal scrolling area that divides the Top 10 into independent areas. Because the most intense competition is right at the top. For platforms and anchors, entering the Top 10 is enough; the ranking doesn’t matter.

In order to give the Top 10 horizontal scrolling area a legitimate start, combined with our user base and product features, the first stage is creatively defined as all anchors competing for ten tickets each week (weakening the rankings), and the scrolling area is defined as the area for competing for starting seats. The UI design uses a ship-borne image to reinforce cognition. The anchor who is still in the ten seats at the end of the game will be the winner and can set sail successfully. Entering the second stage, sail out to sea, sail far away to search for treasure, and mine the fish bean treasure mine.

(PS So this operational personalization limitation finally completed the creativity and theme of the event)

Finalization of prototype:

The design ideas are:

1. The score statistics for the competition are closed at 12:00 on Saturday, and the new competition week starts at midnight on Sunday, so in addition to this week's ranking, last week's ranking is also required. Last week's ranking only needs to show the anchors who successfully started.
2. This week's list is divided into the starting seat competition area and the general vertical list area, which directly widens the gap between the quasi-Top 10 and other players;
3. All live contestants are marked with live broadcast icons, so users can quickly join and cast their votes;
4. The most intuitive thing for the Top 10 is their own ranking (not shown here). The other Top 10 are not clear at a glance, which weakens the ranking competition;
5. For users who want to check the details, they can manually scroll the seat competition area to view the details;
6. Because the threshold for Top10 is 500 votes, the actual number of people may be less than 10, so the value of No.11 in the vertical list area needs to be controllable by the server.

In fact, design ideas are reflected everywhere in functional structure, process, and page prototypes. They are included when outputting documents and do not really need to be written down. However, the design must be reasonable, and you must have a clear idea of ​​it so that you can answer and write it down when other colleagues ask for clarification.

3. APP

APPs all make good use of the existing live broadcast room functions. Since the activities are phased, they try to minimize the impact on the logic of the original APP. While meeting the needs, they consider the technical costs and reuse existing modules.

On the APP side, we should pay attention to directing traffic to the H5 activities, and provide guidance and reminders in the comment area and gift reward area before, during and after the game. We should pay attention to balancing the mobilization of potential participating users and preventing disturbance to uninterested users.

Some prototype images of the APP are as follows. The overall text and pattern are consistent with the theme style. The clicks and non-clicks of designated gifts in the gift area reflect the progress of the activity and provide good guidance.

The other parts of the product plan are also formed according to a similar process and will not be listed one by one. If necessary, a link to the finalized prototype will be provided later.

Development and launch:

After the prototype and related documents are confirmed with operations and communicated with technology, they can be delivered to the next step: development.

Next, follow these steps to proceed:

1. Maintain close communication during the development period and pay attention to the modification suggestions from developers;
2. Before going online, test whether the acceptance requirements are fully met;
3. After going online, maintain close communication with operations at each important node to pay attention to whether the behavior and data are normal;
4. After the event, review the process, summarize the experience, and improve it next time.

Going online is the touchstone for testing a product. After going online, there may be both small and big problems. As for how many, it depends on many factors and the team. Of course, if you have aspirations, at least you should reduce the pitfalls in the links of responsibility and handover. Improving strength is always a person's fundamental quality.

Conclusion

So far, you have witnessed the life cycle of an activity H5 from 0 to 1 to 100.

No matter whether the project starts from an idea or an activity plan, no matter whether you participate in the discussion in the early stage, as a product, before starting product design, you must first understand the needs of the demander in detail, then sort out the business process, convert the needs into specific functional points, globally arrange and allocate functions, draw prototypes, confirm with the demander that the plan meets the needs, and then deliver the final version of the prototype, flowchart, mind map, text, table and other product documents to the technical department. After that, we will follow up on the product implementation and launch, and the work will be considered to have come to a temporary end when the final implementation effect is consistent with expectations.

Regarding modifications and changing requirements, the earlier they are proposed, the better; and the earlier problems are discovered, the better. A basic point is that once a project enters the development phase, it cannot be changed at will. This is especially true towards the end of the development phase, unless there are critical logic or major issues.

After reading this article in its entirety, you will have gotten started, but there is still a long way to go to advance and improve.