When to use FigJam instead of a design file

Quick answer

FigJam is the whiteboard. A design file is the UI. Run the workshop, the map, and the sticky critique in FigJam. Build screens, components, variables, and the prototype in a design file. When a sticky becomes a screen, copy the decision into the design file and leave the board as the record of how you got there. FigJam is not the library engineering will inspect.

Who this is for

• Designers about to drop a critique into the same file as the production screens.
• Leads who want a workshop without forking the design system.
• Anyone who has been asked to “just prototype it in the FigJam.”

If the work is already a framed screen with components, you are past the whiteboard.

What belongs where

Put it in FigJam	Put it in a design file
Agenda, stickies, votes, a flow sketched in boxes	Frames, components, variants, variables
A workshop that will be messy for an hour	The screens you will hand off
A diagram of a journey or an ERD-style sketch	The prototype and the Dev Mode page
Notes from a critique that are not yet a UI change	The file version history should track

The May 2026 digest notes FigJam tables, templates, and generated diagrams as planning tools, and says they are not a substitute for a UI library. Read that note in the mid-quarter digest if you are checking what changed. The split above does not depend on those extras.

What not to do

• Do not design the product UI as a pile of stickies and then ask engineering to inspect the board.
• Do not run the workshop inside the delivery file. People will autosave over the screens, and version history becomes a pile of unlabeled workshop states.
• Do not publish a library from a FigJam. Libraries are design files. The publish steps are in team libraries.

When the workshop is over

1. Write the decision in one sentence on the board. “Checkout keeps a single address step.”
2. Open the design file. Put that sentence on the cover or the section that will hold the screens. Sections are how a design file stays reviewable: organize pages and flows.
3. Build only the screens the decision requires. Leave the rejected stickies on the board.
4. Name a version in the design file once those screens match the decision.
5. Link the FigJam from the design file’s cover, and link the design file from the board, so nobody treats the board as the latest UI.

Slide decks are a third thing. A presentation can live in Figma too, and it is still not the product file. See slide decks if the output is a deck rather than a product screen.

Sharing

A FigJam link and a design-file link are both share links. The same care applies: view access for a workshop guest, edit access for the people running it. Password and link habits are in share links. Do not put customer data on stickies you are about to share with a whole channel.

Common mistakes

• Recreating the whiteboard as a page of unlocked frames in the design file “so it’s all in one place.”
• Letting the board become the spec because it was faster. The spec is the design file with named frames.
• Updating the board after engineering has started, and never updating the file.

FAQ

Can a small team skip FigJam?

Yes. A scratch page at the back of the design file is enough for one person. The moment a second person is sticking notes on the delivery frames, move the workshop out.

Should the design system live in FigJam?

No. Document decisions there if you want. The components live in a library file.

What about Figma Make?

Make is for a generated prototype, not for the workshop notes and not for the production component file. The digest’s line still holds: pair it with a design file when the work has to be built.

Next

Once the decision is in a design file, the next job is making that file safe to open in Dev Mode. Continue with what to finish before Dev Mode. The setup path is on Learn.