You potato, me potato, why we should all hot potato (everything wrong with the designer-developer handoff file).
4 min read

You potato, me potato, why we should all hot potato (everything wrong with the designer-developer handoff file).

You potato, me potato, why we should all hot potato (everything wrong with the designer-developer handoff file).

What if I told you that the key to real collaboration between designers and developers was to stop creating handoff files?


  • Current large-scale companies are conforming to a conventional designer and developer workflow that is costing them resources (lots of ⏰ and lots of 💵).
  • By not addressing the problem, we are perpetuating a non-empowering workflow and mentality
  • The answer to solve this problem is right in front of us and we're choosing not to use it

But Julia, why would we do that? Why would we give up this Rosetta Stone-like file that enables designers to clearly communicate to developers what to code and how to code it?

Completely valid question. Why? Because I also had the same one. As a current design student, I was trained to understand how to press a button and "share" a Figma/Adobe XD/Sketch file to a given developer. School taught me that developers were people that I would never actually talk to, because we never covered what that communication may be like. Once I started freelancing as a digital product designer, I recognized that a bit of annotation is called for during the smaller scale handoffs that I took part of. However, in preparation for my internship collaboration with our contract developer, Clay, I searched more into the concept of creating a beautiful handoff file.

That file looked a little something like this:

A page from my annotated handoff file

I thought it was golden, and so did Clay. I was happy that I could provide my first-ever annotated piece with design tokens embedded within our communications. However, when I asked for feedback from my boss (a.k.a. Dan Mall), he responded with this:


Because, dear reader, contrary to popular belief, we at Arcade believe that collaborating a truly AGILE team means to actually follow the AGILE manifesto.

"We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value...working software over comprehensive documentation."

And what exactly are we creating when making handoff files? Comprehensive documentation...Yep. By creating these files, you're kind of being an AGILE hypocrite. And don't get me wrong, documentation can be helpful during certain contexts (more on that later), but overall, perpetuating the belief that this is the only formal/main means of communication that a designer and a developer will have when "working together" to ship a product.

🍱 We have siloed ourselves and therefore have siloed our workflows

While it might look nice an organized to have all the developers in one room and the designers in the other this workflow discourages person to person (or in our world now, Zoom to Zoom) direct collaboration throughout the process of creating a product.

Generally speaking, handoff files perpetuate a mentality that marginalizes designers to only owning the product at a certain point until handoff, but discourages further conversations about product definition and development the way a product should be treated: as a living, breathing, and constantly evolving thing. In the same way, handoff files place the pressure on developers to try to read minds of designers who produced the creative decisions in the first place, unless of course the designer spends countless hours redlining and speccing handoff files. This is something that is vastly encouraged by designers in tech companies because... well, it's the norm.

🙉 Here's the actual problem: we're choosing not to communicate

In our co-founder, Dan Mall's talks about Design System Pitfalls talks, he exhibits how the Airbnb Machine Learning Design System Prototype and the Jordan Singer Figma Prototype exhibit this notion of avoiding communication between designers and engineers perfectly.

Hours and hours of work are spent on creating products and pursuing disposable documentation that encourage avoiding communication between both parties. And if you've been doing this all your work life, it's not your fault in the same way that it wasn't mine.

So now what? If we can't document, what else can we do?

Talk. Communicate verbally. Collaborate together—simultaneously to create living code instead of a junkyard of Figma frames. This is also known as... wait for it—the hot potato session.


As exhibited in Dan Mall and Brad Frost's video below, a LOT can get done in just two hours by having a designer and a developer (figuratively) sit side-by-side with a goal of shipping something.

You can watch the whole video if you'd like or read Dan and Brad's separate articles on the matter. Here are things that I took away from literally learning why handoff files were the answer, then having to unlearn that in the span of 2 weeks:

  • I spent at least a whole workday on creating Clay's multi-page handoff file, when I could have spent 1 whole work-day (or even less) just sitting down with him to actually produce a usable website
  • Working together not only enables designers and developers to practice articulating design decisions, but also enables a genuine, real-time collaboration that encourages creativity, innovation, and testing for a better product
  • Handoff files should be helpful references/files of guidance, but not the whole conversation between designers and developers

The end(?)

After learning all of this, it truly does make me question current large tech company protocol of taking away such opportunities of collaboration between designers and developers. Moreover, it makes me upset that most of these higher-end tech companies ask prospective design employees to regurgitate design challenges one after the other. At the end of the day what should make designers stand out is their ability to communicate and articulate their design decisions for a product to actually be made.

What you can do now

I urge you to switch things up. I urge you to play by actually pairing up with someone (whether it is designer or developer) and work together to create a functioning product. How long it usually would take you with a normal workflow?How long did it actually take you? Did you learn something new from each other? Should you pitch this collaboration/productivity tactic to your boss and help your company save hours and money? How can this exercise improve the overall product value in your company?

I'd love to hear your thoughts on this matter, and can't wait to tell you all more about my upcoming Hot Potato session for the creation of v2 of our website!

Enjoying these posts? Subscribe for more