Many companies have their creative team or a solo product designer. What often happens in this scenario is that the design process is something unknown, and even if it's shared with the consulting partner or the IT department, it remains impenetrable.
Then, when the design is ready, development can start and suddenly, even the best-curated design seems clunky to the developer's eyes: there are visual bugs on certain breakpoints; some of the most common use cases weren't considered; the UI Kit is incomplete or outdated… At that point, what had to be a small enhancement becomes a thorn in the side for the developers and designers.
I've found myself in these shoes several times, so many that I often defined myself as "the connection between design and development". That nowadays sounds like putting a patch (well, more than one) on the communication gap that often exists between these two worlds.
The perfect design handoff myth
I struggled to understand the best way to bridge that gap. So, I dedicated a considerable amount of time to find new ways to make a design handoff that could reduce the inherent gap between designers and developers. In my vision, this could be achieved by talking with both teams to understand their actual needs and finding a solution that worked for both: a handoff template with agreed-upon guidelines seemed like a good starting point to me.
I had the chance to experiment with this approach on a project, without gaining any results. Well, a good thing happened, actually: I opened a communication channel between the product design team and some developers who advocated for design. As you can imagine, we didn't find the unicorn in the room; of course, the design handoff was improved, but it didn't change anyone's life. Apart from that, devs finally started to talk about design.
After that experience, I realized that I was focused on the output (the design handoff) because I considered it a consistent part of good communication between designers and developers. But I was putting my efforts on the wrong point: the handoff was nothing more than the output of a locked design process that rarely included developers.
How do we expect a design process to be
The design process is a cyclical process in which designers iterate continuously. The design process includes these phases: Research, Ideation, Prototyping, Testing, and Delivery.
I don't want to focus on every single stage, but on the fact that often the development team isn't included in it. What we usually experience is that the design team works on the design and then passes it to developers. But that is like crafting a dress without having certain measurements: when there's something to adjust, you might have to retouch the entire dress, and that's time-consuming for everyone.
When the design process is only designers' business
This is a common way to cooperate, but honestly, how can we still work like that? The design process isn't just the designers' business. It has to include developers. Only by including developers in the design process you can effectively say that designers and developers are collaborating on a project, crafting the dress together.
When the design process is open to collaboration
With this fragmentation, the iteration of ideas is easier for both teams. This process creates a smooth workflow between designers and developers that continues for the project's duration.
The benefits of crafting a dress together
- Better team cohesion: It's easier to support design proposals if you have taken part in the design process.
- Reduce (or even avoid) design debt: It's easier to change a few elements at a time instead of multiple sections or features at once.
- Save time on tasks: Instead of wasting time asking for clarifications on the design (and responding to them), you can work more efficiently.
- Share your knowledge: Working together is also a good opportunity for learning from each other. This is true for product designers who may not be familiar with what happens behind the scenes in their design, but it's also true for developers who may not have much confidence with UI patterns.
How to build an open design process
To build an open design process, we have to consider external factors like project requirements and team dynamics. For example, it isn't always possible to sit down with developers or schedule a meeting just to review small design changes. But hey, technology helps us! You can still record a short video to introduce design updates and collect feedback asynchronously.
Based on experiences I had in Nebulab, there are 3 actions we can implement:
- Share the design process: To create an open design process, designers have to share their process with the team. It doesn't have to be documented; even a list of steps is enough to make everyone aware of the phases and how they will be involved in the process.
- Review designs together and then present them to the client: To be aligned on the same goals, it's critical to review the design outcomes (user flows, wireframes, mockups) together with developers before presenting them to the client. This is crucial, especially at the beginning where the user flow has to be defined, and everyone needs to be aligned on the MVP scope. This is also important to create strong foundations for the process: a transparent environment where everyone can share their ideas or doubts without feeling judged.
- Find compromises: In an open design process, designers and developers are both responsible if the timeline can't be respected. This means that, sometimes, they have to find a solution that isn't ideal for designers or developers, but that meets requirements and reduces development time (also design-wise).
Conclusion
Designers are not asking developers to design, but they should ask developers for their feedback and expertise. By including developers in their design process, designers encourage communication and collaboration and make developers become supporters of design decisions.
