Figma

Design tools used to be programs you installed on your own computer. The working file lived on one person's laptop, and showing it to anyone else meant exporting an image into a chat thread or zipping the file into an email.

Three things went wrong every time. The first was figuring out which version was current. Every meeting opened with someone scrolling back through chat to work out whether mockup_final.png or mockup_final_revised.png came later. The second was values. An engineer would ask whether a margin was 24 or 32, and a designer would open the file, check, and answer — a round trip that happened several times a day. In the years when the tool only ran on macOS, anyone on Windows couldn't open the file at all.

The third was that two people couldn't touch a file at once. One person opened it, edited, saved, and passed it along, so two designers splitting a screen between them created a separate job of merging the files afterward. Moving the file from something each person downloads to a place everyone looks at removed all three at the same time.

What it removes is the class of problems that comes from a file existing in several copies. The work lives in one place on a server and everyone opens that one place, so the question of which version is current, the merge step, and the person who can't open it all disappear together.

1. Sharing is one link. No install, no download, so an engineer, a product manager and the CEO all open the same address. The step of exporting images to show a mockup drops out entirely.
2. Several people edit the same screen at once. Each person's cursor is visible and edits appear immediately, so nothing has to be merged.
3. Engineers read values for themselves. Click an element and the color, spacing and type size are there to copy. This is where the "is that margin 24?" conversation ends. Design handoff, the step of passing a design to engineering, now runs without a separate spec document, and that is the biggest change of the past decade.
4. The features that stop you doing the same job twice live inside it. Auto layout makes boxes and spacing move when the content changes, and an instance is a copy tied to an original, so fixing the original updates every copy. Changing one button color goes from opening 40 screens to editing one master.
5. A prototype, which links screens together to test a reaction before anything is built, and a wireframe, which lays out structure with no styling, both live in the same file. The stages connect without switching tools.

With all of that in place, there's a floor to actually run a design system on — one agreed set of colors, spacing and parts — and each reusable part inside it is a UI component.

There are three alternatives, and the choice usually comes down to a company's circumstances rather than features.

1. Installed tools. Sketch and its relatives still run as macOS applications. Teams that have been around a while have years of files in that format, which makes moving expensive. One person opens and edits at a time, with a web viewer bolted on later for everyone else.
2. Open-source tools you host yourself. Penpot and similar tools install on your own servers. Finance and public-sector teams that cannot put work on an outside service pick these.
3. Using no design tool at all. A team with few screens and no designer blocks out layout in a slide deck and goes straight to code. Below roughly twenty screens that is sometimes the faster path, though the cost shows up later, when nobody can say where the current version of a screen lives.

Three questions decide it: whether the work can sit on an outside server, how many people open the file together, and what format the existing assets are in. For a team starting fresh with no constraint on the first two, there isn't much of a decision to make.

"Send me the Figma link, I'll read the spacing myself."

No round trip — the speaker will get the values they need directly.

"This isn't an instance, so it has to be fixed on every screen separately."

The part was never tied back to a master, so the same edit repeats over and over.

"Did that button change go in? I'm still seeing the old color."

Even inside one file, what you see depends on which screen you have open.

At Pagedeck, Noa editing the checkout screen while Theo has the same file open is an ordinary day. When Noa raises a button from 40 to 44, it appears on Theo's screen at that moment and he changes the value in code alongside her. In the old setup, exporting a revision, sending it, and having Theo measure it again would have taken half a day.

Not every conversation disappeared, though. What Theo asks about most is not a value but a state nobody drew. What the screen looks like when a list is empty, when text runs very long, or when the network drops is often missing from the mockup, and studying the file more closely will never produce it. Those gaps are a question for the designer, not a value to be read off the canvas, which is why the file removed the round trips about numbers and left the ones about decisions.

Plenty of people assume that using the tool gives them a design system. The features for making and reusing parts are right there, so it looks that way. What the tool provides is a place to keep the parts; deciding how many colors are allowed and which part gets used when is an agreement people have to reach. Without that agreement, files accumulate twelve buttons with similar names, and that state is harder to fix than having no shared parts at all.

Reading a mockup as if it were the code is the other common mistake, because what's on screen looks exactly like the finished product. In practice one mockup splits into several states in code. A single button needs a pressed state, a disabled state, and a version where the label overflows, while the mockup usually shows only the default. Planning a schedule without accounting for that scatters engineering time into asking about screens that were never drawn. Pulling the missing states into a list at handoff moves that round trip earlier.