Why leaving Dev Handover to the end is a bad idea
It is well known that the
toIn order to get a flat design as close to the live build as possible, it takes a lot of work. As the industry has matured we have seen a lot of tools come and go, all claiming that they can help the process of Dev Handover with varying levels of success, but the principles of close human collaboration for me has always been key.
That's why, as a design team at Rotate°, we wanted to standardise the way we collaborate as departments.
The goal, the problem and 'jobs to be done'
Firstly, as with one of our projects, we discussed and aligned on the overall goal of what we were trying to achieve.
It turned out that it was to create a document to standardise and streamline the process of creating dev handover. But, as we began to research and discuss best practices around the topic, we realised that we needed to take a step back and rethink the whole process.
The problem(s)? As a team, we could see inconsistencies in the approach, expectation, and results. This inconsistency often led to confusion from both departments and, at times, created friction that got in the way of us achieving the great output that both teams wanted.
Again, as we do day-to-day in our client projects, we thought about the 'job to be done' of a Dev Handover and found that it was 'to communicate design assets to developers to implement, in its intended format. To reduce the need for QA after build.' This made us think more openly about our problem.
Solution
We began to understand that Dev Handover is often seen as a task once design is finished, but the key to an effective Dev Handover is to include it in every phase. This would ultimately create the best alignment of both teams to achieve success. So we decided to expand Dev Handover across three phases:
Onboard — Is during the
phaseAlign — Is the point where we exchange tasks between teams
Maintain — Is while the
is taking place
Onboard
We know it is key to ensure that we are preparing and aligning during the design phase to guarantee a streamlined handover and also validate our design decisions. So, we highlighted that we should start our Dev Handover process during the design phase because this is a chance for us to onboard all of our collaborators.
Designers check list
☑️ Assign time for artworking
☑️ Styleguide & components
☑️ Alignment on scope
☑️ Open communication
☑️ Prototype
☑️ Client sign-off
Example tasks in this phase
Building a style guide — This contains our project's fundamental rules, such as colour, spacing, type styles, and interaction information that will underpin the following build.
Prototyping — For more complex designs, we support any static designs with a prototype. We use this as a way to demonstrate any additional interactive and motion ideas.
Open communication — As the design process continues, we don’t forget about our soft skills, ensuring that all members of the team are regularly consulted, and scope is addressed before every client presentation.
Align
This is where the process that we traditionally considered Dev Handover is done. Once design is completed, we ‘Artwork’ our design elements and create the Dev Handover document. Our designers, in collaboration with product and engineering, become hyper-focused on the details by spending time stress-testing our components and modules to make sure we meet the acceptance criteria.
Designers check list
☑️ Figma house keeping
☑️ Display used modules
☑️ Show responsive behaviour
☑️ Display visual variables
☑️ Include UX flows
☑️ Add states & interactions
☑️ Annotate the unknowns
☑️ Describe motion principles
☑️ Display spacing edge cases
☑️ Conduct handover meeting
Example tasks in this phase
Showing the responsive behaviour – We display a visual representation of how the design should adapt to various screen sizes and devices. It is important to show the difference in layouts and interaction behaviours across devices.
Display visual variables — For designs with various visual variables, for example the ability to display different heading styles, we showcase all the instances and document their behaviour.
Include UX flows — When there is a design that has a multiple stages to the UX show each stage in the flow as a page.
Maintain
It was important for us from the outset to change the culture around Dev Handover from a thing you throw over the wall and never see again to something that was maintained. So, we highlighted that there are still some tasks to do after dev handover is submitted in order to maintain design and dev alignment. Design at this stage takes a back seat but still has a role to play.
Designers check list
☑️ Log changes by branching
☑️ Design QA
☑️ Design approval & migrate to master
Example tasks in this phase
Log changes to design — Both design and engineering should avoid making changes once files are handed over, but sometimes adjustments are needed once the build starts. We identified Figma's 'Branching feature' as the best way to transparently share changes with the team and outlined a process for the teams to follow.
Design QA — We ask our teams to identify the expected design QA review time. The engineer should notify the designer when the task is ready or if delayed, and our design team will respond within 24 hours.
Design approval & migrate to master — After design QA has been completed, there should now be alignment between the design and engineering teams. We now transfer our designs into a master document to establish the source of truth.
Conclusion
Cross-functional team collaboration is fundamental to the success of all projects.
With that in mind we should always look closely at how we can improve all aspects of our daily working practices. Here we intended to set a standard for sharing knowledge between departments to make sure the alignment of design and the final build was optimal. Notably we did this by shifting from a mindset of 'handover' over to 'alignment,' spanning the entire process not just the end of Design.
We also recognise that each task may be slightly different, so we use these principles as guidelines to help guardrail our expectations of a Dev Handover across projects and teams without suffocating every output.
