A designer and a programmer are perceived as opposite professions to each other. Designers are usually thought of as impressionable creatures, and programmers as cold adherents of logic. In the past, I was a software developer and then retrained as a product designer. Therefore, I can argue that the two opposites are capable of working together effectively. With a little understanding of each other’s work, a designer and a developer can dramatically improve the neighborhood in the workplace. Below you will find five general principles of collaboration for designers, and five more for developers.

5 “rules” for designers

Avoid custom styles

A lot of front-end developers rely on styling libraries or CSS frameworks when building applications. Typically, these libraries contain simple styles: preset margins, colors, and other classes that developers use to speed up and streamline their work. Here’s what it means: if you suddenly decide to add a new field, font size or some detail, the developer will have to write the CSS code from scratch to bypass the basic styles. Sometimes this is necessary, but it quickly gets boring and makes the developer’s work tedious and cumbersome. Set aside custom styles for special occasions or when absolutely necessary. In addition, creating a design based on a framework means simplifying many decisions – and, more often than not, this is a big plus.

Get developers involved as early as possible

Let’s be honest: Usually, developers are not given the floor in product decisions unless the work is on a very young startup or the developer is not a CTO. A product vision is often driven by directors, product managers, or, in extreme cases, product designers. But even if developers don’t actually contribute much, you can make them think they are. Get a developer to meet with product managers. Also, schedule a design discussion with the developers and go through the options together. Explain to them why you made these particular decisions and ask the developers what they think. If the developers feel like they have influenced the design process, then they will be more careful in bringing that design to life.

Listen to the opinion * of the developers

Believe it or not, developers are often pretty good designers. Especially when it comes to UX: I’ve worked with a lot of developers who had good taste in design. These developers want to be heard, and their comments are relevant and valuable. Listen when developers you trust give you advice. Better yet, show that you are listening; take a notebook and write down their ideas. You don’t have to end up using all of these ideas, but some of the suggestions just have to stay – this will give the developers the respect they deserve.

* Of course, not all design comments from developers are good. Take them with a grain of salt, and without prejudice – everyone wants to be heard. And you will have the opportunity to learn something new

Learn basic HTML / CSS / JS

The best designer I ever worked with when I was a software engineer at SalesforceIQ would sit next to me, go straight to the web inspector and prototype right in the console using HTML or CSS. Developers are very encouraged when designers understand technology and work within constraints. Of course, you don’t have to have a full set of frontend skills to be a good product designer. But even the most basic skills will play a big role. Earn the respect of your closest colleagues, learn a little code.

Collect all minor edits

“Flow” is the state in which developers are most productive, “on fire.” They need large chunks of time, without interruptions, to enter the “flow.” Therefore, it is better to schedule discussions at the beginning or end of the day, and stop constantly separating the developer from the process, because this poisons his very existence. Yes, that means your unexpected idea of ​​making the blue buttons darker will have to wait. The design process is cyclical, and there will always be changes in it. Let small changes accumulate, and only then go with them to the developer. Set yourself a threshold of 5 minor edits, and go with them to a colleague only when they accumulate. There is no greater pain for a developer than constant distraction from the Stream just for the sake of changing the button color. 7 times

“Friendship with a developer can really be a lot of fun! If instead of arguing about “how can and how can’t” be done in a specific place, ask: “I need to achieve this effect here, what can you offer?”, You can hear quite reasonable and suitable options 🙂 The main thing is to be able to set a vector and explain it in the most logical way! About the first piece of advice – I can’t agree! Truly unique and memorable products are impossible without custom solutions, another conversation is that these solutions must obey a coherent system. If there is a hierarchy of styles and blocks of similar functionality are designed identically, then any good developer can implement the design. “

– Elena Kudaeva, senior designer of the digital agency Red Collar

5 “rules” for developers

As a developer, it’s very easy to jump straight to code. But one must remember that with great power comes great responsibility. Take a look at the big picture to understand the purpose of the overall product or the element you’re working on.

Understand the use case

Talk to your product manager and designer to understand what purpose a particular element is created for, and why the designer created it that way. Without this information, you will simply move the pixels across the screen, and with it, you can imagine all the use cases and edge cases in your implementation, and also take your code to the next level.

UX first, rest later

In a changing climate, design constantly goes through the same cycles based on user tests and feedback. The blue button with 5 px rounded corners and the box shadow that you painstakingly added just yesterday is now a green button with a flat design and sharp corners. Athas. But don’t be discouraged, just take it for granted as part of the development process. First, create the UX path, functionality, and outline the overall design diagram. You can get a little sad, but don’t lick everything down to the pixel just yet. After all the tests and final approval of the design, you can start gradually introducing visual elements into the code.

Object (and move your ideas)

Sometimes designers ask to make some special element that changes colors and bounces every couple of minutes. Don’t listen. Design is two-way interaction. Do not be afraid to argue and express your opinion about the limitations and technical side of the issue. Even the best designer doesn’t have your technical acumen or process understanding. But a simple objection and the phrase “This will not work” is not enough, suggest your options. Try this: “It will be very expensive to do this, let’s try …”. Do not forget that thanks to modern tools, most things can be brought to life, but this does not mean that you need to do everything that is technically possible. The job of the engineer is to help the designer arrive at the best and most profitable solution to a problem.

Talk to designers more often

Communication turned out to be the main topic of this article. You bring the design to life, so the progress of the work must be constantly checked with the author, that is, with the designer. They love to see the work come to life, so everyone will benefit. Checking progress with the designer will help you know that everything is going according to plan and no unexpected surprises await around the corner. It’s also a great excuse to ask the designer any questions about processes or future challenges.

Fill in the blanks **

There are gaps in the design process, and you need to rely on your common sense to fill them. The design that you recreate will not be identical to the one that was given to you at the beginning of the work, it was just a starting point. There will be moments when it seems to you that on this screen the margins should be wider, but this color spot in reality looks completely superfluous on the page. Don’t run to the designer with every question. Put on a designer gown and go ahead, make small decisions on your own. You have all the abilities for this.

** Just don’t go crazy, discuss big decisions with the designer. Use common sense 🙂

“A bit of a strange article, it makes the designer a god and the developer a subordinate. At Red Collar, the work of a front-end developer is built a little differently, we do not use any frameworks for styles, initially there are no blanks, everything is written from scratch, since each new project does not repeat the previous one. In our company, close communication between a designer and a developer is an integral process of creating a website, since the developer himself is a motion designer, and many visual effects are created together with the designer and also the creative director. “

– frontend developer of the digital agency Red Collar, Vladimir Lukashov

So that is all! 5 tips I’ve collected for both designers and developers to help improve workflows. All of this advice is highly subjective and based on my past experience as a software engineer and current experience as a product designer. Let me know how much you agree (or disagree) with my opinion in the comments.

Source: DEADSIGN