All work

Kiwi.com · 2022

Redesigning the design delivery workflow

A participatory process to define how the team delivers, giving designers a shared framework for deciding what comes next.

CompanyKiwi.com
Year2022
RoleProduct Design Lead
Tags
Design OpsTeam ritualsCross-functional

Background

As the design team at Kiwi.com grew, the quality of design delivery became inconsistent. The core issue was not skill but structure: designers, particularly those earlier in their careers, lacked a clear framework for deciding how a project should continue at each stage. Without a shared definition of what it meant for a design to be ready, individual judgment filled the gap unevenly. Some necessary steps were skipped. Handoff to development was unpredictable, and the back-and-forth that followed consumed time on both sides.

The handoff phase was the weakest link. I took it as the starting point for a broader workflow revamp, with the goal of producing something the whole team, designers and developers alike, had a hand in defining and therefore a reason to follow.

The approach

I identified all the people whose input mattered most: the designers and researchers producing the work, the content designers contributing to it, and the developers who would receive it. With stakeholders who think so differently about the same process, I knew a document circulated for async feedback would not produce the depth of alignment we needed. I organised an in-person workshop at the Barcelona office instead, bringing together product designers, UX researchers, developers, and a content designer in the same room.

I defined the goals, designed the session structure, facilitated the day, and processed the output into the two deliverables that came out of it.

The workshop

Idea generation

After an icebreaker to get the group moving, participants generated as many ideas as possible about what a design needed to be truly ready for delivery. The diversity of the room was the point: developers and designers have fundamentally different vantage points on handoff, and putting them in the same exercise produced ideas that neither group would have surfaced alone.

Clustering

With everything displayed as a wall of sticky notes, we worked together to group the ideas into categories. The category names were defined collaboratively through open discussion rather than imposed by me. That step mattered: shared language around shared categories made the output feel like the group's, not the facilitator's.

Consolidation

The clusters were assigned to pairs of participants, who worked together to turn each group into a concrete list of actionable items. By the end of the session we had a jointly-produced set of actions covering what every stakeholder needed to do for a design to be delivered successfully.

Workshop in progress: sticky notes clustered on a whiteboard across requirements, use cases, platforms, documentation, and stakeholders
The clustering phase: ideas from all participants grouped into named categories that would become the structure of the final deliverables.

The output

I processed the workshop results into two documents, both presented to and approved by design leadership.

The first was a definition of done: everything a designer needed to check before considering a design ready for handoff, organised across six areas covering approval, use cases, flows, platform considerations, components, and documentation. Each area contained a set of items to either confirm as covered or mark explicitly as not applicable. The intent was to give designers, especially less experienced ones, a concrete tool for deciding what came next rather than relying on judgment they had not yet built.

The second was a handoff and dev support guide: steps and considerations for conducting efficient handoff and ongoing development support, covering communication, documentation, change management, and design QA. This was shared with developers as well, since handoff only works when both sides understand what the process looks like.

Definition of done and handoff checklist structure
The two output documents: a definition of done covering six areas, and a handoff and dev support guide shared across design and engineering.

Key outcome

Friction in the handoff phase reduced noticeably. Designers, particularly the more junior members of the team, became more autonomous: instead of escalating decisions about how to proceed, they had a framework that answered the question for them. The definition of done became a decision-making tool as much as a quality checklist.


Outcome

Both lists were implemented as checklists in Jira and fed directly into a subsequent redesign of the Figma file structure. They also served as the foundation for several follow-on Design Ops projects, including updates to UX metrics and automation of design QA reporting. The workshop produced more than its immediate output: the process of building it together meant designers and developers arrived at the same understanding of what good delivery looked like, which proved harder to achieve any other way.