Creating FigJam Diagrams
To create a diagram in FigJam:
- Open FigJam and choose a template (or start blank) matching your use case
- Drag shapes onto the canvas — they auto-snap to a grid
- Use connectors to link shapes — they snap to shape edges automatically
- Label each shape/connector clearly
- Invite teammates to collaborate live, or import Figma designs/components for realism
Progress:
- Step 1: Identify the diagram type needed
- Step 2: Select a starting template or blank canvas
- Step 3: Map out the structure with shapes and connectors
- Step 4: Add detail (colors, screens, code blocks, real content)
- Step 5: Invite collaborators for real-time review
- Step 6: Refine based on feedback
Step 1: Identify the diagram type Match the goal to a diagram type:
- Customer journey map — visualize user experience across touchpoints
- Organization chart — show reporting structure/hierarchy
- Swimlane diagram — show cross-functional process steps by role/team
- Flow chart — show decision logic or process steps
- Entity relationship diagram — show data/system relationships
Step 2: Choose a template Start from a ready-made template rather than blank canvas when possible — it enforces standard conventions (e.g., diamonds for decisions, lanes for roles) and saves setup time.
Step 3: Map the structure
- Use grid-snapping shapes and connectors to keep alignment clean
- Keep one idea per shape; avoid overloading a single box with multiple steps
- Use consistent shape semantics (e.g., rectangles = steps, diamonds = decisions, circles = start/end)
Step 4: Add detail
- Use the color picker to encode meaning (status, category, team ownership)
- Pull in actual screens, components, or code blocks from Figma libraries so the diagram reflects real product context, not just abstractions
- Use custom/community shapes when default shapes don't convey the right meaning
Step 5: Collaborate
- Work through messy, early-stage exploration directly in the file with stakeholders in real time rather than iterating over static exports
- Use comments/cursors to gather feedback live during workshops or retros
Step 6: Refine
- Simplify: if a diagram needs a legend to be understood, consider whether it's overloaded
- Re-check that flow direction is consistent (top-to-bottom or left-to-right) throughout
Example 1: Input: Need to show a multi-step signup flow with a decision point (email vs. SSO login) for a stakeholder review. Output: A flow chart template with: Start (circle) → "Choose login method" (diamond) → two branches ("Email signup" and "SSO signup" rectangles) → "Verify account" → End (circle), each branch color-coded by auth type, with actual login screen mockups embedded from Figma libraries next to relevant steps.
Example 2: Input: Need to document which team owns which step in an order fulfillment process. Output: A swimlane diagram with horizontal lanes labeled "Sales," "Warehouse," "Shipping," "Support" — each step placed in the lane of the owning team, connected by arrows showing handoffs between lanes.
- Start from a template for common diagram types instead of building structure from scratch
- Keep shape semantics consistent throughout a single diagram
- Embed real product screens/components rather than placeholder boxes when showing user flows — it builds stakeholder confidence
- Use diagramming collaboratively and live for early, messy exploration phases rather than perfecting alone first
- Use color intentionally (status, ownership, category) not decoratively
- Don't mix diagram conventions (e.g., using rectangles for both steps and decisions) — it confuses readers
- Don't cram an entire complex process into one diagram — split into linked sub-diagrams if it gets dense
- Don't skip labels on connectors when the relationship/condition isn't obvious (e.g., "Yes"/"No" on decision branches)
- Don't use static slides for iterative process mapping when a live collaborative canvas would let the team refine together in real time