DEV Community

Cover image for The Tension of Design and Development
Mike Rispoli
Mike Rispoli

Posted on

The Tension of Design and Development

Inside every organization there exists a natural tension between design and development. In healthy organizations this tension produces magic results. These are interfaces that delight and win awards. Interfaces that leave you awe struck.

The problem is this type of working relationship between design and development exists almost nowhere. That natural tension can turn into an unspoken resentment between the two parts of the organization.

This is not often a conflict of personalities, but rather a problem with the organization itself. In most organizations design and development are seen as entirely separate groups. They work separate, they sit separate, they even congregate separate at work events.

These are all signs of an unhealthy tension between the two groups. The reality is developing products is an unusual art form, one where two different skills and personalities must come together to product a whole.

Imagine for a moment if Michaelangelo knew nothing about marble, but instead berated a marble worker about how he wanted the iconic David to look. The carver might insist that the vision were impossible and the expectations could not be met.

In business we also have deadlines. Things have to ship in a relatively timely manner. This only adds to tension as both parties feel pressured to deliver the best they can in a time line that rapidly closes in on them.

In most orgs this is where the tension begins. Designers struggle to get clients to approve their designs. Each change request results in additional days not budgeted for design. In order to not upset the client, no additional days are added for development as a result.

Developers are then left to implement a difficult design in a shortened time frame. They request something simpler so they can make deadline. The designer grows frustrated as the simpler design WAS the design the client DIDN'T want. The tension grows between the two.

There is some element of truth to the Michaelangelo analogy here as well. In the above example the client and the designer are collaborating with no knowledge of how difficult said feature is to build. Often the time tradeoff is not one to one.

The difficulty of building this new feature often grows exponentially. One additional day of design does not just result in one more day of development. If you've committed to a fixed scope before ever designing the product you're goose is cooked anyway.

Clients are typically willing to let their deadline extend in a fixed scope. Why wouldn't they? The losses are all born by the business. While designers are focused on creating a happy client, you've created a time deficit that must be dealt with internally.

Then comes the design hand off meeting. You know that meeting where design is supposed to collaborate with development to make sure everything is on track. Except for that dirty little secret that the client already signed off on the designs so we really can't go back.

It's easy to see the organizational failure here of running design and development in a waterfall. You create tension within your business, all while delivering subpar products because developers are rushed to fit 9 pounds of bologna in an 8 pound bag.

The solution here is to build cross-functional teams of designers and developers. Designers and developers should be working with clients together and leverage the experience of each other. Why wouldn't you want all the expertise at your disposal in the room anyway?

In this world there is no "design hand off" meeting. The product is designed and developed as a whole, incrementally, with input from all parties. Time tradeoffs can be discussed in real time, with defensible arguments.

Design isn't left alone with a client that was promised the moon and development isn't left holding the bag at the end. They are a team, tasked with carving the David together. The conversation goes from "I want veins," to "what if we could carve the veins?"

We move from an assembly line to a process of creation. One where both parties can dream of delivering better work and actually have the runway to do so.

Top comments (1)

Collapse
 
curiousdev profile image
CuriousDev

I also want to add, that sometimes it actually is necessary, that developers and designers work together and share requirements as well as technical possibilities. Because you do not always have the possibility to change your product the way which you want it to be, like you can do with Software Development in many cases. You can be limited to what your technologies offer, especially when you are using customized products, like having no-code/low-code technologies. You would not be able to design whatever comes to your mind, because you possibly just cannot implement it.