Handoff at GitLab
Context
In gitlab-ui#2558 we took a closer look at real handoffs to assess the impact of design tokens. All product designers we privately asked to share an example of a typical handoff, and their last handoff even if it was sub-optimal. Designers were offered a level of anonymity, links back to the issues and MRs analysed will not be provided.
Initial exploration findings
@danmh
received responses from 18 product designers and 1 front end engineer. The detail varied, but it was enough to get confidence in some design token recommendations.
RAW (annonymised) data coding → Google Sheet
In addition to analysing self-selected issues, here are some collected quotes that resonated.
Selected quotes from participants
-
“You should talk to engineers”
-
“I’m definitely of opinion that we rarely pay attention to accessibility when handing off designs and we don’t have defined boundaries for what is designer’s and what engineer’s responsibility in that regard.”
-
“engineers don’t typically go into Figma, so I bring everything to GitLab. I prefer to use design management but for complex features I need more than the 10 images design management provides, so I write directly in the issue.”
-
"Hoping to encourage more engineering engagement earlier in the process. Referencing colors directly is very rare, apart from some inconsistencies between text colors."
-
"Design manager is expected to be used as SSOT (push from EMs, both dogfooding a [..] feature and transparency/more obvious design history), and from talking to the FEs they either eyeball things and know that e.g. spacing is a multiple of 8, color is usually one of just a few options, or use some basic tools for measuring things in the browser. But that does mean there are cases where e.g. gray-900 gets used in place of gray-700, since devs assume a relatively dark gray = text-primary (if I forget a stray #000 text layer, this assumption works out well), or where a 12px total margin gets read as 8 or 16px. Those are not common, but do seem like they'd be clearer if using Figma for spec, and I'm not all that interested in writing out specs in a tool that provides them automatically."
-
"Getting engineers into Figma is something I want to pursue in the near future, though in our group I think this would mean still using design manager for "concept" and Figma for "spec", and having two sources may be a challenge. Tokens could help the argument for Figma as spec, as it would be even easier to see which token to use on the dev side, though I'm not sure that's any different than grabbing variable names today."
-
How did you know to update the proposal when it was picked up?
"We have a weekly team sync meeting, and our frontend dev said they were gonna take it on that week, so I revisited it because I knew it had been a while and things in settings had changed around. The dev also opened an MR with extra changes (the dropdown with the text in it) which I liked, so I updated the design proposal to match. My original proposal had that dropdown hidden when the setting was enabled, but it makes sense to show the text because of how big of breaking change the setting is."
-
Engineer feedback and questions?
"Typically minimal unless they have confusion about the changes or a suggestion on an implementation method. Otherwise progresses to an MR review either in code or a review app."
-
Some designers collaborated throughout their process. As a result there wasn’t really a handoff point. “Its not even handoff, they know whats coming”
-
Nice, from [issue] it looks like a key handoff point is when the engineer refines the issue
"Yes that is our current process. Design “completes” and then we have a refinement phase where the engineers ask questions and then schedule implementation issues if needed to be broken down further or sometimes goes directly to a merge request. That handoff to refinement happens when I mark an issue out of the worrkflow::design and label it workflow::planningbreakdown and usually I or the PM pings the engineers."
-
"It depends on the team and the engineers I’m working with. […] after you work with a developer for a bit you “develop” a bit of a shorthand, so handovers become pretty quick."
-
"In my previous job, I used Google Docs for handover, but engineers found it difficult to keep cross-checking between Google Docs and Figma Prototypes. So I switched to having the handover notes in Figma using sticky, listing the design tokens for all components and colours for the design. However, this requires every engineer in the team to have a Figma license..!"
-
"I'm not a huge fan of the approach of having a design specific issue for a feature, rather than it either being handled directly in the same issue we will use for implementation, or as the Epic which is then broken down into smaller pieces. The problem our PM is working around now is around keeping track of design work in a board with other items (if we used Epics on some things they wouldn't show in Issue boards), along with other things"
-
"I often times try to promote the engineers to keep track of design details through the use of checklists on those design issues (like in the example I provided), though I haven't been very successful in them going through those, and I often just check them off as I review the MR"
-
"a "typical" handoff involves me telling my PM that designs are complete. Ideally and typically, engineering has been involved with the design proposals before then, but we're going to pilot more of a strict design-engineering pairing to discuss what's in scope for MVC vs post-MVC"
-
"No typical handoff. It depends on the size and complexity of the proposed change."
Things to investigate further...
Design artefacts
In the sample these varied from full interactive prototypes, to annotated screenshots.
Every handoff sampled, both typical and latest, included a reference in GitLab itself. Either through images in the issue description, or using the design management feature.
Annotation methods
There were many annotation methods found across the sample. The most popular were using design management comments to highlight a specific element (5/23), and adding titles to images (4/24).
Annotations were less likely for changes I'd categorise as small.
- 2 out of 9 small handoffs sampled included annotation.
- 7 out of 7 large and extra large handoffs included annotation.
Unknown impact of time
Some handoffs in the sample had 10 months between designer 'handing off' and a developer receiving the handoff.
- Does this matter?
- If it does, how can we encourage engagement earlier?
Handoff to who?
Only 8 out of 24 handoffs analysed included handoff to engineers.
Handoff to a PM was much more common, seen in 15 out of the 24 sampled.
- Does this matter?
- Does this less direct collaboration have an impact?
What's included in the handoff
There were large differences in what was included in the different handoffs. Things seen include:
- Problem to solve and why
- Relevant user research
- Proposal for solution
- Design system components used
- How to measure success
- How to breakdown into MVCs
- Display across devices
- Display across modes
- Personas targeted
- Error and empty states
- User flows
- Logic diagrams
- Video walkthroughs
- Clickable prototypes
- Redlined specs
- And so on
Service design is 10% design
... 90% creating the conditions for design to happen.
That means understanding constraints, building relationships with stakeholders, getting funding, winning buy-in…the list goes on
Most of the handover analysed was not service design, but I think what the 'best' examples from this sample all have in common is most of the work went into creating the conditions, rather than the thing itself.
Separation of issues
Some handoffs happened in a 'design' issue. In some instances there were no links back to this issue from the build issues.
- Is information being lost?
- Is collaboration harder as a result?
Suggested next steps
- Take a closer look at the handoff, and see what can be more efficient