Prototypr

Prototyping, UX Design, Front-end Development and Beyond 👾 | ✍️ Write for us…

Follow publication

Can we talk about design handoff for a minute?

--

If you are reading this article I guess you already know what it is, but just in case: Design Handoff is the process of handing off the designed material to the developers so they can implement the design into a funcional … thing (web, app, whatever).

In the old ages, like five years ago, the process implied creating an exhaustive and detailed description of every element of the design (text file) and all the assets needed (organized in folders). Then these files were given to the developers so they can re-create the product in code.

This is what one of my handoff documents looked like 5 years ago.

So at the beginning there was darkness and times were difficult. We were dealing with Photoshop and Illustrator files and manual handoff processes. Then The good Lord created Sketch and saw that Sketch was good. And thus We are now living in a modern, marvelous era and the handoff has become exponentially easy thanks to tools like Avocode, Zeplin, Invision Inspect and so on.

So now the designer can hands the handoff file to the developer and s/he can get, autonomously, every posible measure or data or asset s/he needs to re-create the design without the need of the original design file or bother the designer. And this is so good and fast that it’s almost a miracle. So …

Handoff

… Why it’s feels to me so stupid and such a waste of time to re-create again something that was once completely done?

Please, bear with me for a moment here.

Handoff means that the very same moment the design is handled to the developers , there are two different versions of the project: the original design and the coded version.

If for some reason the design must be updated (I know, I know, it never happens, but just in case) , the coded product must be updated as well. Since they are different products, maintained by different people, both must be updated separately.

So, when there was one, now we have two and that means that, issues and time, like Entrophy, will grow exponentially. Welcome to the wall.

Quantify

To have an approximate idea of how crazy this is, Let’s try to quantify the time it takes to re-create the design.

Design

Let’s say that it took one designer 3 hours to layout a simple design. Nothing really fancy. No animations, no backend connections, just layout, I’m not accounting for the design time, since it’s really hard to measure. Layout time is way easier to quantify.

Let’s also asume that the design needed another 1–2 hours to include client’s feedback.

Implementation

Create something from scratch like the coded version of your product, needs time. Let’s say the developer will need at least four times what was needed to design it (I think I’m being conservative here, it’s probably more).

Now applying the rule of 4 times the layout time, let’s say that implementation will need somewhere between 16 to 20 hours. Between 2 and 3 days.

Now Take into consideration the rounds of feedback you’ll need to fine tune the coded version to be faithful to the final approved design. Let’s be naive and think that we it will only take 3 – 4 more hours to do the fine tuning.

Implementation time so far: 20–24 hours.

In between

Probably somewhere in the middle of the journey your team has setup something like Jira or Asana or Redmine to keep track of the issues. Also your team has prepared staging and production servers, right?

Let’s add another 2 hours.

Total implementation time: 22–26 hours

Issues

After painfully finishing the implementation and when everything is almost ready, someone (client, designer, project manager …) has changed her/his mind and now something needs to be adjusted in the design. You know, something really, really super critical, like , I don’t know … the text color of the footer.

So the designer fills an issue on Jira, or marks the issue on Zeplin or just send an email (or all of them combined, believe me, it happens) [1 to 5 minutes]. Some time after that, the developer opens the issue and starts working on it [5–10 minutes]. When finished, s/he will update Jira and will push the changes to the staging server [2 minutes].

Now it’s the time for the issuer to review the changes [2 minutes]… and start the cycle again.

So, a really simple issue iteration cycle will take only about 10–20 minutes to be solved.

A really complex issue or a full component redesign can take from several hours to even days. Let’s imagine full redesign of complete sections. And that, in my humble opinion, is the Achilles heel of the development: the after issues.

But for the sake of argument. Let’s say that the project goes really smooth and only has a total of 5 minor issues.

Issues time: between 1–2 hours

Total implementation time: 24–28 hours

Push to the production server:

It should be less than 1 hour. Just in case let’s count 1 hour.

Grand total

  • Layout Time: 5 hours
  • Implementation Time: 26 hours (just the middle)
  • Publishing Time: 1 hour

Total project’s measurable time : 32 hours.

Now the important number: Amount of project’s time dedicated to implementation:

I’ve presented the easiest scenario posible and I’ve considered everything going smooth as silk. And yet we are using an average of 80% of project’s time to re-create the design.

Now, just remember: The design was already created and fully detailed. Isn’t crazy?

Q&A

So here are my questions:

What if there is no need to translate the design? If the design is the final product? What if we can kill the handoff?

What if instead two different products we have only one?

What if the designer fixes the design issues and the developer fixes the coding issues? Even more: What if designer and developer can work at the same time in the same project without interfere each other?

And here is the best answer I have found for all those questions:

Sign up to discover human stories that deepen your understanding of the world.

Free

Distraction-free reading. No ads.

Organize your knowledge with lists and highlights.

Tell your story. Find your audience.

Membership

Read member-only stories

Support writers you read most

Earn money for your writing

Listen to audio narrations

Read offline with the Medium app

--

--

Published in Prototypr

Prototyping, UX Design, Front-end Development and Beyond 👾 | ✍️ Write for us https://bit.ly/apply-prototypr

Responses (5)

Write a response