Shulou(Shulou.com)06/03 Report--

This article mainly introduces "how to quickly change from requirement analysis to hands-on design". In daily operation, I believe that many people have doubts about how to quickly change from requirement analysis to hands-on design. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the doubts of "how to quickly change from demand analysis to hands-on design"! Next, please follow the editor to study!

Analyze the motivation of the demand side

The four most important roles in dealing with designers: product manager / developer / your immediate boss / designer members of your team, each has his or her own temper / style and level of blood, and everyone is doing things with a different purpose. Sharpen the knife without mistakenly chopping firewood, first understand the partners, and then understand their purpose of raising the demand, will make you get to the right demand point more quickly.

For example, it is estimated that everyone has met a product manager who is keen to change the demand. He drew half of the picture yesterday, but today he is going to change it again in fu*k!

A lot of iron juice at this time can not resist the impulse to lift the table to directly attack the product manager, but in fact, it is recommended that people understand the reasons for changing the demand before making plans. For example: did their boss temporarily issue a new order? If so, is it recommended that they submit the design after confirming the requirements with the boss, or they can directly communicate the seriousness of the problem to him with the overall scheduling delays caused by statistical man-hours and prd rework rate?

In the end, even if it really doesn't work, I suggest you give clear problem feedback to your superiors. A good superior can properly help you solve these problems that are difficult to solve. It is not recommended to stick hard in the group or give feedback directly to their boss, because it is easy to create a state of long-term confrontation, which is not good for us to do anything, and all communication is dominated by peaceful coexistence as far as possible.

For example, the boss asked you to make a design self-driving product optimization design solution ppt.

Before you get started, analyze what your boss does with this ppt. Is it to see you idle pain to find you something to do? Or test what you can do?

Obviously not likely.

In most cases, this kind of output has only one purpose: it is for the boss's boss to make him feel that the design team is actively doing something and doing something. So in fact, the real demand side of this ppt is not your boss, but your boss's boss (line of business leader: a person who may not understand design at all). At this time, if you focus on the details of the design and the beautification of the ppt, it is easy to lay down the gun, that is, it is better to be tired and half-dead (the real case around me).

Because people who do not understand design do not have much perception of these things. On the contrary, if you can focus on the combination of design and data, more pre-and post-comparison cases and design proposals for research will have a completely different effect.

Rapid positioning and prediction of new demand

Before starting the design, we can carry on the basic analysis and planning of the requirements. First of all, the order of magnitude / priority and scheduling of the requirements are defined, and then the upstream, middle and downstream members who need to participate need to be judged according to the actual situation of the requirements.

For example, here we have received a demand: a live app needs to add a type of live room (emotional worry relief program) to the original function.

So let's take a quick look at the prd prototype, with obvious experience changes in more than 3 core pages, plus N small detail states and three-level pages. Basically we can determine that it belongs to a medium-sized page, and if it is urgent, it will take about 3 days. From a prototype point of view, there should be a combination of interaction / ui/ operations to promote design / front-end + development.

Well, after understanding the staffing, the parts that need to apply for the help of the operation promotion design team need to be informed in advance to the corresponding responsible person for scheduling in advance, and the specific implementation of some pages should be communicated with the corresponding technical juices in advance under uncertain circumstances.

For another example, here we want to continue the experience of immersive black panels in app, so the newly released story also wants to make dark panels that are different from conventional white.

But in fact, this new story release page belongs to the non-native native H5 page, which is operated by the front-end iron juice. it is not like the original page can directly set the default background color. At this time, many technical iron juices choose to directly ignore this problem to develop, or directly tell you that when you enter the page, there will be a white flash, Bart, can not be solved. Next, many designers will choose to rework and change the white version.

However, a more efficient and high-quality solution suggests that we first take a look at whether there are cases of solving problems in the same situation in Jingpin and their own app. Taking them out will be more convincing. Usually, they will try to solve things that are not particularly difficult, and you will also reduce feedback to ensure the user's experience.

A lot of iron juice here may say that if you bibi with them for a long time, you may have to change the manuscript in the end, which is not as fast as if I change it directly. So the question comes back to the first point, you have to understand the nature of your partner / demand side, whether this communication is necessary under the premise of determining efficiency priority, and how long the communication time range is the most cost-effective.

When the competitive product analysis is done, it is the AK47 sight.

Many iron juices want to know what methodology to use to control their own output, in order to achieve professional norms and be able to convince others. In fact, whether it's the kano model for analyzing requirements priorities, the double diamond model for big project problem mining, Nielsen's ten interaction principles or the gestalt principles designed for typesetting, you will find that they are like a warrior fighting on a real battlefield with the feeling of a gorgeous song and dance show fake knife.

The reason is simple, because they are all general methodologies. In practical work, the projects we encounter are usually urgent and have different demands, and the general methodology is only a kind of knowledge reserve for us, which will produce basic positive guidance to our design when we start the design, and help us avoid some low-level experience errors, such as inexplicable interactive gesture design, or and WCAG visual design with large color contrast deviation.

But if we want the quickest and most accurate remedy to the case, there is only one core weapon-competitive product analysis. The competition here is not exactly the same business model as your product, even if your home is a 0-1 product innovation, there is no vertical competition to refer to, and you can dig up a lot of similar product analysis details.

While analyzing the ui and interaction of the competition, you can quickly get to the validated design, and you can also add a lot of "unwritten" experience, such as why some details are such a design, go to Duniang to search for the reason, to ensure that your experience value has increased by 1%. At the same time, it is a relatively low-risk thing to use the experience of many trials of online products as a scheme reference, which is also persuasive for products and technology.

But there is a special thing to pay attention to here, a lot of iron juice to do competitive product analysis to do turned into a copy of the product?

In fact, no innovation is really from 0-1, even if the creation of the car is also based on the carriage, so how to effectively do competitive analysis, green from the blue is better than the blue, is a very big issue.

To put it simply, it is divided into three steps:

Determine which products are vertical competitions and which are similar products

In-depth analysis and comparison of multiple vertical competitions (frame / interaction / visual style of specific modules)

Combined with the communication with the product, judge what kind of upgrade or transition belt is more suitable for the design of your own product.

At this point, the study on "how to quickly change from requirements analysis to hands-on design" is over. I hope to be able to solve everyone's doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.