Figma's offline prototype mode: A case study in UX copy
When Figma users asked for a way to present prototypes without an internet connection, the feature that resulted was relatively straightforward. The harder problem was the words attached to it. Henry Freedland, a UX writer at Figma, joined the project close to shipping to consult on a single menu string—and found that the team's language exposed deeper questions about what the feature was actually doing.
The limits of technical accuracy
The first draft, "Preload prototype," was precise about the mechanics. Typical prototypes load screen by screen as you interact with them; this option would fetch everything upfront and hold it for a presentation. In web development, that behavior is called preloading, so for a technically minded audience, the verb is descriptive.
For everyone else, it asks you to rewind time. "Pre-" implies an action that precedes another, like preheating an oven. But by the time you see a "Preload" option, you've already loaded the prototype once. Understanding that you can load the rest before presenting requires inside knowledge the UI isn't giving you.
The team tested simpler nouns—"Load full prototype," "Load all screens," "Load all assets"—but each undermined trust. When the computer tells you it's loading and then says it's done, you need to believe it's done. Suggesting there's more to load after a completed load breaks that contract.
Goal-oriented language falls short
Another approach was to describe the user's purpose. Phrasing like "Present prototype offline" or "Prepare to present offline" targets a clear desire. But there's a timing problem: clicking "Present…" without presenting delays satisfaction, while "Prepare…" is too vague about what preparation means or when it's needed. Both require a workflow the product didn't have; they felt too imposing for a simple toggle in a menu.
Freedland cites computing pioneer Terry Winograd's 1987 observation that "people act through language." A menu phrase gives a user a point of view—often a command directed at the program, or the completion of "I want to…". The words must bridge a person's intent and the computing action that follows. When a wide gap remains, the interaction falls apart.
Finding an enabling verb
"Make" offered a middle ground—a soft imperative that still carries authority. People make dinner, make sense, and make things right. On a menu, "Make available offline" would instruct Figma now about a future need: presenting without a connection. Yet it could imply a permanent download onto the device, and some team members worried it was ambiguous for users just wanting better prototype performance online. "Available offline" still didn't pin down what happens next.
Part of the answer came from a 1983 study. Lucy Suchman, a grad student in anthropology, placed a new Xerox high-speed copier in a room with cameras at PARC. Her recordings showed two researchers struggling to understand what the machine knew about their actions—and why it behaved unexpectedly. Her conclusion was that a computing machine must make plain what it's doing, and why, not just prompt the next click.
The final design added icon states at the top of a file with fuller explanatory language. It leaned on "downloading" to connect the technical action—moving file assets from the cloud to the browser session, not device storage—to a familiar concept. When everything was ready, a reminder noted that the user could now present offline, with clear guidance on what kept the download alive: keep the tab open, since closing it clears the data.
In the end, the chosen words were unremarkable on their own: make, keep, present, close, clear. But each one had to hold up to scrutiny because an individual verb can shape how a person understands the object of their attention. Freedland argues that a UX writer's work is weighing those words carefully, since they define the point of interaction between a person and a program—and getting them wrong can cause the whole encounter to fail.
