1. Learn what developers do.
Many designers have no idea what developers do. The stereotype is that developers think differently from designers and live in a world of undecipherable code. So, when a developer says something cannot be done, too many designers tend to accept that and move on. Instead, as a designer, you should ask why something can’t be done and find out whether there are ways around the obstacles.
It is even rarer for designers to truly understand what developers do and actually know how to code. While there is no need for you to become a developer yourself, learning the basics can take you a long way. First, this results in superior design solutions because you’ll have a better understanding of what is possible and what isn’t. Second, you’ll be able to communicate better with developers about their work. Third, and probably most important, it will improve your professional relationships with developers because you’ll gain their respect.
How often have you talked with clients who only had a vague idea of what you do? They tend to be the ones who come up with the most unreasonable requests—not because they want to be difficult, but because your work seems like some sort of voodoo to them. This probably frustrated you and made your work even more difficult.
At the opposite end of the spectrum are clients who know exactly what your job is and how you do it; clients who ask you about your personal process, the problems you’ve encountered, and your reasoning. Those clients are probably a joy for you to work with.
Why would this be any different for developers? Like everyone else, they’ll work harder and better if they know someone’s paying attention.
2. Ask developers for their thoughts—and listen.
It’s becoming more typical to involve developers from the very beginning of a project. While this is a great idea, “involve the developer” sometimes tends to be interpreted as “just have the developer in the room.” People may ask for their opinion and thoughtfully nod their head, then just move on. Not to mention, they mainly ask developers for their opinions on development, not user experience.
This is a big mistake. Many developers have coded just about every type of Web site. So they may have a vast amount of knowledge that no one is tapping into. Just because developers are not UX designers or members of your target audience doesn’t automatically mean that their insights are irrelevant. Often, unexpected and brilliant insights or solutions come from developers. The key is to listen. This doesn’t mean that you should run every design decision by a developer, but open the conversation by asking, “Hey, what do you think?”
Furthermore, fostering a team culture in which developers know designers value their opinion is very beneficial. The most successful, enjoyable projects are those on which all members of the team, including developers, can contribute at any point in a project and run their ideas by others, knowing that their contributions will be valued. Developers tend to be especially good at connecting the dots and spotting solutions that haven’t occurred to anyone before, but they can do that only if they know you’ll hear what they have to say. A developer is not there simply to make the designer’s vision come to life. A developer should be an equal partner on the team.
Again, think about instances when you’ve worked with a client who told you exactly how everything should be. How enthusiastic were you about those jobs? I’ll bet you prefer clients who trust your expertise and are open to suggestions. Why would developers be any different? Take their feedback on board.
