“You can’t see it until it’s finished…”
So sang The Talking Heads way, way back in 1978, a line that pretty much sums up the emotional landscape of a creative. The work isn’t just work, but expression of an artistic vision that is very personal. Designers of UX/UI strive for the ineffable, an experience that is pleasing on a functional and aesthetic level.
Developers, on the other hand, approach the same project with a different perspective. It has to work, and it can only work if the code is written properly. If that means altering a flawless design, such is life. You can’t get blood from a turnip.
It’s not hard to see where feelings can get hurt, egos bruised, and teamwork made to suffer when creatives clash with coders.
But it’s not inevitable that this age–old collision between the beautiful and the functional has to lead to a breakdown in communications. There are strategies you can use to avoid the estrangement that can arise between designers and developers.
Stay in Your Lane
When a developer says, “We can’t make that work,” it’s very tempting for a designer to summon that very Shakespearean impulse of: kill all the messengers. The bearer of bad news is often the brunt of ill tidings, in Elizabethan England and the local office park.
But designers need to understand that developers often have their hands tied in a technological sense. Sure, designers know what users want because they’ve conducted surveys, recorded usability tests, interviewed real users, and come up with brilliant layouts that will rock UX like nothing else. This isn’t the end of the rainbow, however. The pot of UX gold still has to be claimed by knowing what is technologically possible.
UX that isn’t doable isn’t really UX. It’s just so much scratching on a cocktail napkin. Instead, designers need to work closely–in person, with desks nearby, or remotely on an active Slack channel–with developers so that the ultimate prize, a workable solution that is a desired UX outcome, can be built. If designers can understand where the technological bottlenecks are, they can brainstorm workarounds that don’t sacrifice the larger vision.
Talk to Me
Designers and developers occupy different worlds, no doubt. One group seeks artistic inspiration, while the other toils in numbing drudgery. Or so the story goes.
In fact, this stereotype need not persist. Both groups need to seek common ground. One way to do this is to learn the language the other speaks.
Creatives, welcome to code. Developers, meet Dieter Rams.
Code is what developers speak, and designers should be conversant in it. Not as an expert, necessarily, but to know enough to ask the right kinds of questions, especially if developers are saying no. If designers remain ignorant of a developer’s frontend programming language, then they sit at a disadvantage and must take at face-value everything they’re being told. It’s never a good idea to be in a power asymmetry based on information.
By the same token, coders should spend time delving into the basics of design, like perusing the ideas of Dieter Rams, the design paragon who gave us the classic injunction: “Less, but better.” Seeing how color and pattern form the core of design will allow developers to better empathize with the visions of creatives.
Likewise, if designers can assist developers, they should, and there’s no better way than by using Figman’s Auto Layout system. The gist of it is that if designers use this feature, then developers can grab snippets of code to ease the transition from mockup to actual product. There has to be buy-in from everybody on the team, because Auto Layout can create headaches if it isn’t used with fidelity.
When No Is the Answer
When developers say no, designers face a conundrum. Is this a no based on actual technological constraints or is this a no because the dev team is swamped and this design looks too complicated?
When should designers push back? And when should they tactically retreat?
The sad truth is, and this should come as no surprise: people can be lazy. Even the very talented people on a dev team. If not lazy, then in no mood to fight for the resources your design needs, which might involve some unpleasant office politics.
In that case, no isn’t really no. So how should a designer probe without starting World War III? Simple: become a reporter and gather some basic facts. Ask questions that have easy answers to, and follow those up with more simple questions, and if you don’t hear a good technological explanation for why something has to be cut from your design, you can possibly shame the dev team into at least trying to figure something out.
But be careful about pushing for things that make no technological sense. You have to know when to fold em, as Kenny Rogers told us.
Agree to Agree
Mostly, though, what designers need to do to have better communications with developers is to build durable and pliable relationships that are based on trust. Often, a good working relationship has little to do with work. Just like communication involves more than emails and texts, relationships transcend working on the same project.
People need to feel invested in each other, and so designers and developers should take the time to establish rapport, which fundamentally centers on trust. Collaboration depends on the ability of teammates to know that they won’t be left holding the bag, that everyone will pull their weight, and that each voice can be heard. This kind of rapport might require time spent together outside of work, to forge bonds that will open lines of dialogue.
The Final Word
Designers and developers should have the same goal in mind: excellence of work product. That is, the kind of UX/UI that gets people buzzing and builds a brand. The stereotype of creatives vs coders is one that should be retired for good, as both groups can find common ground to prosper.
So, yes, you can see it before it’s finished…in case I need to make some changes.
YOU MAY ALSO ENJOY
