If you’ve seen me give a talk or ever worked in a design/development team alongside me, you’ll know that I really don’t subscribe to the “handoff” when it comes to designing and building things for the web.

Using a term like “handoff” implies that one person or team is throwing something over a fence to another person or team. This image is sadly not too far from the truth in the majority of teams like this.

Typically, a designer or team of designers will work away in isolating, using their design tool of choice for days, weeks or months at a time. Once they’re done (what they believe to be done, not actually done), they will “handoff” these designs to a developer and move on.

It’s actually far worse than that, and the tooling that we believe is helping us is actually leading to worse results.

Where we are today

It’s now the year 2020, and I personally know web designers and developers who still refer to the process of design to development as doing a “cut up”, stemming from the “slice tool” that was bundled with Photoshop as a way for designers to draw rectangles around areas of their image that would be automatically exported out as lots of image “slices” for a developer to use in their HTML and CSS build.

While my friend’s company is (hopefully) an outlier, and the idea of using the slice tool in the current day as a means of development handoff from a designer probably makes you say “Oh man, I remember when we used to that, back in the day… thankfully we’re past those dark times now” — I would argue that the reality is we haven’t had much tremendous amounts of innovation on this process.

Taking a look at the current crop of design handoff tools, the fundamental thing they all share is translating layers from a design tool into rectangles that you can click on, which can then either be exported as assets (“slices”?), or inspected to get some idea of what the CSS would look like to create this layer in a web browser.

Thankfully, Figma has all of this functionality built in and doesn’t require another handoff tool to be able to see these CSS properties or save out assets, which is great; but it’s not enough.

Designer’s gone wild (No restraints + “handoff” = chaos)

One of the reasons that this process is fundamentally broken is that our design tools — as good as they are in what they do — are still essentially open canvases that have little relationship to a production codebase (or code at all, for that matter).

No matter what tool you are using to design, you can grab any element and do almost anything to it:

• Change the colour
• Change the font size or line height
• Change the position or alignment
• Change the context where it’s being used

There are dozens more, but the point is that there are truly no restrictions.

That can be seen as either a bug or a feature. It’s a feature when you’re designing something that sits outside of an established design system or codebase that ships the a product to lots of people, and in the same way, it’s a bug when you’re designing something that sits within an established design system or codebase.

Once you have a designer moving things around, changing sizes of things, colours, alignments, grids, layouts, components etc, working on this for days or weeks at a time, getting everything ready for that perfectly crafted final version to “handoff” to a developer (using whatever tool that involves), you end up with chaos.

If the developer takes the design at face value, starts copying CSS code from the handover tools and blindly implementing whatever they see in the design, there’s a good chance that things are going to go haywire pretty fast.

Sadly, these handoff tools have really become an excuse for not needing to talk to each other at all. Instead of fostering designer/developer collaboration, they serve as a wall (or chasm) between them.

When a developer receives a design that contains a form with labels aligned to the right (instead of the left, as it is in their design system), without proper context, the developer might go ahead and do one of three things:

1. Assume that the designer must want to change this core component, make a global change to the form/label component, so every label in the codebase is now aligned to the right (instead of the left).
2. Hack together a very special bit of HTML and CSS that becomes super !important to the codebase, just for this once off thing.
3. Build it as a brand new component or variant, and publish it to the codebase for other developers to use in the future.

You’re probably thinking “well, obviously none of this would happen, because the developer would have asked the designer anyway once they knew it was a new design…”.

Sadly not. This is a real example that happened at a real (very large) company, and they decided to choose what was behind “Door #1” and roll out this change to the global codebase, until someone discovered what had happened and reverted it.

Where we need to go

To briefly jump back to the DesignOps meetup that I used to co-run; our singular focus, believe and mission was that:

“The distance between design and development should be zero.”

This can never be true when there is a wall between the design teams and the development teams who have no real relationship together, beyond the fact that they may (or may not) sit in proximity to each other.

As I mentioned, there are companies who still literally “slice” up web designs from static Photoshop or InDesign files and use this as a way of handing over something to a developer to build.

This is a process that most companies have become comfortable with, despite the downsides of widening the distance between designers and developers instead of the intended goal of reducing it.

As I’ve written and spoken about before, I absolutely believe that the future of the design and development will look very different from this process (and the other things that come along for the ride with it).

At the time of writing this, Figmatic is still a company of one. I am founder, designer, developer, marketer, copywriter etc. All I have are ideas and time, which are both somewhat constrained by each other. Even with spending almost every waking hour working each day, there are still only a finite number of things that I can work on and accomplish on my own right now.

There are much bigger, venture backed teams already working on solutions to much bigger tooling problem of making the codebase the source of truth of design, and I know they will be able to solve this problem based on their visions are trajectory. There is really nothing substantial for me to bring to that party right on my own right now.

So, as a bootstrapped solo founder, I decided to focus on what I can do right now, while still pushing things ahead in the right direction (reducing the distance between design and production to zero).

What we can do right now

With all that in mind, I recently built a Figma plugin called Pixelay, which takes your designs from Figma and streams them into the browser, overlaying them on top of your real website.

The reason I built it is because I’ve seen people go to great lengths to provide feedback on developer implementations after this (clearly, truly, wonderfully effective) “handoff” process we’ve just been discussing, including:

• Designers printing out screenshots of the build and writing pixel measurements on them with red sharpie.
• Creative director’s sitting with a developer for hours, pointing out pixel by pixel what is different from the original design.
• Having a meeting with 5-10 people to all review the design and build together, pointing out the differences for the developer’s benefit.

This is madness and this is normal at the same time. I think it’s killing the souls of both designers and developers, and it has to end.

Pixelay helps avoid these maniacal measures and literally brings the design and development environments together, where any differences between the design and build are immediately visible.

This is not intended to turn developers into mindless code puppets, where they blindly just make the design and build match no matter what. That may be the right answer sometimes, but other times, the developer might be using a pre-existing component that is out of sync with the one the designer has used from their Figma components.

The distance between design and production will eventually be reduced to zero, but until then, this feels like a step in the right direction to get away from thinking of design and development as two sides of a chasm that requires one to “handoff” something to another, instead of treating them as the same thing.