This post by Tom Johnson gives a fantastic overview of the limitations of static design tools and design/dev handoff tools. The author breaks down the various ways static design tools are detached from the reality of how things truly play out in the browser.
The author is excited that there’s a new crop of tools aiming to address these issues, and he rounds them up:
Rather than dragging around rectangles and then “exporting” to code, the code is the source of truth (in many of these tools) and is then backfilled into a more visual, design-friendly environment. Treating the code as the source of truth in my view is the right call. After all, users interact with that code, not some static representation of it.
I get asked about these new tools often. I too am excited about this new crop of tools, although it’s still early days.
My main concern about this new generation of tools is that they require a specific toolchain in order to function. “If you just use this version of React and just use this styling library and configure things in exactly this way, your designers can play around with coded components. It worries me that teams would end up choosing (and subsequently holding onto) specific tools not because they’re the best choices for our users but because the designers’ and developers’ workflow depends on a specific toolchain to work properly.
Don’t get me wrong; I think it’s important for this process to happen and again I think there’s a lot of promise to this approach in tooling. But I also think it’s worth addressing the potential downsides too.
So how else can we create realistic designs that address the myriad challenges and opportunities of the browser, including:
- flexibility
- impact of the network
- interaction
- motion
- ergonomics
- color and text rendering
- pixel density
- scrolling performance
- device and browser quirks
- user preferences
Tooling can help, sure, but it’s not a silver bullet. To truly address the realities of the medium for which you’re designing, designers and developers to collaborate as equals to solve problems together. That means more talking and real-time collaboration and less time spent throwing static artifacts and Zeplin links at each other.
If you’re interested in what this looks like, my colleague Dan and I put together a video or two about how designers and devs can collaborate to bring ideas to life and address the realities of the browser quickly. We also give a workshop on the topic, where designer/developer pairs practice this close collaborative workflow. We’re giving the workshop as part of the Artifact Conference in Austin and at SmashingConf in NYC.