How to improve the voice of B-side designers? Let’s see the analysis of the director of a large company!

The current situation of lack of voice

Let’s get back to the career issues of B-side designers. In our group these days, we have repeatedly discussed one issue, which is how designers can improve their voice and increase their approval rate.

[[412338]]

The main problems of lack of discourse power can be summarized as follows:

• During design reviews, it is difficult to convince the other party, and the final solution is often not what you want.
• The design style is not decided by the designer himself from the beginning, but is entirely based on the requirements of the boss and the product.
• Design cannot participate in the review, does not participate in the first-hand product solution discussion, and directly takes the requirements to work. Requirements change very frequently, but I think that design does not take much time and can be easily achieved.
• If you encounter difficulties in implementation, be guided by development requirements and cut down on design requirements.
• The boss doesn't care about the design, he thinks it's fine as long as it's made, and there's not even room for opinions or discussions.
• The development is not implemented according to the design draft, and the design is not done according to the corresponding parameters, resulting in a huge gap in implementation.
• The specific suggestions put forward were not taken seriously or adopted, and simply came to nothing.
• Design specifications are difficult to establish, and no time is given for construction, with the view that “it’s not like it won’t work”.
• …

It can also be taught for three days and three nights, and everyone can choose their own topic.

The lack of voice is one of the most serious problems in the B-end design industry, which is far more frustrating than the C-end product team.

Let's briefly analyze the difference between the two. The core reason is what I mentioned in the previous sharing: C-end products focus on growth, while B-end products focus on business.

C-end products focus on the number of users, length of stay, and revenue growth, so it is inevitable to consider user experience and satisfaction. Any team with a little experience will know that personal opinions cannot overcome the overwhelming negative reviews and user loss in the application market.

Therefore, in the face of unpredictable users, creating an excellent product will not be a one-man show work environment. It requires brainstorming. Not only does the product itself need to have insight, but the designers must also be able to fully understand the users from the perspective of experience and maximize the effect after the version is launched.

Although experience does not represent the whole success of a product, it is at least an important indicator, so designers are naturally the ones who need to be relied upon and have a certain say in the product itself. But on the B-side, the situation is completely different.

The B-end project is more of a tool attached to business operations, and most B-end products are designed to solve certain specific problems that arise in the business process.

For example, the goal of an HRM system is to make the talent management and recruitment of enterprises more standardized, streamlined and digital. The goal to be achieved is very clear, not the elusive C-end users. Therefore, the difficulty of implementation is often also very clear, that is, what kind of functions should be provided to enable these business needs to be met.

Unlike C-end applications, which have a relatively simple structure, B-end systems are often very complex in terms of development. Unlike C-end applications, it is not easy to practice the MVP minimum viable principle and release some simple versions into the market for testing.

If the B-side system does not build a highly scalable and sound bottom layer from the beginning, it is equivalent to cutting corners on building materials, adding countless hidden dangers to subsequent construction, and sooner or later the building will be destroyed and people will die, such as the recent landslide in the United States.

[[412339]]

Therefore, if you have some experience in B-side projects, you will have experienced the reconstruction of the entire system by team development, because the "shit mountain" of code written previously has accumulated to the point where it is simply impossible to maintain, so it is better to tear it down and rebuild it.

Therefore, the technical threshold determines that the overall development cycle of B-side projects is relatively long and difficult. This is not the most serious problem. The most serious problem is that for small teams, they are often grateful if they can produce the product on demand. Why expect to add a lot of interference factors in the middle to delay the progress of product development?

For many inherently complex industries, it is not uncommon for a B-end product to take one or two years to develop. Although this is often due to the boss's or the product's own lack of consideration, insufficient management skills and experience, it does not prevent them from understanding that the top priority must be to make and implement the product.

So, at this time, can you expect them to overemphasize design or experience and add unnecessary development costs to the project? Indeed, as long as they can achieve a state that is not unusable, they have already tried their best.

Furthermore, for these complex industries, the business itself is very heavy. It is an extremely chaotic and complicated process from organizing the business to implementing the needs. If your job is to look at a bunch of flow charts and logic diagrams every day, and then communicate with the developers repeatedly about the difficulty of implementation and explaining the product logic, it will basically drain all your patience and energy.

With this mentality, the person in charge will not want to waste time explaining the logic of the product to more people, such as explaining the reasons for doing so to the designer from the beginning, or discussing with the designer where a button should be placed and what color to use. The designer only needs to follow the roughly determined and achievable plan and not worry about anything else.

This is the fundamental reason why B-side project designers lack the right to speak. If the project experience, visuals, and interactions can be done to the extreme, no one would be unhappy. But the contradiction lies in that B-side projects have other important things that are higher than the job functions of designers and need to be implemented first, and then consider design. This is the real environment in which B-side teams exist.

Therefore, objective factors are there, which makes B-side designers have weak voice. So, can we really only be a puzzle guy?

How do B-side designers gain the right to speak?

The low voice of B-side designers is a growing pain in the industry's development process. Although this is an objective fact, it does not mean that as a B-side designer you will never be able to hold your head up or have no voice.

So next, I will share some suggestions on how to gain the right to speak on the B side, hoping to bring some effective help to everyone.

First, we need to describe a common B-side designer standard for regular projects.

1. Good visual ability

At the very least, the output quality of the page should be above average. Don’t let even the backend developers complain about how ugly your work is!

Step 2: Familiarize yourself with web standards

Especially for front-end specifications, it is very necessary to master the basic HTML+CSS, as well as have an introductory understanding of some basic frameworks to ensure that what you design can be implemented without the developer telling you that it cannot be done or the cost of implementation is too high.

3. Solid foundation of interaction

Have sufficient understanding of the usage and interaction forms of common management system components, and when formulating corresponding functional interaction processes, at least ensure that the processes are complete and logically rigorous.

No. 4: Component-based design thinking

It can integrate project reuse elements and specifications very well. Whether in terms of visual or development level, elements can be called by componentization to avoid reinventing the wheel.

No. 5: Smooth development handover

After the design is completed, the annotations and cut-outs can be reasonably submitted to the developer, allowing them to realize the style and functionality of the design at the lowest cost and fastest speed.

No. 6: Rigorous work attitude

This isn't a skill in the literal sense, but I'll bring it up anyway. B-side design involves too many trivial details, and if a designer doesn't take details seriously, he or she will inevitably make all kinds of low-level mistakes, such as typos, forgetting to modify elements, misaligned edges, and poorly cut canvases.

When a certain number of low-level mistakes accumulate, it is also a sign of poor work ability. According to my work experience and the designers I have observed, a rigorous work attitude is really a professional skill that needs to be cultivated and has a very high threshold.

If you meet the above points, you can be a qualified screw. Before fighting for the right to speak, I always suggest that everyone should first have the ability to be a good screw, or even the ability to be a super screw.

Because the necessary basic qualities are the guarantee for being able to speak with confidence in the workplace. Design is ultimately a service-oriented profession. If the quality of basic work content cannot be guaranteed, then no one can convince you. If you do not do your job well, the more you explain, the more noisy you will appear.

Think about it from another perspective. If you find a Tony to cut your hair, and the final hairstyle looks like the one below, it will be meaningless no matter how much he recommends eyebrow tattoos, highlights, or styling, because the trust is gone, and you will just want to break up with him as soon as possible.

Therefore, when you feel that you are not doing well in the above points, don’t be unwilling to be a puzzle worker. Do more and talk less, and delve into the details. This will allow you to make more progress.

As long as everyone has no objection to your basic level and has established trust in your professionalism, you will have the energy and qualifications to fight for your own voice. The following will further explain the source of voice.

There is no unified template for gaining the right to speak. As long as you achieve a fixed A standard, you can become the leader of the team. I can only provide a general idea, and you need to make your own judgment in the actual environment.

First of all, you as a designer need to have a full understanding of the key goals of the current project, or the expectations of the leadership, to help us change our way of thinking.

It’s not about “I think a certain style should be designed to make the product more stylish and better looking.”

Rather, it’s “the team wants to achieve a certain goal, how can I better achieve this goal through design implementation?”

For example, if the team hopes to launch the product next month, but the workload is very tight and some requirements are unclear, then the design must aim to save time and energy when submitting the proposal or reviewing it. When explaining the design, clearly provide the corresponding design reasons and reasons, how this can save the team time, and why not do another solution. Or even provide another solution, explain the pros and cons of this solution, and let the team choose.

The design solutions we provide must meet everyone's design requirements at this stage. This is a professional's "eyesight" to a certain extent, but it is not a purely flattering mentality. Because project development is a team work, heroism is not allowed. Your goal is to sacrifice a certain degree of self-awareness for the better advancement of the project.

In addition to providing basic solutions, designers need to have a deeper understanding of the industry and business model that the project is targeting. Many B-side designers have almost zero understanding of the business. This state is clearly visible to the boss and the product. If you don’t even understand the industry, how can you talk about what users think? Is it meaningful?

Understanding the business depends on whether the solution we provide can meet the needs of the business or whether it is irrelevant. This ensures that you will not appear extremely ignorant and biased in various meetings and communications.

Also, for the product level, you should be able to make your own judgment on what the demand is, effectiveness, and whether the logic is reasonable. It is not to let everyone really realize all the functions of a product manager, but to make you clear about what the product should do, how to do it, and the quality of the work. Only in this way can you form effective product suggestions based on the business.

Finally, it is about collaboration with development. A good product or design will fully understand the impact of its output on development. If the demand far exceeds the development level and energy expectations, it will inevitably lead to a rebellious plot in development.

Just like the boss asks the UI designer to make a Taobao store model, which is obviously beyond our own capabilities or expectations, and of course will make us extremely unhappy.

Therefore, every time before the project starts, senior designers will work with developers to plan and investigate the implementation boundaries of the design. Not all plans are given the lowest limit, but the design content is reasonably formulated according to the limit of the other party's expected energy investment to ensure the best results within the capabilities of both parties.

Many people have the misunderstanding that front-end developers simply disdain to implement visual layer codes and just like to slack off. But in fact, it is all the output of work, and every front-end developer hopes that what they write is both beautiful and easy to use. But in many cases, the solutions given by the designer are not only unconvincing, but also purely increase the workload, without considering the difficulty of implementation. Then he definitely does not want to bear such pressure and directly enters a state of giving up.

Designers and developers are both comrades in the implementation layer, and they are the ones that designers need to keep winning over. It is much easier for a reliable design to gain recognition from developers than a product (product discourse power also needs to be established). What designers need to do is to restore the interface in the most comfortable way within their capabilities, so as to fulfill their sense of accomplishment.

This includes many output factors such as interface style, componentization, naming rules, display methods, version management, and cutting standards. Designers need to formulate them according to actual conditions and there is no unified standard.

If you can do all of the above and continue to do so for a period of time, you will naturally begin to gain a say and begin to gain respect and attention from product, development, and your boss.

Summarize

Some people may ask, why does it seem so difficult? How good of a B-side designer can you be if you can accomplish all these?

That's right, this is why you need to use excellent professional qualities to fight for the right to speak. The right to speak is not only for designers, but also for product managers and front-end and back-end developers. In a team, apart from force majeure such as the boss himself, the boss's relatives, the investor's insider, and the client's father, the right to speak is acquired by those who have excellent abilities and can make accurate and effective judgments on products and projects.

Throughout my career, I have seen many bosses and products in a weak position. Why? Because their professional qualities are too poor and they cannot control design and development. Every product review process is a public punishment by other team members.

Therefore, gaining the right to speak is a process of convincing them with facts and professional ability, and effective persuasion must be based on the overall context of the project rather than considering it independently from a design perspective.

People with high or low professionalism will generally respect other people with high professionalism. A team is always in a situation where everyone dislikes each other, blames each other and is in opposition. Usually, neither of them is highly professional and no one can effectively convince the other. This kind of scenario is called - noobs fighting each other.

The more this happens, the calmer you should be. Don’t worry about how others view you now. At least you should have the confidence and motivation to fight for how they will view you in the future. If your work environment cannot be changed, you can try to change companies and continue to try and accumulate experience.

The fight for the right to speak is not a matter of one day or one night, it depends on your own attributes.

Give up lying down and prepare to fight...