What should we do if we are rushing to complete a B-side project and don’t pay attention to design?

In B-side projects, this problem often occurs: as a developer of a new project/new function, he will give priority to product functions and ignore the restoration of the final page presentation, which is often referred to as "function first", and the design draft is often not restored. When we encounter such a situation, how should we deal with it?

I believe that many B-side designers will encounter this kind of problem in their work, so let’s talk about what to do when the project itself does not pay attention to design?

Value Yourself

I have seen classmates complain that the design page restoration is very bad, which makes him unwilling to spend more energy on the design page, and then he often does nothing in the company (mo yu)

The first thing I want to tell you is to value yourself, because many designers will give up when they encounter this kind of situation, and will not pay too much attention to the acceptance of page details (designers will say: they will not change it even if it is brought up, and they don’t want to bring it up again later). The result is that as time goes by, if a page lacks 20% of the design details, ten pages, fifty pages? Maybe it will be a disaster.

Therefore, when design is not taken seriously, the first thing to do is to pay attention to yourself. Be attentive and responsible in work output, and take requirements and design acceptance seriously, because only when you do it well, you can ask other members of the team to assist you.

For example, after a version is completed, assign different design details to different front-end engineers, and clearly mark various design details on the page, so that R&D colleagues can know your attitude towards work. A project team will definitely not hate a serious and responsible person.

Ask a question

The above problems are actually caused by "project rush". I have had in-depth discussions with many developers about this kind of problem. They don't want to make things difficult for us. It's more because they don't have enough time to develop the project functions, not to mention the design details.

At present, most teams still adopt "agile development" for project development (which is contrary to waterfall development. If you don't understand it, you can search Baidu). Therefore, at the beginning of each iteration, you can communicate with the project leader to clarify the specific time and requirements for restoring design details.

In this way, we can clarify the project design requirements with everyone at the beginning of the project. For example, this issue is indeed more complicated in terms of functions. In this way, designers also know the overall situation of the project and can appropriately relax the requirements. How to relax them? We need a relatively quantitative standard for page restoration.

Page restoration criteria

[[425212]]

Setting a basic standard for page restoration is essentially to help developers have a deeper understanding of design details. Often you will find that they are not aware of some obvious errors, such as light gray and white, which are similar to them in terms of perception. Some small details are difficult for developers to observe, but through a standard, they can check their pages to see if there are any problems, such as:

Basic stage:

Page layout, color values, font size, control usage, and missing key elements

Intermediate stage:

The thickness of the stroke, the distinction between detail and background color, and the blurring of design resources

Advanced stage:

Control effects, page content copywriting, prompt information...

Of course, this is just a simple example. The ultimate goal of specifying page restoration standards is to enable developers to have quantitative standards so that they can have a better attitude towards designers and design details. And the determination of standards can help you clarify iteration standards in meetings and further improve the efficiency of collaboration between teams. People always make mistakes. For example, I occasionally make typos when writing articles. Therefore, we must understand each other after being strict.

Of course, in addition to standards, Design Token can also help front-end developers quickly understand basic styles. I will talk about it separately later.

Clarify the time for subsequent iterations

After we first do our best, then raise questions, and then determine the restoration standard, the most important thing is to know when the remaining problems should be improved after a version.

There are usually two different scenarios for resolution time:

• In the next 1-2 versions, iterate and solve the previous problems
• Summarize the problems and then make a major version update to improve the experience

There is no good or bad difference between these two methods. For us, we need to summarize various problems in design details, and also require designers to have their own design experience demand pool:

Typically, this type of demand pool includes the following types of issues:

• Problem description, problem picture, responsible front-end, and subsequent iteration time, etc.
• After such problems occur, it is possible to determine the developer responsible for the problem and the subsequent time. After all, spreadsheets are the most useful tool in project management.

Sincere communication

When you encounter problems in a team, you should consult and communicate with team members. Because we are all colleagues, communication and problem solving is the way adults do things. For example, you can have a meal and talk about the problem, go downstairs to smoke and chat together, and occasionally buy a cup of milk tea to reward the front-end students who have worked hard to restore the page. Sometimes the tense atmosphere can be relieved by a joke or two. I hope everyone can work smoothly and have fewer troubles (in the next issue, I will recommend a few plug-ins to make the page acceptance go by so fast~)

In the comments section, what weird things have you encountered in actual projects?