The designer and the 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 use style libraries or CSS frameworks to create their applications. Typically, these libraries contain simple styles: predefined fields, 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. Besides, creating a design based on a framework means simplifying many solutions – 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. The vision for a product is often driven by directors, product managers, or, in extreme cases, product designers. But even if the 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 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 a good taste in design. These developers want to be heard, and their comments are relevant and valuable. Listen when you are advised by developers you trust. 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, sat next to me, went straight to the web inspector, and prototyped 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 suite of front-end 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 long periods 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 tip – 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 into 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 whole product or the element you re working on.
Understand the use case
Talk to your product manager and designer to understand why a particular item is being created 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 begin to gradually introduce visual elements into the code.
Object (and move your ideas)
Sometimes designers are asked 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 the 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 “It will not work like this” 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 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 that no unexpected surprises await around the corner. It is also a great excuse to ask the designer any questions about processes or future tasks.
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 times when it seems to you that on this screen the fields 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 a designer a god and a developer a subordinate. At Red Collar, the work of a front-end developer is structured 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. “
– front-end developer of the digital agency Red Collar, Vladimir Lukashov
So that is all! 5 tips I ve put together for both designers and developers to help improve workflows. All of these tips are 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.