Why do you keep revising your design? These 4 methods can help you pass it in one draft!

In actual work, most designers often have to revise their design drafts again and again, becoming exhausted and even doubting their own design skills. Why is this? And what are the solutions? This article will answer your questions.

It seems that the job of "design" can never avoid the stage of "draft revision". Even the best designers will seek changes in their own practice without compromising for the client or external reasons. However, "design revision" may not necessarily get better and better. If the communication is not appropriate, the result may get worse and worse. Therefore, as designers, on the one hand, we should absorb different opinions, and on the other hand, we should comprehensively improve our knowledge structure and stick to our principles.

Next, let’s take “UI design” as an example to analyze the problem of “repeated changes” in our daily work. In actual work, UI designers usually face opinions from bosses, product managers, operators, developers and other parties. They often have different opinions and endless arguments over issues such as font thickness, spacing, color selection, etc., as shown in the figure below:

Why is this so? In fact, in UI design, there are three main situations for frequent revisions:

• *** Type: Inadequate communication with product managers leads to misunderstandings and directional errors when meeting their needs. This is a problem of information transmission.
• The second type: The designer’s lack of experience and limited design capabilities lead to the product manager’s needs not being met to the fullest extent. This is a problem of the UI designer himself.
• The third type: The UI is halfway done or has already been output, but the product requirements have changed. This is a problem of uncertain requirements of the product manager or boss.

In view of the above problems, how can we avoid falling into the vicious cycle of frequent revisions in actual projects, so as to improve work efficiency, promote project progress, and enhance our sense of accomplishment as a designer?

Understand the workflow and maintain all-round communication

First, let's understand the workflow of UI design. Only by knowing the process of your position can you better grasp the design. The type and size of each company may be different, but they are basically the same, which is nothing more than 5 stages: demand - design - development - testing - launch. If divided by position, it is: product manager - interaction designer - UI designer - front-end and back-end development engineer - tester - product launch.

Therefore, our UI designers are in the middle of the pipeline, connecting with products upward and developers downward. In this process, we need to reduce the frequency of design modifications:

It is necessary to clarify the needs of product managers and visualize the prototype requirements accurately and appropriately;

Next, we need to consider development implementation and time cost. Because if a design is very gorgeous, but it cannot be developed and implemented or is difficult to implement or the time cost of implementation is very high, then we will definitely need to adjust the design plan and adopt a compromise solution.

Therefore, if you don’t want to have to revise your design again and again, you must communicate more comprehensively and never work in isolation.

Determine requirements and thoroughly understand interactive prototypes

After receiving the product prototype, the UI designer must clarify the following points before starting the design:

1. Is the prototype finalized? Will there be any changes?

After we receive the interactive prototype submitted by the product manager, we first confirm with the other party whether the received requirements are complete, whether it is the final draft, and whether there will be changes. Generally speaking, the processes in large enterprises are relatively standardized. After the product manager outputs the final prototype, the possibility of later changes is low. However, in small and medium-sized enterprises, there is usually a high possibility of repetition due to tight project time and imperfect processes. For some large requirements, product managers may transfer them to UI design in modules or a small part. This will cause many problems and hidden dangers, because product managers with less experience have poor overall concepts. Although they say that this part of the requirements has been perfected, in fact, when all the requirements are summarized, it is very likely that they will need to be adjusted again. Therefore, as UI designers, we try not to accept prototypes that are partially output. We need to confirm again before we start designing, so as to avoid changes in the prototype requirements causing changes in the design.

Another point is, when the product manager gives us the interactive prototype, do we passively accept it, or can we participate in the demand communication in time?***During the review stage of product requirements, the corresponding UI designer can actively participate in the discussion and communicate together. On the one hand, he can be familiar with the whole process of product thinking, and on the other hand, he can find problems and make suggestions in time from the perspective of design in the communication of the prototype, avoiding the embarrassment of modifying the prototype after it is finalized.

2. Project duration

After receiving the prototype of the product, you must confirm the time period of the project in a timely manner. Usually the product manager will take the initiative to inform the project cycle and ask about the completion time of the UI design. We give the estimated time of UI output according to the complexity of the requirements, and then divide the workload completed each day according to this time node. If the time period given by the product manager is relatively short, then explain the reasons as much as possible to apply for design time. If the time is too rushed, there will be less time for design thinking, and it will be difficult to consider the issues comprehensively, which is not conducive to the best presentation of the interface effect, and there is a high possibility of subsequent revisions.

3. Clarify the design intent and handle the information hierarchy

When receiving a product prototype, you must clarify the design intent and handle the information hierarchy well.

When the product manager submits us the confirmed demand prototype, do not start designing blindly. UI design is not a simple arrangement of the prototype framework. We need to clarify the design intent, be familiar with the functional architecture, master the interaction logic, understand what problem the product manager wants to solve, to what extent, and the specific design direction.

The issue of information hierarchy seems to be often mentioned in our actual work, but it is still a bit difficult to achieve the appropriate standard. To accurately grasp the information hierarchy of the interface, you need to communicate with the product manager in many aspects, because sometimes what we think is not what the product wants, so we must confirm it many times to accurately grasp it.

Key points of the changes:

• The pictures are arranged in a card-like format with blank spaces around them, making the interface more transparent, enhancing the sense of breathing, and concentrating the visual focus;
• Optimize the display of titles and topic tags, and use text size and color depth to differentiate the hierarchical relationship between topic text and topic tags;
• Follow the icons with the real-time number of popularity, likes, comments, and reposts to increase user participation.

Compare multiple design drafts to make each design reasonable and well-founded

In the actual design process, when you are unsure about a design module, you can create multiple artboards in Sketch or PS, lay out several different design plans, and conduct visual comparison and analysis. If you are not sure, you can ask team members or "novices" from other departments to vote or make suggestions for improvement. Don't underestimate "novices" and don't think that they don't understand design and their suggestions are useless for design. In fact, the ultimate goal of our design is for people to use, and it must be easy to use, so we must combine the multi-faceted opinions of novice users to make our design more worthy of scrutiny.

The above picture shows that when the author was unsure about the effect of the personal center interface, he laid out multiple effects for comparison. After the comparative presentation, he can clearly judge the problems of each interface.

In addition, in UI design, don’t just stay on the surface and don’t simply judge it by “good-looking or not good-looking”. In the design process, our interface layout, color control, character spacing, icon settings and other aspects must withstand scrutiny: Why is it designed this way? Is it appropriate to change the design?

Only when every design has theoretical support and is carefully considered can the design be more practical, convincing, achieve growth in the product index, and better reflect the designer's value.

Focus on products and respect the positions of all parties

When the design draft comes out, UI review will generally be organized. UI designers must express their design concepts clearly and convey the sophisticated ideas in the design to all parties involved in the review, which will make your design more convincing. If during the review process, the product, operation or development has different opinions on the design draft, we should not rush to deny it, but determine our position: everyone thinks about the problem with the product as the core, and don’t follow the crowd. We should know why they put forward this opinion, and whether there is something wrong with our design? Even if the other party’s suggestion itself is not desirable, you should stand from your perspective and explain it to the other party with your point of view. This depends on each designer’s own knowledge structure and theoretical support, so you must keep absorbing it so that your design can stand up to scrutiny.

The above are some of my relatively superficial summaries of my actual work. If there are any shortcomings in the explanation, we can discuss with each other.