Version control: How a UX writer weighs one word against another
In UX design, a single misplaced verb can lead users astray, frustrating their expectations and creating confusion. That’s why UX Writer Henry Freedland chose his words very carefully when he was brought in to help polish a new prototyping feature.
Hero illustration by Antonio Carrau
Designing a product is a little like inventing new laws of physics. You inscribe a universe of activity waiting to be put in motion—by people, products, machines, and code. To understand how to navigate this universe, people need to know how the other agents behave; in other words, they have to know what falling is even if they can’t calculate the force of gravity. As a discipline, UX writing tries to find this balance.
This was my task when we answered our users’ request to please—for the love of all faulty hotspots—create some kind of prototype “offline mode.” Georgia Rust, a product manager at Figma, had pulled together engineers to create a scrappy working version, then refined it with product designers. It seemed close to shipping if some UI and performance complications could get ironed out—but first, they needed just a few words to explain the new functionality and how to use it.
As the UX writer who worked on prototyping, I was tagged in to consult on a menu string. I read through the discussions the team had been having and thought, Ah, once again. Language had exposed deep questions about what was really happening.
Version one: What’s under the hood?
What we think of as “loading” now is a subset of many types of loading throughout computer history. “Booting,” for example, is a shortened form of “bootstrap loading”—the idea that a computer has to somehow load itself to start. That phrase is a reference to the 18th-century idiom, “to pull oneself up by one’s bootstrap.”
At first, the stand-in phrase was “Preload prototype”—very exact about the programming function.
Prototypes usually load screen by screen as you interact with them, rather than all at once. This new option would allow you to load everything upfront and keep it long enough to present. In code, improving web performance by gathering important assets early in loading is known as “preloading,” so if you have a technical mindset, the verb communicates the experience reasonably well.
For everyone else, “preload” is tricky. It’s accurate, but asks a person to enter a time loop. “Pre-” indicates something happening before another, as in “preheating” an oven. In that example, you expect your oven to go from off to on. When seeing this option to “preload,” on the other hand, you would have already gone through a loading screen to have the prototype displayed. What we mean is that you can load the rest before doing anything else—going offline to present, say. But to realize that, you’d have to know more than we’re telling you.
A more understood computer action is the common act of “loading”—might that have worked here?
We played with nouns—“Load full prototype,” “Load all screens,” “Load all assets”—but each of them felt like they broke central trust between the person and the program. You just loaded this prototype; why would you know it’s not all there yet? To load is a wonderfully evocative action your computer can tell you it’s doing on your behalf. But when it’s done, you need to believe it’s done.
Version two: What’s the point?
In writing for software, it’s important to wonder why the user is doing something at all. What’s the goal? In this case, it was clear: People needed to present dependably without internet access. “Present prototype offline” or “Prepare to present offline” aim right at someone’s desire. But are they the right verbs in the right phrases?
Computing pioneer Terry Winograd wrote back in 1987: “People act through language.” When we put a phrase in front of a person in a menu, we’re establishing their point of view. Most of these phrases are either imperatives they’ll direct at a program or inclinations that can finish the sentence “I want to…” The words have to connect a person’s mindset to computing actions that will deliver some kind of result. If there’s too big of a gap between the thinking, the words, and what will happen, the encounter falls apart.
The gap with both iterations felt pretty big. To click “Present…” without presenting is severely delayed gratification. And to click “Prepare…” without knowing what that preparation is or how early you need to call for it is too ambiguous. Either of these could work if we had a larger experience planned, following up with granular actions for the user to follow. But that wasn’t our UI; both felt too imposing for a menu option to toggle on.
Version three: What can you control?
There’s a point in all product writing when words start to feel nearly interchangeable. Invariably, someone says, “Who’s really going to notice except us?” But I genuinely believe that an individual verb has a unique power to create. It can arrange the matter between you and the object of your attention. It spotlights the focus of an encounter, lighting the lamp to work by.
So what phrase would guide a person to use Figma as a supportive partner? We could try a verb that was about enablement—a gentle nudge from a person to a computer to work together.
“Make” is a soft imperative that still offers someone a sense of firm authority. Unless we’re ship captains, we don’t generally go around telling people to “Make it so.” We do, however, affect the world with it: We make dinner, make a fuss, make sense, and make things right. Perhaps here a user’s role is really to instruct Figma now, in the moment, about what it needs later, when presenting: “Make (it) available offline.”
Very close to right, but still not quite enough. “Make available offline” might make you think something will be downloaded onto your computer forever. And there were a few team members who were concerned that this was ambiguous for people who just wanted better prototype performance—even while still online. So we needed a little more language to bring home the final version.
The final version: What happens next?
PARC ethnographers placed a Xerox high-speed copier in a room and observed people using the machine.
Back in 1983, a grad student in anthropology named Lucy Suchman set up a camera to observe people struggling to use a new high-speed copier. In one video, two researchers are trying to figure out what the machine knows about what they’re doing and why unexpected things are happening.
Lucy took note in her later writing: It was not only vital for users to know what to do, but also for a computing machine to make plain what it was doing—and why.
We needed to remember that it wasn’t enough just to get someone to click; we also were responsible for making sure they knew the implications of what was happening. So, for the final experience, we added icon states at the top of a file, accompanied by more explanatory language, connecting the technical situation to the overarching goals of the experience itself.
We used the commonly understood idea of “downloading” to describe what was taking place as the file assets moved from the cloud to your browser session, though not to your device storage. And once it was all ready, we gave a reminder about what you could finally do—present offline—alongside clear markers of actions you should and shouldn’t take if you wanted to do that in the future—keep the tab open because closing it will clear the download.
Simple, really—just a few words, after all: make, keep, present, close, clear. A parcel of minute actions orbiting one another in a big Figma universe.
Thank you to everyone who worked on this, including Georgia Rust, Connor Skees, Tim Van Damme, Niko Klein, Jackie Chui, Jediah Katz, Stephanie Cheuk, and John Lai.
