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

The translation of this article was inspired by the article Feeding and caring for developers (or why we are such grumblers) .
The author of that article responds to the topic below. For a complete vision of the picture you need to look at it from different angles. The author suggests to look from 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 that I have had.
Designers, you can also create these types of relationships with developers — you just have to break through your personal biases (both designers and developers) to create the space for effective partnerships. If you are successful, the benefits far outweigh any pains and minor changes necessary to achieve this.

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

There are some well-established patterns of poorly designer behavior that undermine our reputation in the eyes of developers. I achieved great success by refining my approach to design in a technically oriented company, and in the process formed a long-lasting, trust-based, effective relationship with the developers, while the other designers failed. A good designer can exponentially improve his work if he has a good development partner, but for this they need to make small 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 entering a new team or starting a new project, the first step is to ask a simple question: “How do you like working?”. Many designers make the mistake of using the tools or processes they are used to or 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 discrepancy process 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 search for them. Some may even just send emails 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 working draft is as close to the ideal as possible. A truly good designer can adapt to any tool needed 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 the design.

2. Participate in the full development cycle

Designers can easily ruin their relationship with developers, if they are not activated until the very end of the product development cycle. The development team working to launch is disappointed when an 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 design a front end. Designers should be knowledgeable (if not involved) about the heavy engineering tasks of creating basic data structures, storage, search, and interface frameworks. Designers should celebrate and promote each stage along with the rest of the team — even if it’s a crooked, half-made prototype using Comic Sans’s # 00C link set

Too often, I observe how my fellow designers interfere with the aesthetics or interaction of the design of the early prototype. Designers' early criticisms about things that the engineer hasn’t even thought about yet do not contribute to the inclusion of the designer in the next reviews. As a result, designers end up starting to beg for significant changes a week before launch and, in most cases, do not receive them.

3. Be specific about what needs improvement.

Many designers think that they have finished when they give a finished, “pixel-perfect” layout to a developer. Designers become nervous when a product or opportunity becomes close to release, and the front-end does not look in accordance with the specification. But instead of responding to the latest build of the developer, “this does not fit my layout, here’s 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 deliberately overlook the details - this is simply not such a priority for them as the main functionality or the creation of code without bugs. It is the designer’s job to notice these errors and point them out as specifically as possible, because the person you are working with was not trained to look for these types of parts.

Submit a bug report with screenshots from a 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 post a bug with commented "before and after" screenshots and summarize what needs correction, like a bulleted list. Thus, both, visually and verbally, the descriptions have a format for faster and more conscious movement.

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

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 trail” (protocol, records - for. Translation . If you are not working in a team of two (you and your developer), everything should be documented for widespread access and response teams.

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

5. Drink 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 you can rely on to realize a designer's vision.

---

Developers! You did not 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 better relationships with designers.

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

For a designer, there is nothing more disappointing than being excited about a new idea, starting to discuss it and then being nailed to the ground before you really explain the potential!

I found that many developers (especially those with whom I worked for years) usually respond negatively to design and innovation ideas, 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 that will not break if you look askance.

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

Designers may be enthusiastic about the fun of new ideas, but instead of saying no at once, take a little time to understand why the designer is so excited about this idea. Discuss with her or another developer how to achieve the same effect with less expense. If your designer thinks you are an energetic person open to new ideas and agreements, you will most likely get the icon you need from them at 4 am in a critical situation. .

2. “Fit and finish” - not a developer’s problems

"Fit and finish" is a term used in the automotive industry. It means that everything in the car is done without errors and deviations, that the machine is completely ready - approx. transfer.
Different disciplines consider different things 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 state, 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 the designer asks the developer to move 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 launching.

If your designer tries 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 the way you would treat any other team member. Your designer is involved in product success just like the rest of the team.

When you do the analysis with your designer, make sure that you give her time to respond, suggest changes or repeat before sending. Showing the project to the designer only as “for your information” is as bad as sending, I do not 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. I really hurried. How many do not reread, and ...
Thanks to everyone who sent (and sends) errors and typos.