Creating Reality

Are you familiar with the game “telephone”? You might know it by a different name. The first person whispers something into the second person’s ear; the second person whispers what they heard into the third person’s ear, and it carries on in this manner until you get to the end.

Hold that game in your thoughts; we’ll come back to it. For now, I want to talk a little bit about a concept in programming called expressivity.

We talk about more modern programming languages and features as being more “expressive” than what came before. Generally what’s meant by this is that we can write code that more clearly and accurately describes our desired result.

React is a good example of this. React is a JavaScript framework for building user interfaces. It powers many web experiences and even many of mobile experiences you may use daily. And compared to what came before it, it’s very expressive.

Before React, if we wanted to programmatically render a label to the screen, we might have to write code like this:

const label = document.createElement("label")
label.setAttribute("id", "date-label")
label.innerHTML = "Start Date "

const input = document.createElement("input")
input.setAttribute("type", "date")
input.setAttribute("name", "date-input")
label.appendChild(input)

document.body.appendChild(label)

Whereas in React, we can write code like this:

return (
    <label id="date-label">
        Start Date
        <input type="date" name="date-input" />
    </label>
)

We describe code like this as declarative, insofar as we are declaring how an interface should render, instead of describing the procedure for rendering it (otherwise known as procedural programming).

Let’s take another example. Written communication is both highly expressive and often ambiguous. Take these examples:

I’m confused.

Sounds good.

Look at that huge hot dog.

Each of these garden-variety sentences can have their entire meaning changed with some small additions:

I’m confused. 😅

Sounds good. 🙄

Look at that huge, hot dog.

Our first sentence has gone from frustrated to friendly; our second has transformed from sincere to sarcastic; and our third has changed from delicious to disgusting.

Design tools have their own inconspicuous expressivity, too. With advancements of things like auto layout, components, and design tokens, we can infer a lot more from the structure of our design files than from their appearance alone.

Looking at a layer panel used to not reveal much at all about the design. Similarly, the mock-ups themselves can be ambiguous: given a grid of elements, do the elements appear from left-to-right, or top-to-bottom before wrapping?

When we use the expressivity of tools like auto-layout, these questions find their answers.

Disclosure Group

The simple game of telephone is a good demonstration of how a single medium is not enough to make sure an idea is shared consistently. Wouldn’t it be easier if you got to see a picture along with the phrase?

I wanted to share these examples to illustrate the point that design doesn’t just happen in design tools. It happens in conversations, writing, and—critically—it happens in code.

Should Designers Code?

I find this question so reductive, since code is just another tool for communicating.

It’s like asking: Should Designers Write? Speak? Gesture? Prototype? Wireframe? Design?

Design, in my mind, is the expression of an idea. It’s the exercise of getting an idea out of your mind and into the minds of others, through whatever tool we find most useful. It’s about creating a shared reality.

For digital product design, that often means something like a prototype or a mockup created in Figma. But why stop there?

Design tools create illusions. Code creates reality.

Everything that we do in tools like Figma is meaningless to our customers. Apart from a handful of research participants, no customer will experience your design as it is expressed in your design tool. They experience whatever your engineers build, which means that:

Engineers have the greatest leverage over user experience of anyone in the company.

At first, this might seem quite scary. But I think it presents an opportunity for us to arm ourselves with just enough knowledge to be dangerous. We want to be able to challenge our engineers to produce the best possible experience. We want to make sure our intent is adequately expressed in code. So let’s get to know who we’re working with.

Computers are cold, calculating, unforgiving, and incredibly stupid. They deal only in the simplest terms: 0’s and 1’s. Over the years, as technology has advanced, we’ve been able to build more sophisticated abstractions which allow us to write code in more expressive, human language, but it all gets compiled down to the same stuff: turn this circuit on, then off again.

It takes me back to the example of procedural programming from the beginning of this post. We have to tell the computer exactly what to do, and the order in which it must do it.

const label = document.createElement("label")
label.setAttribute("id", "date-label")
label.innerHTML = "Start Date "

const input = document.createElement("input")
input.setAttribute("type", "date")
input.setAttribute("name", "date-input")
label.appendChild(input)

document.body.appendChild(label)

There are two things this tells us:

1. Computers will only do precisely what they’re told to do
2. Any mistakes they make are therefore actually our own

I have a feeling that this is why so many designers not only don’t exercise their usual curiosity with code, but actively avoid it. We bury our heads in the sand at the thought of being confronted by the blind spots in our designs. Blind spots that are too often addressed by engineers who will make different decisions based on different approaches.

But this is also the nice thing about code. Not only does it make the contract between our idea and the computer’s reality concrete and specific…

It makes the contract between people concrete and specific in a way that visual design can’t guarantee.

Why should design be any different? Why settle for just sharing a mockup, when we can share a prototype, or a code snippet, or a message with a description?

There’s a whole other language of experience design that design tools can’t express, and that code can.

How do you know from a Figma prototype how a screenreader should announce an interface? Or how it should appear in different screen sizes? How it should appear when printed, or in different locales?

Code lets us express in unambiguous terms these otherwise-hidden properties of our work. It lets us add enhancements for technologies like VoiceOver. We’re doing a disservice to our customers and our colleagues by omitting or ignoring these details.

From “Should” to “How can”

So how do we begin to embrace this power? What needs to change in our approach?

Let’s think about what makes designers unique. Our habits of mind include:

1. Systems thinking
2. Creativity
3. Optimism
4. Collaboration
5. Communication
6. Attention to ethical considerations

What would need to change to allow us to harness code as a tool for communicating?

It seems only fair to ask: Should Engineers Design?

And in so doing, it makes sense to think about what makes engineers unique. Let’s look at their habits of mind:

1. Systems thinking
2. Creativity
3. Optimism
4. Collaboration
5. Communication
6. Attention to ethical considerations

That’s not a typo—it’s the same list. This list comes from the National Academy of Engineers; it’s their list of 6 habits of mind that every engineer adopts.

You already think like an engineer. You just use different tools.

And it’s important to embrace these differences in our work. Engineers may appear to speak a different language, but our goals—and even our approaches—are almost always the same. We should lean into these differences and learn how to speak their language, adding more nuanced and detailed expressivity to our work.

It’s not us vs. them. It’s us, together.

All you have to do is ask the questions left unasked by your designs, and answer those unanswered. Express your ideas with accuracy, or, failing that, embrace the ambiguity, and allow others to co-author the reality with you.