The best design handover is no handover at all. Why are our tools lagging behind?

Edit: A week after the release of this post, Adobe and Flutter announced a plugin for Adobe XD that makes it possible to export designs into working Flutter code. I haven’t tested this plugin yet, but I’m reasonably optimistic about its chances to succeed because of the first-party support from Flutter. The plugin is now in early access for public testing.

One of the biggest challenges in working as a designer with developers is always the handover. In an ideal agile project, developers and designers would work next to each other and be able to discuss and solve problems as a team. Unfortunately this is not often the case, especially during challenging times like these, when everyone is working remotely.

In the worst cases, the designer has barely any time for the handover and the developers only get the designs and a brief memo. No wonder the word handover has such a bad name.

When the ideal co-creation setup is not possible, the handover process needs to be efficient. In my opinion, the biggest gap in this process tends to be caused by the different tools used by designers and developers. When a designer creates a prototype with their tools of choice, the developer has to interpret the prototype and translate it into code.

Going towards a mutual toolset?

Just a few years ago, designers typically had to use three separate tools to get the job done: one for drawing the designs, one for prototyping and one for the design handover. Today, tools like Sketch, Figma and Adobe XD all support drawing, prototyping and design handover.

Even with today’s capabilities, there is still a gap that is most visible in the limitations of the design handover features as well as in visibility of the actual code. Demand for a genuine integration of design tools with code is increasing, especially with the rise in popularity of design systems.

But there is also another route that could be taken here. What if instead of trying to integrate design tools with code, developers and designers could just use the same toolset? This is the question that came to my mind when Apple released its new UI toolkit, SwiftUI. If creating UIs is truly as easy as SwithUI’s pitch makes it out to be, then maybe even designers could use it and dedicated design tools wouldn’t be needed at all in the future.

Searching for the holy grail

The innovation in bridging the gap between designers and developers can potentially come from either design or development tools. Right now, the design tools seem to be further along this path.

The holy grail of design tools has always been a tool that makes UI design easy, that can export designs to actual code. There are some tools that claim to do this, but none of them have really taken off. I suspect it’s because of the complexity of the task. 

This isn’t the only approach that design tools can take. Framer X, for example, is a very interesting tool because it merges a regular prototyping tool with the ability to use actual React components in prototypes. This means that if you create a design system with React, Framer X can be a really powerful tool for designers.

From the perspective of development tools, the goal is to build a toolset that makes designing and prototyping, in addition to coding, so easy and fast that the need for separate design tools just goes away. This is not exactly a simple task.

This situation reminds me a lot of the famous battle inside Apple, in which they created two separate projects to build the iPhone. One project created a phone based on the iPod while the other created a multi-touch phone based on MacOS. The limitations of the iPod turned out to be too great, so what we now know as the iPhone is based on MacOS.

I can’t help but think that maybe the same will eventually happen to design tools. Using a separate prototyping tool can be very easy and fast, but will separate prototyping tools end up becoming too restricted compared to what actual development tools can offer?

SwiftUI for designers

As I mentioned before, I got interested in this subject because of SwiftUI. Let’s have a look at how it fares in this regard at the moment.

First of all, in order to use SwiftUI, you will need to learn to code at least on a basic level. So we can’t avoid the age-old debate on whether designers should code or not. Knowing how to code makes communicating with developers much easier, but at the cost of more likely limiting yourself to designs that are easy to code. There’s naturally a lot more to this discussion than just these two points, but I won’t be going into them in this article.

With that out of the way, the very first thing that really struck me about SwiftUI was how much it reminded me of web development. Because of the new syntax, writing code feels very much like writing HTML with inline CSS and JavaScript. 

Live previews work pretty much as the Inspector does on browsers. You can make changes to your code and instantly see the changes in the live preview. This feature is especially important when you are fine tuning UIs.

But what really blew me away was the ease of creating animations and gesture-based interactions. Even though there are prototyping tools that enable this type of prototyping while being even easier to adopt, the ease of creating actual working gesture-based UIs really impressed me.

Using SwiftUI in the real world

So SwiftUI clearly has potential, but could it be used as a prototyping tool in an actual project? In theory, yes, but this comes with many caveats.

Even though coding in SwiftUI is much easier than iOS coding has been before, it’s still coding, and expecting all designers to become unicorns isn’t realistic. Also because SwiftUI is proprietary to Apple’s ecosystem, utilizing it as a design tool in a team that does both iOS and Android development won’t be feasible either. And finally, distributing prototypes with developer tools is far from easy, at least when compared to more or less any prototyping tool on the market.

But if none of these caveats are an issue, the potential is there. The most realistic approach I can see could be to mimic the way Framer X works. This means giving designers access to a design system repository built with SwiftUI, which they could then use in Xcode to create prototypes with the actual components.

Where do we go from here?

There is a clear need to integrate the entire design and development process into a single toolset because of the popularity of design systems. The big question is, will design tools evolve further to fill this need, or will development tools start trying to take control of not just development, but the design process too.

What I find most surprising is that Apple, which traditionally wants to control all aspects of development for its platforms, still seems to be OK with allowing other companies to own the tools of the design process. Because of this discrepancy, I’m going to make a prediction. By WWDC 2021, Apple will have either released their own integrated design tool or acquired an existing one.

But for the time being, dedicated design tools are still a must for the vast majority of designers. For those who feel like trying to bridge the gap between design and development, I would look into Framer X if you are working on a React project and have a design system set up. Otherwise, I feel there is still a lot of room left for innovation.

Illustration: Niina Nissinen