Stop trying to fix the handover process

The design handoffs are a standard in every product team today. 

1. UI/UX Designers draw up the UI for a new feature

2. Designers send the design to the Engineers

3. Engineers implement the design

4. Go to step 1

For as long as the design handoff has existed, people have been trying to fix it.

The design handoff makes it impossible to iterate quickly. The steps above represent a utopian view of the process. In reality you usually end up going back and forth between step 1 and 3 several times before the feature is done. This isn’t a failure of the team. We have long known that the assembly line approach to software development doesn’t work. As an industry, we collectively rejected the waterfall model decades ago, yet the tools we use today are still designed for that era.

The second problem is that information is lost at every step. The majority of designers today have little to no technical understanding of the platform they are designing for, whether it is the web or native apps. They also often lack an understanding of the technical limitations of the system the team is building. This impacts their ability to design functional solutions and is usually not discovered until the implementation starts. The design tools we use today are exclusively focused on the visual aspect of design, and provide no way of describing the functionality. How something behaves is just as important as how it looks, but behavior is all too often excluded from the design handoff.

There are many more problems, like the fact that every feature has to be built twice — Once by the designer in the design tool and later by the engineer implementing the feature, but we will focus on the first two.

I have come to realize that these problems aren’t incidental — they’re baked into the very nature of the design handoff. They are not edge cases to be fixed; they are the logical outcomes of splitting design and implementation into two separate worlds. If we want to solve them, we can’t optimize the handoff — we have to eliminate it entirely.

Can’t we just generate the code?

In order to speed up development, several companies have tried to automate the handoff process by generating code based on the design. Figma tried to do this by connecting the developer's code editor with Figma and generating code directly in the text editor when the Figma file was updated.

Recently, we have seen tools attempt the same thing but using AI to generate the code instead of a normal compiler. While AI does add some improvement over the previous solutions, the two main problems with the handoff still exist:

The design tools we use today are not designed to create working applications. Just like with the handoff, much of the critical information is lost in the process. AI can attempt to guess what was intended, but it ultimately can’t know what the designer was thinking at every step.

The process still only works one way. When the design is updated, the code has to be generated again. If one of the engineers made changes to the code after the handoff, those changes will be overridden. In order to enable fast iteration, we have to eliminate the handoff altogether so designers and engineers are free to iterate without stepping on each other's toes.

Should designers learn to code?

That is one solution that does address the problem, but it also creates a new one. It used to be the case that all you needed to know was a bit of HTML and CSS in order to style a website, but for most web apps that is not the case anymore. With the introduction of web frameworks, TypeScript, and various build tools, the barrier to entry to web development has increased by several orders of magnitude in the last decade. Upskilling every designer to essentially be a junior frontend developer as well is simply not feasible.

Designers writing code is not the answer. That is probably a good thing. A large part of the design process is visual, so code was never really a good fit.

Hiding in plain sight

It turns out that the solution was right in front of us all along. We are not the only industry that has faced this problem. The game industry faced the very same problem, and over 30 years ago, it solved it. Every new game that has come out in the last 20+ years has been developed using a game development engine, which is essentially a framework and a set of design tools bundled into one: a single tool shared by both designers and developers.

Designers are not just drawing pictures of the characters and worlds in the game; they are creating them in the very same tool where the engineers are programming the logic and behaviors. Updating the design does not break the logic, just as changing the code does not invalidate the design. Designers and engineers can iterate on the same features without overriding each other's work.

Every major game engine even has a visual scripting system that lets designers create much of the logic on their own. Where the tools we use on the web are enforcing silos, game engines help break them down.

In the game development world, it means that your tools and workflows can now be adapted to the capabilities of the team. If you have a designer who is very technical, they can now own much more of the process without needing the assistance of an engineer. Similarly, designers who want to focus exclusively on the visual design of the application can do that without requiring the engineers to duplicate their work.

There is not a game studio today that would ever entertain building a video game without the use of a modern game engine and the excellent tools that come with it. It is an absolute necessity when building AAA games that have to push the boundaries of creativity and raw performance.

The future of web development tools is borrowing from that same idea, but designed from the ground up for the web. This is a whole new category that we are calling a Web Development Engine. Web development engines combine interactive design tools with a powerful web framework. Web development engines are designed for high-performing product teams. Just like game engines, the goal is not to lower the bar for entry, but to raise the ceiling for what we can accomplish.