As you should have heard by now, the development hand-off is dead. But why did it never really work? And how can we establish solid collaboration between you, the designer, and the developer? Let's dig in.
The waterfall methodology, which includes the so-called development hand-off, is dead. Although this seemed to be an industry standard, it never really worked according to seasoned creatives. You may have noticed already, that the industry is dropping waterfall widely. Many organizations are transitioning to the agile methodology and the scrum framework.
Due to changing requirements, constant new insights from the client’s side, insights in user behavior and novel arising pain points, you need to be flexible. The waterfall methodology certainly is not.
A typical waterfall process is based on fixed hours. Each discipline that contributes to the project has an amount of hours reserved for their activities. This inevitably leads to a siloed environment. Everyone is doing a quality job though. But then, they ‘hand’ it over to the next discipline down the waterfall. Never refining their work again, as there are usually no hours left when their work is finished.
When all of these factors are accumulated, they result in the following pitfalls.
The time pressure’s result is that designers often overlook technical constraints. The technical knowledge lies with the developer, but she can’t be contacted due to the limited time and siloes. In the end, the process lacked collaboration.
Due to the siloed environment and fixed hours, there is usually no room to discuss and refine. Because these hours are hard to account for, as they do not provide tangible results, like designs, copy, or working code.
Design requires multiple iterations in order to come up with effective solutions. When the requirements inevitably change during the implementation, the tangible results have to be revised and reviewed again. Which is both time-consuming and costly.
The hand-off assumes that designers can anticipate all possible scenarios upfront. However, in reality, user needs and requirements often change during the development phase. And since there is a fixed time for one discipline’s tasks, there is no room to refine.
The team where I’m active works agile. Through the scrum framework, we work towards the same goal of delivering software every 2 weeks – which customers and businesses value. This is such a different dynamic compared to the waterfall methodology. As both agile and scrum allow for better, continuous collaboration.
When I encountered agile and scrum for the first time, I thought collaborating would be peanuts. But due to the tremendous dynamic environment, I got a little lost.
I’ve assembled all my learnings. These are based on my own experiences and strengthened by additional research. The following practices are working quite well to establish great collaboration between design and development.
This one is crucial. Make it a habit. The developer possesses great technical knowledge. When you huddle upfront, technical freedom and constraints become clear. They can guide you towards multiple solutions. Even before you start designing.
This information can also be taken into account during design reviews with the rest of the team, and stakeholders. Setting good expectations and priorities.
Don't be afraid to show WIP. Development sees things from a different perspective. This increases the effectiveness of solutions. Plus, when agreed, you stand stronger since the entire team embraces the proposed solution.
Communication is key. Be sure to ask questions and dig deeper upfront, to understand the technical landscape. Keep this up, even during implementation. Sometimes consensus must be made, and these can be established through clear communication.
Although, this isn’t a favorite line to throw towards designers, it’s crucial in my opinion. I’ve seen designs distort a little, as Figma does not always translate pixelperfect to code.
As your designs need to be translated to – and not limited to – HTML, CSS and Javascript. Concepts I recommend to become familiar with are MediaQueries, which focuses on responsive web design, and Flexbox, organizing information in your design in a flexible manner. Which can also have an optimal responsive appearance when combined with MediaQueries.
Practice through Codecademy or W3Schools for example, as they offer free learning paths, exercises, and courses.
I don’t know about you, but dopamine kicks into my brain when I transform my designs to a web page with a cool URL that actually works!
Developers highly value modularity. Being able to reuse code. This increases the ability to scale the product, and maintain the code with more ease. Plus your designs become more consistent. Want to learn more about this topic? Check my Design System and Design Tokens articles out!
When a programming concept is explained, gain immediate feedback by translating the concept into your own words – preferably stripped from technical jargon. Ask the developer to validate if you understood it correctly. From my experience, this results in 2 scenarios:
If your organization is still in the transition of becoming agile, or if they are bound to waterfall, you can still find value in the practices stated above. Be sure to compress these practices down, to ensure you divide your time effectively.
It’s a heavy learning process. I experience this daily. The learning curve is rather steep. Hence, when solid continuous collaboration is established – and you will see the signs when it becomes solid – it boosts momentum and is extrinsically motivating. As a bonus it results in better relationships.