Design Tool

Before software existed specifically for screens, designers drew app interfaces in programs built for print and photo retouching. Those programs were made to produce one finished piece at a time, and a product screen is never one piece. Draw a signup screen and you immediately owe four more: the empty state, the state while someone is typing, the state after a wrong password, and the state after the account is created. All four are connected, and changing one usually changes the others.

As the screen count grew, the same work kept coming back around. Deciding to change one button color meant opening every file that contained that button and editing it by hand. Files lived on individual laptops, and the only way to share one was to send it over chat. Folders filled with a final file sitting beside a revision and a real final, and an engineer had to ask which one was current before starting anything.

Reading a value out of a mockup also went through a person. At Pagedeck, Theo would ask how much space sat above a button. Noa would open the file, measure it, and answer 24. That exchange happened ten times a day, and whenever one of them was in a meeting, that screen stopped there. Theo, tired of waiting, would eyeball 20, and the build shipped four pixels off the mockup — small enough that nobody caught it, repeated often enough that the product slowly stopped matching its own design.

Three separate problems sit underneath those scenes. The first is repetition: one decision turns into dozens of edits because the same part is scattered across files. The second is finding the current version: when every person holds a copy, confirming which one counts requires asking someone. The third is moving values: a number gets read by eye, spoken aloud, and typed somewhere else, and each of those steps can lose it. None of the three is a question of designing better. They are all questions of moving a decision without shaving pieces off it on the way.

Design tools go after all three at once. Many screens sit side by side in a single file. A part is built once and shared by every screen that needs it. Engineers read numbers directly out of the file instead of asking. In the larger design map, this branch belongs to how a team works rather than to what a team designs. It does not decide whether a screen is good. It decides whether the screen that was agreed on is the screen that gets built.

Two branches sit under this term. One holds the names of programs a team actually opens. The other holds the names of features inside those programs that keep the same work from being done twice. Knowing only the first tells you which window is on someone's second monitor. Knowing the second tells you what is happening inside it.

Before the branches, it helps to split what a design tool does across a working day into four slots.

1. Drawing. Setting the layout, color, and type of a single screen.
2. Grouping. Turning anything that repeats across screens into a part managed in one place.
3. Connecting. Linking screens in the order someone would tap through them so the flow can be tried out.
4. Handing off. Exposing colors, spacing, and type sizes in a form engineering can read.

The tool branch is the container all four happen inside. The feature branch is what makes slot two possible. Slots one and three are things nearly every tool does, so no separate term grew up around them, and slot four has its own name on the receiving side.

The tool branch holds two entries, and they hold different things.

1. Figma — a design tool that opens in a browser and lets several people edit the same file at once. Sharing a link instead of installing software and mailing files is the break with the previous generation of tools. A designer can be editing a screen while an engineer has the same file open reading colors and spacing, which quietly removes the "how much space above this button" exchange from earlier. Because the file exists in exactly one place, the question of which copy is current disappears with it.
2. Storybook — a tool that displays one interface part on its own rather than a finished screen. An engineer renders a coded button with no page around it and checks the pressed state, the disabled state, and the state where the label runs very long, all in one view. It holds what was built rather than what was drawn, so it gets used where the two are compared. A button that turns out to have six states while the mockup covered two is the kind of gap that surfaces here.

The feature branch holds the devices that remove repetition inside the container. There are two, and one handles size while the other handles the relationship between an original and its copies.

1. Auto layout — a layout feature that makes boxes and spacing move when the content inside them changes. Change a button label from "Save" to "Save changes" and the box stretches to fit, and the cancel button beside it shifts by the same amount. Without it, every text change means manually repositioning the box and its neighbors, and across ten places one or two will stay wrong. Switching a Korean mockup to English makes the difference obvious: when the text doubles in length, a file with this feature adjusts itself, and a file without it needs twenty screens redrawn.
2. Instance — a copy that stays connected to the original part it came from. Edit the original and every connected copy changes with it. Build one button and place it as an instance on forty screens, and a color change drops from opening forty files to editing one. An instance and a pasted duplicate look identical on the canvas; the difference shows up three months later, when thirty-nine of them follow the new color and the one that was pasted stays the old one.

The two branches are one chain rather than two separate topics. Without the features, a tool drifts toward being a drawing program. Without the tool, the features have nowhere to live. When the chain runs properly, the colors, spacing, and parts used across a product settle into a single set. That settled set is what a design system is, and each reusable part inside it is a UI component. Tools and features are the floor that keeps the system moving; a written standard with no parts built inside the tool ends up as a rulebook nobody opens.

The exit side is worth knowing too. What comes out of the tool moves into implementation through design handoff, the step where design is passed to engineering. That step used to mean exporting screen images and writing a separate document listing every measurement. Now the engineer opens the design file and reads the values directly, and slot four needing far less human effort is the biggest change of the past decade. A prototype — screens wired together temporarily to see how people react before anything is built — is made in the same tool, and a wireframe, which shows structure with the styling stripped out, starts in the same file. This is where the tool branch touches the rest of the design map.

"The mockup lives in the tool, so I'll send you a link instead of a file."

A way of saying the other person should always be looking at the current state. A sent file freezes at the moment it was sent, and screens built from it follow a decision that has already moved on.

"The spacing on this card is different on every screen — I think it was pasted rather than used as an instance."

The parts look the same but the copy lost its connection to the original, so only one of them got fixed. Implied in the sentence: patching the spacing by hand now means the same gap reappears at the next edit.

"The box breaks when the text gets long. Can you rebuild it with auto layout?"

A request to change how the element is laid out so its size follows its content. The point is to stop a design that looks right in the mockup and falls apart the moment real data goes in.

At Pagedeck these sentences come up in the screen review. Noa puts the mockup link on screen, Theo opens the same file and sets the built version beside it, and they walk through the differences. When something is off, the cause is one of two things: the mockup was using a copy that had lost its connection to the original, or the build was made from memory rather than from the file. In the first case Noa converts it to an instance on the spot. In the second, Theo reads the values again. Either way it ends inside the meeting, with no document changing hands afterward.

Mia does not bring numbers to this meeting. She works from the list of screens and checks how far the mockups have been settled. On a team whose tooling is working, that check takes five minutes. On a team whose tooling is not, five minutes go into finding out which file is current. Tool conversations look like a matter of taste among designers, but they show up on the schedule first.

The most common mistake is treating fluency with the tool as design skill. It is an easy assumption, because early on almost all visible progress does come from the tool. Learn the shortcuts and a screen that took two hours yesterday takes thirty minutes today, so the sense of improvement is real and immediate. But what the tool answers is how to draw something. What to draw and why it is drawn that way sit outside it. Miss that distinction for a few years and the mockups come out fast and tidy while the question "why is it laid out this way" has no answer behind it. The gap becomes visible the moment someone has to present their work and explain the decisions, and by then a few years of habit are already set.

The second mistake is assuming that turning on the part-and-copy features produces a design system by itself. The setup looks like a system already, so the assumption is reasonable. What the features actually supply is the connection that lets many copies be fixed at once. The agreement about which part to use in which situation has to be made by people, separately. Without that agreement, originals multiply instead of consolidating. Seventeen near-identical button originals accumulate, a new hire has no one to ask which is correct, and makes an eighteenth. A year in, cleaning it up is its own project that eats two or three weeks, and the cleanup has to happen while the product keeps shipping, so it rarely gets a clear slot on the schedule. The tool gave the team the ability to change many things at once; deciding what should exist in the first place was never part of what it offered.