Executing a foolproof design development ‘handover’
No matter the type or size of business, when working with existing or new development partners; problems concerning output are identifiable:
- Poor build quality and extreme lack of care
- Lack of capability or technical understanding to solve problems
- Ignored design documentation
- Lack of QA (Quality Assurance)
- Lack of team chemistry
- Closing development tickets pre-maturely
- Skipping essential parts of the development cycle e.g., VQA (Visual Quality Assurance)
When these problems arise, it is easy for businesses to shift blame to the developers. However, multiple parties are accountable for the quality of the final deliverables. The low production rate results from teams not interacting effectively.
When colleagues leave or join a team, knowledge gaps arise in the context of the product, ways of working and technical understanding. Cross-sector communication can also be a blocker. For example, language barriers between design and development teams; each team and business have unique acronyms and phrasings.
Businesses have expectations and standards related to processes, management, and deliverables. Therefore, projects become blocked and need additional review if acceptance criteria fail to align across teams.
Post understanding and identifying the problems, the objectives of the business should be to:
- Standardise and uniform ways of working to ensure clear expectations from the outset and that all parties are on the same page
- Increase collaboration permitting direct crossover with development teams
- Increase creative team understanding so that designers can easily feed in and out of development enhancements streams
Every company has a unique way of communicating, and therefore, the design development handover process will be different. The term ‘handover’ should be interpreted loosely as walking away from a design once in development allows third parties to implement their standards, processes and assumptions. There should be no room for error, and the process must be collaborative. So, what is the best development handover?
Opening conduits of communications at strategic milestones within the creative process enables designers and developers to establish constraints and requirements alongside building trust and relationships.
Low fidelity wireframing
A low-fidelity wireframe is intentionally basic to focus on design and flows rather than intricate details. Wireframes are also an opportunity for developers to make critical decisions about HTML structure alongside CSS attributes such as position, size and layout.
Include only essential features and opting for a mobile-first approach results in a content-focused approach. Scaling upwards to larger screens is much easier than scaling down. After scenarios are refined, peer-reviewed and signed off, this should be the first point of communication with the development teams.
Discuss the skeleton of the solution and review technical feasibility before taking concepts forward — allowing development teams to familiarise themselves with tickets lower in the creative backlog. Additionally, it’s much faster to modify designs at low fidelity if technical concerns are flagged.
Hi-fidelity design & documentation
Hi-fidelity design is an accurate representation of the user interface. It’s the surface and concrete details of a solution’s appearance. Designs should once more be peer-reviewed and signed off by business stakeholders at this stage. Solutions may also require testing to validate assumptions concerning user behaviour.
The capturing of ‘what-if’ scenarios also ensures no room for assumption during development. For example, when someone on a project considers interaction and thinks, what if the user wants to do X? How would this interaction look? How would the element or component behave?
Developer documentation should also consist of:
- States ((none, hover, pressed, focused, focused (keyboard))
- Behaviours, interactions and motion, e.g., ease-in
- Accessibility guidelines (alt-text, aria labels, click areas, heading hierarchy, screen reader flow, tab order)
- Classes (existing and new)
- Markets usage guidance — typically captured post-build release to ensure content admins use solutions as intended
- Supporting documentation (if required)
- Prototype — better demonstrate user flow, states, behaviours, interactions and motion
- Asset pack — imagery and iconography
- Copy matrix — text translations for markets
New components must be fed into the design system for other creatives to access, as design systems require continuous maintenance and oversight to ensure they don’t become outdated, obsolete, or overcrowded.
Always conduct a second design review with development teams before formal handover. This time allows designers to walk through the final solutions and let:
- BAs (Business Analysts) to commence the capturing of ACs (Acceptance Criteria)
- Developers to query any uncertainties as well as walkthrough the approach for implementation
When working agile, development teams conduct daily stand-ups, which a designer should attend for regular build status updates. These traditional ceremonies allow developers highlight additional design queries and for designers to provide further guidance if required. Developers should operate systemically and adhere to the creative team designs, scenarios, developer guidance, design system and component libraries.
Ready for VQA checklist
Development teams (BA and developer) must review builds and complete a checklist to ensure they are ready for creative review. The VQA will not commence unless the following criteria have been implemented:
- Link to the creative brief
- Have all acceptance criteria been delivered?
- Has all developer documentation been captured?
- Does the build adhere to the design system?
- Are builds authored for all valid design scenarios?
- Do builds visually match the designs across all breakpoints?
- Has code bloat been minimised?
- Is their budget and time to conduct 2 rounds of VQA?
- Has the creative been assigned to the VQA subtask?
- Build URLs
BA & designer walkthrough
The next touchpoint is for the BA to schedule a call with the creative to walk through the builds. The BA’s responsibility (acting as the middleman) is to mediate between design and development. Therefore, the BA should thoroughly understand and have oversight of design scenarios alongside acceptance criteria.
VQA can begin after the ‘Ready for VQA criteria’ have been fulfilled, and both BA and designer are happy to proceed. The purpose of the VQA is for the designer to stress-test the builds, looking for interface bugs and inaccuracies. It is to be used as a fine-tuning exercise only.
After the creative captures necessary change requests, it’s the responsibility of the development team to implement the changes. Discussing change requests individually with developers is valuable to ensure all parties are clear on the intended design. There should be a maximum of 2 rounds of VQA. If VQAs span more than two rounds, it’s a symptom that there’s a problem within the development cycle.
If a development team’s output begins to deteriorate, there must be a system to fall back on. Therefore, implementing strategic touchpoints with developers and essential business stakeholders will improve the volume and, most importantly, the output quality.