by Chris Cardello on January 21, 2016

People ask me all the time how Hashrocket manages the give and take between design and development. After being involved in a number of external teams over the years, I've realized that this is a challenge which many companies struggle with.

One could say that well crafted software is the product of a balance between intuitive design and easily-maintained code. Design and development are essentially two sides of the same coin, but problems arise when one side is treated as more valuable than the other.

We've probably all witnessed or been part of one of the following two situations;

• Developers make a thing and hand it off to a designer to "make it look pretty"
• Designers design a thing and hand off to developers to "make it work"

When writing software, it is of the utmost importance that all project team members are treated as having equal value, and treat each other with respect and appreciation for the value they bring. So this us-then-them mentality is fundamentally broken: ideally, anyone who is going to be contributing a project for its duration should be involved in all phases of the lifecycle.

Collaboration from the beginning is key, because it sets the tone for the working relationship that will occur over the coming months. Wireframes and storycards should be created concurrently, so both perspectives can be voiced. This ensures that decisions made at this phase of the project are informed by both perspectives. This approach helps minimize the situations where something is designed in a way that's costly or time-consuming to implement, or a clunky interaction is developed where a more intuitive interface may have improved the user experience from the start.

This level of collaboration shouldn't stop there. Your company should have a "no fences" culture. This means that at no point is something thrown over a fence to become "your problem". When a designer is working on a design, it shouldn't be an oddity for them to grab a developer and ask their opinion on how a given thing will be implemented. Likewise, when a developer is implementing a design, they should feel free to question the design and voice their concerns or get clarification from the designer.

Occasionally, something that everyone agreed upon in a wireframe or static view doesn't "feel right" once implemented. If this happens, no matter what side of the coin you're on, it's your responsibility to bring up the issue before any more time is spent on a potentially less-than-ideal experience for the user. Too often the walls we build between each other cause us to fall back on assumptions which hurt the project in the long term.

Even when the entire project team is all working towards the same goal, there are bound to be differing opinions on matters. This is why having strong leaders in place who can make the hard decisions is paramount. Not everyone is going to get their way every time, but it's essential that everyone feels that their opinion is valued, so that they aren't deterred from providing it in the future.

All of this may sound obvious or idealistic, but the truth of the matter is that it all starts with the culture of your company. In order to work together this closely, everyone needs to stand on equal footing and leave their egos at the door. No one should be fearful of providing constructive feedback due to unwarranted backlash. Active collaboration is the key to a successful and healthy design & development team, and that can only be achieved through humility, conversation and mutual respect.