Have you ever made a string telephone as a child? The one that uses two paper cups at the ends and is joined by a string? It’s a science activity that every child/parent does. A while ago, it struck me that engineering and design teams are like the two kids who are at the end of this paper-cup telephone– solving problems, observing, experimenting, collaborating, failing and succeeding together to make a lovable product.
Just like building a good string telephone requires a taut string between the two cups, in the same way, building a delightful product also requires good rapport between designers and developers.
When the string slacks, it doesn’t transmit sound properly and you’ll only hear faint murmurs.
Similarly, when the communication between designer and developer slacks, it results in confusion, misunderstanding and loss of important information.
Result? A mediocre product.
There are a lot of published articles that offer help to make this collaboration easier. A few suggestions like– designers must learn to understand basic HTML/CSS/JS, and developers must regularly communicate with designers–are great only when they’re followed religiously (which almost never happens).
These nuggets of wisdom have a short-life.
What we need is a mindset shift. That too at the organizational level.
The collaboration gap between developers and designers is a problem area for every organization—whether they’re in a remote setup or working from the same location. Below are some ways through which we have tackled them at Quovantis.
We still have a long way to go and adapt to this mindset change entirely, but we’re glad we’ve taken baby steps.
Motivate developers to participate in design thinking workshops
When it comes to working together on a project, designers and developers are miles apart from each other. They approach the same problem in different ways. A designer might only worry about getting the fonts, colors, size, and shadow settings right. Whereas, a developer’s first line of thought would always bend towards making things functional.
And there’s nothing wrong with this mindset. After all, they’re doing justice to their role.
But to close the gap, we need developers to understand and respect the value of design. We need to show them that good design doesn’t always mean a pretty-looking interface. It’s usability which matters the most.
A good way to make them understand all of this is by sparking their curiosity. How do things work in design? How do designers envision their designs in development? What happens when developers miss small details in design? How does it affect the usability? How does it impact the overall user-experience of the end users?
At Quovantis, we answer all the above questions in our various design workshops that are compulsory for all developers. In these workshops we help developers see design and engineering as one unit. Not only this, we also help developers learn by doing through a fun exercise. One of such exercises is “spot-the-difference” where we tweak a design and add deliberate mistakes. We then ask the developers to compare it with the original design and find out mistakes. The best part of doing this? It adds a gamification element rather than forced learning.
Make your design process visible
One of the reasons why developers think design comes second to functionality is because they don’t understand design. And even if they do, they only understand the aesthetics of it. That’s why designers must make the design process transparent and more visible for their developer teammates.
An example could be sharing the reason for choosing a particular layout, typography or color and help developers understand how these choices impact usability. Make everything available to developers in the form of a style guide.
Additionally, designers must spend enough time with developers to help them understand why usability principles should be considered in every project. Talk frequently about heuristics principles like error prevention, consistency, simplicity, etc. and what role they play in enhancing the user experience of the product.
Understand each other’s role
Designers and developers who work remotely on the same project or even those who work in the same office but communicate rarely are like two people in an arranged marriage- they know each other, but they don’t understand each other.
So it’s important to understand the boundaries, the uniqueness, and challenges of both the roles. One must put conscious efforts in understanding how systems, tools, and workflows vary in both the roles and why it’s important to be in sync in order to craft a compelling product.
Instead of doing ‘easy’ work, ask yourself what could help your design/development team to work in the best capacity without facing any blockers? What pain points can you address as a designer/engineer? What collaborative initiatives can you initiate to improve the process?
Understand the product’s vision
A good design is one that solves users’ problems. A well-engineered product is one that delivers on that promise of solving problems. A product’s vision binds both design and engineering together. It brings the team to speak in a common language– one that understands the user’s pain points and is empathetic towards the problems they face.
Most of the time, designers move to different projects when their previous project goes into the development phase. Later when developers need to modify designs, at that time, it’s the product’s vision that brings them back to the ‘why’ of building this product. If understood well, a product’s vision holds the two teams like a glue.
On the other hand, when designers and developers are detached from a product’s vision, it not just affects the collaboration, but also affects the quality.
We’re repeating the benefits of some of our practices like “spot-the-difference”. Our developers feel this has improved their attention to detail and they now know how small things make a big difference. I hope you can borrow some of these practices in your organization and improve collaboration and efficiency between your design and engineering teams.