Code-Blended Design

Originally published on Medium

Code-Blended Design

This article was originally published on Medium on March 27, 2020.

For a long time, the design industry has shared many hot takes on whether designers should learn to code or not. To me, this is a pretty silly debate. Should a contractor do electrical and plumbing? Should an athlete play more than one sport? Should musicians play and sing? Should singers sing and dance? Yes? No? Maybe? It depends!

Okay, those might not have been the best analogies, but here is one: should designers write? Perhaps — if it helps them get a point across.

But I get it. There are a lot of designers out there who have never written any code and wonder if they should learn how. And these articles aim to help them make an educated decision.

Rather than pontificating on whether designers should learn to code or not, I believe a more interesting question is: should our design tools learn to code?

As I finish up writing this article I just realized Fabricio Teixeira wrote about this very question back in 2019.

Photo by Safar Safarov on Unsplash

What do I mean by Code-blended Design?

I'm still trying to work out exactly what this means, but generally I'm talking about designing with both a GUI and a text or code editor. Further, being able to interact with a file in a design application with all the traditional tools (artboards, frames, shapes, text boxes, pen tool, etc.) and also, optionally interact with the same live file with a code editor. Additionally, adding a layer of logic or scripting would be extremely valuable. But I will touch on that a bit later on.

This idea is far from new. Dreamweaver and GoLive were early WYSIWYG editors released in the mid-nineties. Today, we have applications like Framer X, Origami (not code per say, but has an interesting level of abstraction) and Webflow that, while all very different from each other, successfully blend "code" with traditional design editor interfaces.

I'm referring to "code" in the broad sense of articulating design elements and structure through words and syntax.

But these code-blending design applications are not the most popular. According to UXtools.co, the design applications being used by the most designers (UX, UI, product, etc.) are Sketch, Figma and Adobe XD. While these tools offer "developer handoff" features (Sketch's version is currently in Beta), they are pretty far from blending code and design like the others mentioned.

Now might be a good time to make the distinction between designing with code versus obtaining code output. This article discusses the former and does not attempt to argue for or against design applications that generate production-like code for an end product.

Also, the ideas in this article are primarily aimed at the big three design tools (Sketch, Figma, and Adobe XD). While these ideas can go beyond the big three, these apps are the most popular and are targeting similar users and use cases. So that's where my mind is as I write this article.

It's also worth noting that Apple is tackling this idea but starting from the developer side. Using their new SwiftUI framework inside of Xcode, you can craft a UI by declaring elements in the code editor or by dragging and dropping elements into the live preview. You can even modify attributes with some clever dropdowns and pickers. See: What's new in Xcode 11?

See also:

Why Code-blended Design?

Imagine you are creating a new project in Figma (Sketch or XD — it doesn't really matter). You decide to spin up a quick design system (it's often easier to start off using styles than trying to add them later). You start off by defining 11 or so named text styles and 20 named color styles. Oh, and also, you want to duplicate some of these styles for a dark-mode theme.

Doing all this would require a fair number of mouse clicks, double clicks, typing on the keyboard, back to the mouse, over to the layers panel, back over to the art board, and on and on and on. There are plugins that can help speed up this process, but these design applications are not really optimized to mass produce all of these styles for a design system. And maybe they shouldn't be.

Text and code editors are fast, powerful and extensible (if you haven't used a code editor much, check out things like Emmet and multi-cursor features). And for certain design-related tasks, like mentioned above, code editors may be a more appropriate tool. Doing a task like this with a powerful code editor could be accomplished very quickly.

Well, except that text editors are not really optimized for picking colors or fonts. That's where the blending of a code editor and a traditional design application really starts to make sense.

"Ok, I know I'll need 6 heading styles. I'll name them h1 through h6. For now, I'll just make them all 18 points and change them as I start designing"

You could quickly create the scaffolding of your design system in code — perhaps using placeholder attributes — and then, use the design application to modify and tweak those attributes in a WYSIWYG or GUI experience.

Sidebar: I just heard on a recent Design Details episode that the iOS app, Play (Beta) starts you off with a default set of these styles that you can then go in and modify. That's pretty smart. Looking forward to getting beta access!

Photo by NordWood Themes on Unsplash

Design Tokens

Now, you may be thinking "if designers take the time to create all this "code" to describe these design attributes, can developers have access and use them in their projects, too?"

Yes. Enter, design tokens.

Design tokens are becoming pretty popular in the design systems community so you may have heard of them. Back in 2016 Jina Anne and Jon Levine talked about how they use them at SalesForce.

Inside a design system, design tokens are the smallest parts — the sub-atomic particles. Included are things like colors, font size, font weight, border radius, shadows, sizing and so on. (I don't think it's just visual values. I can see having design tokens for things like notes, decibels and BPMs in sound design, bevel and emboss sizes in industrial design, etc.)

Design tokens are designed to be platform agnostic (usually stored in JSON or YAML files) so they can be shared across platforms like the web, iOS and Android. But what about Sketch, Figma and XD?

These modern design applications have their own internal design styles which are sort of like design tokens. But they are trapped inside — often difficult to import, export and maintain. For awhile now, Adobe has had CC Libraries but those only play nice across Adobe apps. They are also not very "sub-atomic".

For design tokens, I would like to see a universal standard emerge and our modern design applications natively embrace them by reading and, perhaps, even writing to them.

And this looks promising. There is a community group on GitHub working on a design token specification. Among others, Sketch, Figma and Adobe are all listed as represented.

If this is a likely future, this could also reduce some friction in switching or toggling between design applications. Let's say another design app offers better prototyping or animation for the type of feature you'd like to test. You could spin up everything you need a lot faster if that app can work with an existing set of design tokens.

But I digress …

See Also:

What are some other use-cases for code-blended design?

Design tokens are not perfect on their own. Assigning static values for colors and font sizes makes sense at this level. But how do designers arrive at these specific values? How do designers craft thoughtful color palettes and typographic styles?

Well, they can poke around color pickers and dropdowns for fonts, weights and sizes. But is there another way?

One of the things I love about Sass is its built in color functions. For example, you can very easily take a color and make it 10% lighter or 5% darker. You can also saturate it, desaturate it or shift the hue by 60º. These functions make it possible to generate color systems procedurally. Sass also has math functions. This can be helpful in creating typographic styles based on a modular scale.

Powerful functions like this give designers different ways to think about and make decisions regarding styles and design tokens. They can improve the way we calculate appropriate contrast and for legibility and accessibility. They can increase our efficiency and productivity.

I believe these types of code-blended-design features deserve to be brought into our modern design applications.

See also:

Anything else?

There are so many ways to push further on this idea of code-blended design in our design applications. Like adding layers of routing, scripting, and templating to make prototypes more dynamic and more choose-your-own-adventure-y. And taking that further by pulling in microcopy and data in more dynamic ways so we don't have to just keep duplicating screens to give the appearance of interactivity. And what about prototyping live map experiences, or real video and music players? The list goes on and on.

Again, there are a lot of plugins that aim to solve some of these shortcomings. And maybe plugins are better at addressing some. But I believe native, first-party support can provide a much better experience.

See also

It's also really important that these types of code-blending improvements do not sacrifice any of the main reasons these tools are so popular — approachability, ease of use, speed, etc. Similar to other power-user features, like components, states, and smart layout, interacting with these types of code-blended features should be completely optional.

So that's all I got for now. Let me know what you think. Do you currently use any code-blending design tools or applications? What are some other ways code-blended design can work for you and your tools?

Signed,
A designer who codes

← Back to Blog