How designers and developers can play together (and keep running with scissors)

Original author: Jenna Bilotta

I was prompted to translate this article by feeding and caring for developers (or why we are such grumblers) .
The author of that article answers the topic below. For a complete vision of the picture you need to look at it from different angles. The author suggests looking from the side of the designer. Who cares - under cat.


As a designer working in tech-oriented companies for the last ten years or so, I spend a lot of time working with developers. These collaborations are the most constructive and fruitful working relationships I have had.
Designers, you too can create these types of relationships with developers - you just have to break through your personal prejudices (both designers and developers) to create a space for effective partnerships. If you are successful, the benefits far outweigh any pain and minor changes needed to achieve this.

I worked in consulting, in the academy and in one of the most famous developer companies in the world. I saw the behavior of developers from different angles and worked with many types of designers (from very technical to conceptual, to visual and others).

There are several well-established patterns of poor designer behavior that undermine our reputation in the eyes of developers. I achieved great success by clarifying my approach to design in a technically oriented company, and in the process a long-term, trust-based, effective relationship with the developers was formed, while the rest of the designers failed. A good designer can exponentially improve his work if he has a good development partner, but for this they need to make minor adjustments.

Here are my best tips for creating effective design and technical relationships. My goal is to reduce prejudice on both sides and help designers and developers form a strong alliance to create better products.

1. Use the tool they use

As a designer joining a new team or starting a new project, the first step is to ask a simple question: “How do you like to work?”. Many designers make the mistake of using tools or processes that they are used to or they have found success with the previous team. But things change quickly in software, and each team is unique.

I found that I can avoid the process of divergence by simply asking the development team how they like to work and what tools they already use. Some teams like to create a matching document to track bugs or use software to find them. Some may even simply send an email or use a flexible tool like the Pivotal Tracker.

The key to design success is not how good their techniques are, but how successful they are in the interaction of their design, so that the design is as close to ideal as possible. A truly good designer can adapt to any tool necessary for effective design interaction - even if learning a new tool takes a little longer, it pays off in paving the road by reducing friction with development.

2. Participate in the full development cycle

Designers can easily ruin their relationships with developers if they are not activated until the very end of the product development cycle. The development team working towards the launch is disappointed when the outsider dives with a few detailed changes. (And if you do not turn on earlier than right before launch, you are actually an outsider.)

Developers need designers to participate in the full life cycle of a product or opportunity, not just to develop a front end. Designers should be well aware (if not involved) of the heavy engineering tasks of creating basic data structures, storage, retrieval, and interface frameworks. Designers should celebrate and promote every step along with the rest of the team - even if it's a curve, a half-made prototype using the # 00C set of links in Comic Sans

Too often, I watch my fellow designers intervene in the aesthetics or interaction of early prototype designs. Designers' early criticisms of things that the engineer hadn’t even thought about before didn’t contribute to the designer’s inclusion in the next review. As a result, designers end up asking for meaningful changes a week before launch and, in most cases, don't get them.

3. Be specific about what needs improvement.

Many designers think that they are done when they give the finished, "pixel-perfect" layout to the developer. Designers begin to get nervous when a product or opportunity becomes close to release, and the front end does not look up to specification. But instead of responding to the latest build of the developer “this does not match my layout, here is the layout in case you lost it” - be specific!

Designers are trained to notice even the smallest details that most people will never notice. Developers do not intentionally miss details - this is simply not such a priority for them as the main functionality or creating code without bugs. It is the designer’s job to notice these errors and point to them as specifically as possible, because the person you are working with has not been trained to look for these types of parts.

Submit a bug report with screenshots from the live demo and your layouts side by side. Comment on the screenshots with detailed descriptions of what needs to be changed. Show and tell. I usually send a bug with commented “before and after” screenshots and summarize what needs to be fixed, like a bulleted list. Thus, both visual and verbal descriptions have a format for faster and more conscious movement.

I even went so far as to send improvement of interaction separately from polishing visual design, because you can have developers in your team who are stronger in one area or in another - so it can be easier to divide the work if it is divided into these categories. In general, developers respond very well to lists of improvements that they can methodically promote and subtract when they are ready. This is a bit more work for me, but it’s more appropriate to get changes with less legwork.

4. Real conversations are good, but they cannot be tracked.

Many of the designers that I know prefer to develop design details in person with a product manager or developer. This is wonderful and can help team cohesion, but the side effect of this is that there is no “paper trace” (protocol, records - at. Translation .. If you are not working in a team of two (you and your developer), everything should be documented for wide access and response teams.

So even if you have a productive personal discussion with your developer about design improvements, go back to your table to summarize this immediately in a letter or bug report. This gives the whole team a chance to react and acts as a report on the decisions made. Any decision that does not come with a documented rationale is open to change by anyone when things get tangled to an end.

5. Have a beer with your developer

Never underestimate the power of socialization in team members. Get to know them and let them know you. You can improve trust and communication if someone feels that you care about him as a person - and not just a set of skills that you can rely on to realize your design vision.



Developers! You didn’t think that you got off so easily? With all the things that designers can do to make your life easier, there are also a few things you need to do to create the best relationship with designers.

1. Do not let your first answer be “no”

There is nothing more disappointing for a designer than to get excited about a new idea, start discussing it and then be nailed to the ground before you really explained the potential!

I found that many developers (especially those that I have worked with for years) usually respond negatively to design ideas and innovations because they require "too much work for something that does not look important." Believe me, designers understand that you are working hard to make something as viable as possible, which will not break if you look at it askew.

But there is a reason why teams need both designers andthe developers. It is our job to make an intuitive, fun and innovative experience that people will love to use and will return to. Otherwise, all the hard work of the developer will be nothing.

Designers may be enthusiastic about having fun with new ideas, but instead of saying “no” right away, take a little time to understand why the designer is so excited about this idea. Discuss with her or another developer the ways to achieve the same effect at a lower cost. If your designer thinks that you are an energetic person, open to new ideas and agreements, you will most likely get the icon that you need from them at 4 a.m. in an emergency .

2. “Fit and finish” - not the troubles of the developer

“Fit and finish” is a term used in the automotive industry. It means that everything is done in the machine without errors and deviations, that the machine is completely ready - approx. transfer.
Different disciplines consider different things to be extremely important. For a great designer, attention to detail and creating a truly polished experience is paramount. These details matter, they can be difficult to describe, but usually affect the user's subconscious attitude to the product. Many small detailed errors can accumulate and create the feeling that the product is not professional or not reliable. On the contrary, a well-polished application can create a strong emotional impression that the application is flawlessly designed, but has a sloppy interface.

When a designer asks a developermove the icon three pixels to the left or align two blocks of text along the same baseline, this change may not seem important, but a set of such things can really make a difference.

3. Make a debriefing with your designer before launch

If your designer is trying to cooperate with you, do not punish him by confronting the fact of a new feature, even if it seems to you that these are minor changes. Treat your designer as you would any other member of the team. Your designer is involved in the success of the product in the same way as the rest of the team.

When you do a parsing with your designer, make sure you give her time to respond, suggest changes, or repeat before submitting. Showing the project designer only as “for your information” is just as bad as sending, I don’t show it to your designer at all.



I hope my experience - and the approach that I have developed over the past years will help you create strong alliances between designers and developers. I believe that in the end it will lead to the creation of much more powerful products and a better user experience.

PS I apologize. Really hurried. How many do not re-read, but ...
Thanks to everyone who sent (and sends) errors and typos.

Also popular now: