The Designers Should Design, Coders Should Code Here’s why you need someone who understands code but doesn’t necessarily live in it.
This essay is excerpted from the ebook Interaction Design Best Practices: Mastering the Tangibles by Jerry Cao, Kamil Zieba and Matt Ellis of UXPin, a UX design platform.
It’s an old argument: should designers code? And it gets a lot of people up in arms, some in favor while others not so much. We’ve even chimed in before.
Yet everyone wants the Unicorn. You know the type: designers who can craft stunning visuals, plan winning user experiences, handle clients with panache, and code semantic HTML5 with bleeding-edge CSS3. But are those really necessary? Maybe what’s needed is someone who understands code but doesn’t necessarily live in it.
Quality can suffer when designers stretch themselves too thin. Keeping up with everything is impractical. Designers can spend many hours learning the nuance of code when they should focus on solving problems.
Today we live in a world of specialists. Front-end devs speak in HTML and semantics. Others delve into CSS and Sass. Visual designers study interactions. Server technicians make it run. Client liaisons build relationships. Everyone can focus on what they love. Too bad it’s not enough.
A new dynamic must take the place of unicorns: communication among specialists. Specialists need to know what others are capable of, even if they don’t understand the precise techniques. The key is to never operate alone.
If you’re a designer, then chances are you’re already empathetic with coders’ mindsets. That’s one of the top qualities we seek at UXPin when evaluating design talent.
You pay attention to detail. So do coders. You’re passionate about your work. So are they. You understand interaction design, and they understand how to make it work. What coders need to know is why, you want, say, links across the top of a widescreen design to jump down the side on tablets. So learning to speak each other’s language is critical to communicating ideas.
Luckily visual design and code are more related than many people realize. It’s not hard to make the jump from graphical tools to concepts in CSS. Did you know that InDesign’s paragraph styles are analogous to CSS selectors? Or that Sketch 3 can export browser-friendly XML? Just as Photoshop has layer effects, code has its hidden gems and secret techniques. But if you’re not aware that, say, CSS can give an element multiple shadows, then you’ll never discover ways to take advantage of them.
UXPin
A generalist would spend time deciding how to use shadows, then spend more time implementing it. And that could come at a switch cost—having to constantly switch mindsets. Not to mention that it takes a lot of time to get really good at it. A specialist designer, on the other hand, would decide how to use it, work with a developer on implementing it, then jump on the next task.
This ties back to communication: designers who are aware of certain techniques don’t need to know their exact inner workings. Smart designers respect the fact that coders are more in tune with feasibility. Their job is to stay current with bleeding-edge techniques and browser limits. When it comes to possibilities, coders are a designer’s best friend. And the bridge between them is empathy.
Designers need to relate to both their clients and the rest of their team to understand not just what they’re saying, but what they really mean. And that calls for a little humility.
Design, which lies at the crossroads of art and science, is an extremely powerful ego booster. When designers work, they feel clever and creative at the same time. Because a product and its design are inseparable (which we elaborated in Interaction Design Best Practices), designers feel almost a sense of parental responsibility. That devotion also creates a dangerous trap.
Unicorns can be proud beasts. And that’s a problem. Ego emotionally isolates them from coworkers, preventing them from making greater products than they can alone.
That’s not to say designers shouldn’t feel passion for their work. But designs do not serve designers. They solve problems for other people. Understanding the root of the problems, not just critical feedback about color and layout, will help designers build products that will keep end users coming back.
As a collaborative design app, we can’t stress this enough: empathy smooths over team communication, which leads to better products in the end.
Designers and coders live in overlapping worlds.
While designers serve human needs—solving users’ problems and addressing their goals—coders tackle onerous technical and server issues. The two come together when designers hand off their vision to coders. Yet implementing the plan requires a different set of skills, which is where things tend to fall apart.
Coders need more guidance than “just make it work” for even relatively simple techniques like, say, parallax scrolling—to say nothing of AJAX requests and DOM manipulation. Flat PSDs only scratch the surface of interaction design. Database-driven mockups require designers to drop their trade and pick up something in which they’re less proficient. Compounding the problem is that interfaces are increasingly complex: animation and interaction are now the norm in web design.
Flickr user opensourceway
Maybe that’s why job descriptions that require proficiency in everything chase away many candidates. It’s not unusual for a job posting* to ask for:
*From a real job post at dice.com.
Yet designers don’t need to know how the DOM works, or how to troubleshoot the idiosyncrasies of asynchronous exchanges. They need to know that such things are possible, and how to communicate the problem and solution to the people who do know such things. The only way to tackle this is with open collaboration in which both sides have an inkling of what’s going on without having to specialize in each other’s fields.
As a designer, the more you specialize, the more you benefit the team.
But solving problems isn’t enough. Understanding what’s possible in HTML, CSS, JS will help designers create practical web designs—products that developers can actually build, and that clients can maintain. Products that work well in the wild. Products that users use.
Comprehension begets understanding. Learning the ideas behind code is an important part of understanding something else—rather, someone else (the hard-core coders). When you articulate yourself with the right terminology, you can properly communicate your design ideas to people who specialize in HTML, CSS and JavaScript.
Subscribe to our mailing list and get interesting stuff and updates to your email inbox.
I like this site, because so much useful stuff on here : D.