Should designers be able to code? This topic never seems to die, with its endless blog posts, Twitter discussions and conference talks. But the developer’s involvement in the design process seems to be addressed very little. This is a shame, because developers have a huge amount to add to discussions about design.
The unfortunate truth is that many designers have a somewhat elitist attitude towards design. They believe that only they can come up with good design ideas. That is simply not true.
Everybody has the ability to make good design suggestions, including developers. Admittedly, a trained designer will probably be more effective at finding design solutions. But that does not mean others should not contribute. As designers, we need to swallow our pride and accept contributions from everybody. For that reason alone, we should include developers in the conversation.
The Dangers Of Not Including The Developer
Back in the heyday of Digg, I remember a conversation between Daniel Burka (Digg’s lead designer) and Joe Stump (its lead developer). They told a story of a design change to the Digg button that Daniel wanted to introduce. From Daniel’s perspective, the change was minor. But upon speaking with Joe, he discovered that this minor design change would have a huge impact on website performance, forcing Digg to upgrade its processing power and server architecture.
This is the problem when developers are not involved in design. It can be disastrous. It can lead to designs that are impossible to build, designs that introduce unnecessary technical complications, endless back and forth between the designer and developer as they struggle to fix problems created by the designer, wasted days of revision and iteration — all because the developer wasn’t consulted.
Consider also the client’s perception of this mess. The client has signed off on the design, only to be told later that it cannot be built. That reflects poorly on everyone. This is why we need the developer’s involvement in design decisions. The decisions we make as designers have far greater ramifications than we are aware of.
The Developer Can Improve Our Understanding Of What Is Possible
But we need developers not only to block infeasible ideas. They might also suggest ideas that we’ve dismissed as impossible. We sometimes filter our own ideas because of the limitations of our technical knowledge, especially if we do some coding ourselves. We figure that if we cannot think of how to build an idea, then it cannot be possible.
Sure, developers will sometimes resist our ideas. But other times they will build on them and take them further than we ever thought they could go. I have been in discussions with developers who proposed things I didn’t even know were possible. Without having them in the room, I would have missed out on those insights.
What’s more, I learned through the process. By working closely with developers, my understanding of development has increased. I remain a specialist in design, but my knowledge of development has increased, making me more of a generalist. And, as I have written before, being a generalist is no bad thing.
Developers Make Design Decisions All The Time
The biggest reason, though, for involving developers is that they will end up making design decisions anyway. The truth is that, as a developer delves into building a project, they will have to make decisions that affect and refine the design. Designers rarely have the time to consider all nuances of a website. The rest fall to the developer.
By involving the developer in the initial design discussions, they will be in a better position to fill in the blanks. And when compromises in the design must be made, they will be in a better position to make those calls.
The Developer Will Have A Greater Sense Of Ownership
There is one final reason for including the developer in the process: They will feel more engaged with the project. Too often, developers are at the end of a long chain of decision-making. Their voice isn’t heard because they’re brought into the process far too late. This leaves them feeling no ownership over the project. By bringing them in earlier, they will feel more connected to the work and more appreciated, too.
The question, then, is how do you include the developer in the process?
So, What Are You Waiting For?
Involving a developer in the design process is not rocket science. It comes down to inviting them to any design sessions that take place.
Get them involved in the design exercises you do with clients. Encourage them to sit in on at least some of your usability testing sessions, and involve them right from the beginning of the project. The earlier you do it, the more you will benefit. In particular, show them your design work early on, before the client sees it. Too often, a client will sign off on a design and then the developer will discover that it cannot be built! That puts you in the embarrassing position of having to backtrack with the client.
Of course, the more meetings the developer attends, the less coding they will get done. We must find a balance. A few meetings are worth it if delays are avoided down the line.
There is another thing you can do that won’t eat into the developer’s time. Put the designer’s and developer’s desks side by side. My agency’s designers and developers sit beside each other and are always commenting on each other’s work. When a developer is able to look over at the designer’s screen, you can be sure they will speak up if they don’t like what they see!
In the end, this is all about breaking down the barriers between roles and encouraging more collaborative work, not just between designer and developer but between workers in all disciplines. The more we understand what our colleagues do and the less precious we are about our own discipline, the better the result will be.
Excluding the developer from the design process will do nothing but prevent the project from living up to its potential. In fact, excluding anyone — whether copywriter or SEO specialist — will ultimately compromise our work.
Thoughts?
(al, il)