Building a customer journey map in Figma. Why the whiteboard matters more than the template.

The short answer. FigJam is the tool, not Figma itself.

I'm Lauren Pearson, and when a client says they want to "build the journey map in Figma," they almost always mean FigJam, Figma's separate whiteboard product built for exactly this kind of collaborative, work-in-progress mapping. Figma's own design canvas is for interface screens; FigJam is where teams actually run a customer journey map. Figma maintains a free template in its resource library that lays out the standard stages-across-the-top, lanes-down-the-side structure, and it is a reasonable starting frame, provided you treat it as scaffolding to strip, not content to fill in verbatim.

That distinction matters more than it sounds. Our guide to free customer journey mapping tools makes the point that the tool was never the real bottleneck, and that still holds here. Figma does not make a bad map good. What it does genuinely offer, better than a static document or a spreadsheet, is a canvas several people can edit at the same time, in the same room or across time zones, which is the actual reason to pick it over a template built in Excel or a slide deck.

How it works in practice. Set the structure before anyone adds a sticky.

Start with the frame, not the content. Lay stages across the top exactly as your research defines them, not however many the template happened to ship with, and keep the lanes down the side to a short, fixed list: customer goal, actions, touchpoints, emotional state, pain points, and an opportunity column with an owner's name against it. Five or six lanes is usually the ceiling; past that, the board becomes too wide to read in one pass, which defeats the point of a canvas over a document.

Pin a legend to the canvas before the first sticky note goes down if more than one person will be adding to it: which colour means what, what a red stamp means versus an amber one, which section is evidence and which is a hypothesis still to test. FigJam gives every contributor their own colour automatically, which is useful for seeing who added what, but it will not stop five people inventing five different private colour codes for emotion or priority unless you agree one first.

The genuine advantage of building this in FigJam rather than a static document is the live, multiplayer session itself. Run it as a working session with the people who hold the evidence, support, sales, a handful of actual customers if you can get them in the room, rather than building it alone from notes and sending it round for comments afterwards. Our guide to running a journey mapping workshop covers that session in detail; this piece is specifically about the canvas you build it on, not the agenda for the room.

Attach evidence to the board as you go rather than after. FigJam's comment threads and sticky notes both support this: a pain point on the map should link, even informally, to the support ticket, the quote, or the data point that justified putting it there. A journey map built entirely from assumption looks identical to one built on evidence until someone asks where a claim came from, and by then the file has usually already been shared with a client or a leadership team.

Name the file properly and keep it in a findable project from the start: "Customer journey map, onboarding, v2, March 2026" beats "Untitled" or a generic "Journey mapping" title buried in someone's personal drafts within a week. Teams that skip this step end up with three half-finished boards scattered across different people's files, each slightly out of date, because nobody could find the original to keep working on it. Use FigJam's version history to mark the point a map was last reviewed with stakeholders, rather than relying on memory for which version is current.

Not everyone who needs to see the map has, or wants, a Figma seat, and that is fine. Share a view-only link for stakeholders outside the working session rather than asking them to create an account, and flatten the finished board to an image for a slide deck or a client pack once it has stabilised. Keep the live FigJam file as the working version that actually gets updated, and treat any exported copy as a snapshot dated the day it was taken, not the current source of truth; a PDF pasted into a deck six months ago is the single most common reason a team argues from an outdated version of its own map.

What good looks like. A map someone outside the room can still read.

The test of a good Figma journey map is not whether it looks finished. It is whether someone who was not in the room can read across a single stage, in order, and understand what the customer is doing, feeling, and running into, without asking you to talk them through it. That means consistent lane order across every stage, short sticky notes rather than paragraphs (if a note needs three sentences, it belongs in a linked document, not on the board), and emotional state shown as a simple line or face icon rather than another block of text. A dip in that line does more to get a stakeholder's attention in a review than a sticky note saying "customer is frustrated here" ever will.

Our worked B2B customer journey map example shows this structure applied to a committee sale; the lane structure holds regardless of whether you are mapping one customer or a buying group, because the discipline is the same: fewer lanes, consistent order, evidence attached, and a line for emotion that a glance can read.

Resist the temptation to make the board look finished before it is accurate. A visually polished FigJam map with rounded frames, a consistent colour palette and neatly aligned stickies can hide the fact that half the content is still a guess, and a tidy board tends to get challenged less in review than a messy one, which is exactly the wrong outcome. Leave the hypothesis stickies visibly rough, grey and unstyled is fine, until the evidence to support them actually exists, so a reviewer can tell at a glance what is proven and what still needs testing. Polish the board's formatting only once the content behind it has actually been checked, not before, whatever deadline is pushing the other way.

A worked scenario. Where five colour codes nearly derailed a map.

A hospitality technology team's FigJam session I sat in on opened a board to five contributors at once with no legend agreed first. Each one had their own idea of what a yellow sticky meant: one used it for "needs more research," another for "customer quote," a third for "disagree with this." By the second working session, the board had become unreadable, not because the mapping was bad, but because nobody could tell the difference between an evidence-backed pain point and someone's unverified hunch. We stopped, agreed a four-colour legend on a single frame pinned to the top-left of the board (pink for a customer quote, amber for a pain point, grey for a hypothesis to test, green for an agreed action), and re-tagged everything in under fifteen minutes. The map was usable again by the end of that session.

This is an illustrative pattern I've seen across several teams' first FigJam sessions, not one named client, but the fifteen-minute fix works regardless of which team or industry is doing the mapping. The decision rule that came out of it: pin the legend before the first sticky goes down, not after the board already needs cleaning up.

Pitfalls to avoid. Where Figma journey maps go wrong.

Filling the template literally rather than stripping it is the most common failure. Stage names, lane labels and even sample sticky notes that nobody edited stay in the final board, because nobody wanted to be the one to delete someone else's placeholder text.

Building it solo is the second. The whole point of FigJam is the live, multiplayer session; a map built alone from notes and shared afterwards for comments gets comments, not the argument-it-out-loud that actually improves a map.

Letting the board sprawl is the third. Boards that keep growing sideways because "we'll just add another stage" lose the one-pass readability that makes a whiteboard better than a document in the first place.

Treating it as a one-off build is the fourth. A map built once for a launch and never opened again goes stale within two quarters. Name an owner who revisits it, the same person named in the opportunity column, not a shared folder nobody checks.

And picking Figma because it is fashionable rather than because the team already uses it is the one that costs the most time. If nobody on the team has ever opened Figma, the learning curve costs more than the multiplayer canvas saves, and a shared document or our Excel template will get finished faster.