A Figma workflow is the structured, repeatable sequence of stages a design team follows to move work from initial concept to production-ready code, using Figma’s end-to-end platform across three core environments: FigJam for ideation and whiteboarding, Figma Design for high-fidelity UI work, and Dev Mode for developer handoff. Understanding the Figma design process in full means knowing not just which tool to open, but when to open it, who owns each stage, and what a completed stage actually looks like.

A well-governed workflow produces four concrete outcomes:

Single source of truth — all design decisions live in one cloud environment, eliminating version conflicts between local files.
Fewer handoff surprises — developers access live files with annotations, measurements and exportable assets rather than static screenshots.
Faster engineering delivery — Dev Mode surfaces code snippets, design tokens and component specs directly, reducing clarification cycles.
Stable collaboration — granular permissions and branching keep work progressing without overwriting each other’s contributions.

Key takeaways

A Figma workflow covers six stages from FigJam ideation through to Dev Mode handoff, with governance and file structure determining whether those stages remain reliable as teams grow.

Point	Details
End-to-end tool mapping	FigJam handles ideation, Figma Design covers wireframes and high-fidelity screens, Dev Mode manages handoff.
File structure first	Agree naming conventions and project hierarchy before publishing any library components to avoid broken references.
Invite developers early	Give engineers view access from the wireframe stage to prevent costly design-to-code conflicts at handoff.
Component documentation is mandatory	Every main component needs a written description covering states, responsive behaviour and edge cases before Dev Mode handoff.
MedwayWebDesign workflow setup	MedwayWebDesign delivers library creation, file structure, Dev Mode configuration and team onboarding in two to three weeks.

What does a Figma workflow look like end to end?
Detailed stages: what happens and what to do at each step
How should you organise Figma files and libraries?
How do you collaborate effectively and run critiques in Figma?
How does developer handoff work in Figma’s Dev Mode?
DesignOps practices that help workflows scale
MedwayWebDesign starter template for teams new to Figma
A repeatable checklist for running a Figma workflow well
What MedwayWebDesign sees go wrong in client Figma projects
How MedwayWebDesign can set up your Figma workflow
Editorial perspective: what teams consistently underestimate about Figma workflows
Sources

What does a Figma workflow look like end to end?

The Figma design process runs through six sequential stages, each with a defined purpose, a lead role, and a primary tool.

Ideation — The team maps problems, user journeys and early concepts in FigJam using sticky notes, voting widgets and diagrams. Lead role: product manager and UX researcher.
Wireframing — Low-fidelity frames establish layout logic and content hierarchy in Figma Design, without colour or final typography. Lead role: UX designer.
High-fidelity design — Components, tokens and brand styles are applied to produce production-representative screens. Lead role: UI designer, drawing on published design system libraries.
Prototyping — Interaction flows are built using Figma’s prototype editor, connecting top-level frames to model navigation paths before any code is written.
Developer handoff — Files are marked ready in Dev Mode, where engineers inspect measurements, copy code snippets and download assets.
Maintain and iterate — Published libraries are updated, version history is preserved, and branched files manage ongoing changes without disrupting the production baseline.

DesignOps governance typically intervenes at two points: between wireframing and high-fidelity design (to confirm components are sourced from the shared library rather than drawn ad hoc) and between handoff and maintenance (to audit whether Dev Mode annotations remain current after design revisions).

Detailed stages: what happens and what to do at each step

Ideation and discovery

The designer and product manager open a FigJam board and run a structured session: user journey mapping, competitive reference gathering, and a dot-vote to prioritise directions. Figma’s DesignOps guidance recommends prototyping internal workflows in FigJam before committing to full builds, which applies equally to product concepts. The output is a shared board with agreed problem framing and a rough direction the team has explicitly signed off.

For UI design inspiration at this stage, teams typically pull reference screenshots directly into FigJam alongside their journey maps, keeping context and stimulus in the same file.

Wireframing

The UX designer creates low-fidelity frames in Figma Design using placeholder components and auto-layout. Pages within the file should be named clearly: 00_Wireframes, 01_Flows, 02_Reference. Figma’s file structure guidance recommends using pages to separate explorations, designs and component libraries, which prevents wireframe clutter from contaminating the production canvas.

Developers should receive view-only access at this stage. Inviting engineers early creates ambient awareness of design direction and avoids the large-scale surprises that typically surface at handoff.

High-fidelity design

The UI designer applies the published component library, spacing tokens and colour styles to produce screens that represent the final product. Every component placed on the canvas should come from the shared library rather than being drawn locally. This is the stage where the distinction between UX and UI responsibilities becomes operationally significant: the UX designer owns layout logic and user flow, while the UI designer owns visual execution within the established system.

Prototyping

Prototype flows in Figma rely on top-level frames as starting points, with explicit connections between frames to model interaction paths. Figma’s prototype flow system supports multiple named flows within a single file, which is useful for testing distinct user journeys without duplicating screens. The prototype should be shared with stakeholders and, where possible, tested with real users before handoff begins. Unvalidated prototypes passed directly to engineering are one of the most common sources of mid-sprint rework.

For teams building interaction-heavy interfaces, Figma’s smart animate and variable features can model state changes and conditional logic without requiring a coded prototype.

Developer handoff and maintenance

Once screens are approved, the designer marks the file ready in Dev Mode and writes component descriptions covering states, responsive behaviour and edge cases. Engineers then inspect the file directly rather than relying on exported PDFs. Version history and branching handle ongoing revisions, with branches merged back to the main file after review.

Stage	Purpose	Primary Figma tool	Typical deliverable
Ideation	Problem framing and direction	FigJam	Shared board with agreed direction
Wireframing	Layout and content hierarchy	Figma Design	Low-fidelity frames, named pages
High-fidelity design	Production-representative screens	Figma Design + Libraries	Component-driven screens with tokens
Prototyping	Interaction path modelling	Figma Prototype editor	Named flows with starting points
Developer handoff	Engineering implementation	Dev Mode	Annotated specs, assets, code snippets
Maintain and iterate	Ongoing accuracy	Figma Design + Branching	Updated library, version history

How should you organise Figma files and libraries?

File sprawl is the single most common reason Figma workflows break down at scale. A clear project hierarchy, enforced from day one, prevents teams from hunting across dozens of unnamed files for the current production version.

Recommended project and file hierarchy

Organise work at three levels within a Figma team space:

Projects map to products or clients (e.g. ClientName — Product).
Production files hold approved, library-published components and final screens.
WIP files hold active explorations, named with the designer’s initials and a date stamp (e.g. JD_2026-07_Checkout-Exploration).
Archive files are moved to an _Archive project once a sprint or phase closes.

Naming conventions

Consistency in naming is what makes files searchable and handoff predictable. A practical convention:

Files: [Project]_[Feature]_[Status] — e.g. Acme_Checkout_PROD or Acme_Checkout_WIP.
Pages within a file: prefix with a two-digit number to enforce order (00_Cover, 01_Wireframes, 02_Designs, 03_Prototype, 04_Handoff-Notes).
Components: [Category]/[ComponentName]/[Variant] — e.g. Button/Primary/Default.

DesignOps guidance recommends standardising file organisation and contribution guidelines so workflows remain scalable as teams grow. Without a naming convention enforced in contribution guidelines, individual designers default to personal habits, and the shared library becomes inconsistent within weeks.

Publishing and versioning libraries

Publish a library only when components have been reviewed and approved. Use Figma’s built-in version history to tag releases with a label (e.g. v1.2 — Added dark mode tokens) before publishing. Teams should designate one person, typically a senior designer or design lead, as the library owner responsible for approving contributions and publishing updates. Ad hoc publishing by multiple team members without review is a reliable path to broken component references across production files.

Folder or page	Purpose
`00_Cover`	File metadata: owner, last updated, status
`01_Wireframes`	Low-fidelity layout explorations
`02_Designs`	High-fidelity, component-driven screens
`03_Prototype`	Named flows with starting points
`04_Handoff-Notes`	Dev Mode annotations, edge cases, tokens
`_Components` page	Local component overrides not yet in the shared library
`_Archive` project	Closed sprints and superseded files

How do you collaborate effectively and run critiques in Figma?

Effective collaboration in Figma depends on two things working together: a permissions structure that gives people the right level of access at the right time, and a critique practice that produces useful feedback rather than open-ended opinion.

Permissions and invite strategy

Figma’s permission model has three relevant levels for most teams:

Edit access — designers and design leads working on active files.
View access — developers, product managers and stakeholders who need visibility without the risk of accidental edits.
Dev access — engineers using Dev Mode to inspect specs and export assets; this is distinct from standard view access and unlocks code snippet generation.

Invite developers with view access from the wireframe stage onwards. This creates the ambient awareness that prevents large-scale surprises at handoff, a principle supported by product manager–designer–developer collaboration research. Stakeholders should receive view access to a dedicated presentation page rather than the working canvas, to avoid confusion between explorations and approved designs.

Critique formats and when to use each

Figma’s product design team uses different critique formats depending on the stage of work, matching the method to what the work actually needs at that moment.

Silent critique — participants write sticky-note feedback independently before discussion; best for early wireframes where verbal anchoring biases responses.
Pair critique — one designer presents to one reviewer; efficient for quick directional checks mid-sprint.
Standard critique — structured group session with a facilitator, a presenter and a fixed agenda; appropriate for high-fidelity screens before handoff.
FigJam jam session — open collaborative exploration on a whiteboard; suited to ideation and problem-framing, not polished design review.

Figma’s critique guidance documents six critique methods and recommends limiting topics per session and timing each topic with a fixed timer to prevent overruns. A practical cadence for most product teams: a 30-minute pair critique mid-sprint and a 60-minute standard critique before each handoff, with FigJam jams reserved for discovery phases.

The concept of critique “altitude” is worth applying deliberately. Use FigJam for informal, early-stage feedback where the work is still directional; switch to Figma Design for structured review of polished screens where precision matters. Mixing the two contexts produces confused feedback, with stakeholders commenting on pixel-level details on a wireframe or waving through structural problems on a near-final screen.

How does developer handoff work in Figma’s Dev Mode?

Dev Mode is a purpose-built workspace within Figma designed to make developer handoff faster and more precise. When a designer marks a file ready for development, engineers switch to Dev Mode and gain access to measurements, spacing values, typography styles, colour tokens and exportable assets, all without needing to ask the designer for a specification document.

Setting up Dev Mode effectively

The quality of a Dev Mode handoff depends entirely on how well the designer has prepared the file. Three areas require deliberate attention:

Component descriptions — every main component should carry a written description covering its purpose, its variants, its interactive states and any responsive behaviour. A component without a description will be treated by developers as a static image, which defeats the purpose of a component-based system.

Asset export settings — configure export settings directly on frames and components rather than leaving engineers to guess at the correct format. SVG is appropriate for icons and illustrations; PNG at 1x, 2x and 3x for raster assets; WebP where file size is a priority. Name exported assets using a consistent convention: icon-arrow-right.svg, not Vector 42.

Design tokens — colour, spacing and typography tokens should be published through the shared library so that Dev Mode surfaces token names rather than raw hex values. This is the connection between design and code that makes a design system operationally useful rather than decorative.

A handoff-ready checklist for a component should confirm: all states are designed (default, hover, focus, disabled, error); responsive behaviour is documented in the description or via a separate annotation frame; edge cases (empty states, long text, RTL) are covered; and all assets have export settings applied.

For teams managing document-heavy review processes alongside design work, contextual annotation and redlining workflows follow similar principles: explicit markup, named versions and a clear handoff state that signals the document is ready for the next party.

DesignOps practices that help workflows scale

DesignOps is the operational layer that makes a Figma workflow repeatable as teams grow. Without it, good practices exist in individual designers’ habits rather than in shared systems, and they disappear when those designers move on.

Core governance elements

The three governance elements that have the most impact on workflow quality are contribution guidelines, review cadences and tooling audits.

Contribution guidelines define who can add components to the shared library, what the review process looks like, and what documentation a component must carry before it is published. Without these, the library accumulates untested components and duplicate variants.

Review cadences schedule the recurring rituals that keep work moving: weekly library reviews, fortnightly critique sessions and quarterly audits of file organisation. DesignOps in practice recommends building habits and systems that survive team growth by starting small, documenting what works and iterating.

Tooling audits review which plugins, integrations and third-party tools the team is using, and whether they are still serving the workflow. Common integrations worth auditing include Slack (for Figma comment notifications), Jira (for linking design files to tickets), and Zeplin (for teams that use it alongside Dev Mode for legacy handoff documentation).

Onboarding new team members

A starter kit for a new designer joining a Figma-based team should include:

Access to the team space and the shared library file.
A read-only copy of the contribution guidelines document.
A walkthrough of the file naming convention and page structure.
A list of the recurring critique and review sessions with calendar invites.
A short recorded walkthrough of Dev Mode for any developers joining the team.

Measuring design impact

Metrics worth tracking to demonstrate workflow effectiveness include: time from design approval to engineering ticket creation; number of design-related clarification requests raised during a sprint; frequency of library component updates that break existing screens; and the ratio of components sourced from the shared library versus drawn locally.

Audits should run quarterly for active teams and at the start of each new product phase. The audit scope covers file organisation compliance, library health, Dev Mode annotation coverage and integration status.

MedwayWebDesign starter template for teams new to Figma

The following configuration is what MedwayWebDesign recommends for a team setting up a Figma workflow from scratch. It is designed to be operational within a single working day.

File and project structure

Create one Figma team project per client or product. Within that project, create three files:

[Project]_PROD — the production file, containing only approved, library-published components and final screens.
[Project]_WIP — the active working file, where explorations happen before they are promoted to PROD.
[Project]_Library — the shared component and style library, published to the team.

Each file uses the standard page structure: 00_Cover, 01_Wireframes, 02_Designs, 03_Prototype, 04_Handoff-Notes.

Review cadence and role ownership

Weekly: 30-minute pair critique between the lead designer and product manager. Owner: lead designer.
Fortnightly: 60-minute standard critique with the full team, including a developer representative. Owner: design lead.
Monthly: Library review and contribution sign-off. Owner: library owner (senior designer).
Quarterly: Full workflow audit covering file organisation, Dev Mode coverage and integration health. Owner: DesignOps lead or equivalent.

Week 1 versus month 1 priorities

In week 1, focus on three things: publish the shared library with at least the core colour and typography tokens, set up the file naming convention across all active projects, and invite developers with view access to the production file. Everything else can be iterated.

By month 1, the contribution guidelines should be written and shared, the critique cadence should be running, and at least one full handoff cycle should have been completed through Dev Mode to identify gaps in component documentation.

Pro Tip: The single biggest early mistake is publishing a library before the naming convention is agreed. Once components are in use across multiple files with inconsistent names, renaming them breaks every instance. Agree the naming convention first, even if it takes an extra day.

A repeatable checklist for running a Figma workflow well

Use this checklist at the start of each project or sprint to confirm the workflow is properly configured before work begins.

Start of project

Shared library published and accessible to all team members.
File naming convention applied to all new files.
Developers invited with view or Dev access to the production file.
FigJam ideation board created and linked from the production file cover page.
Critique cadence scheduled in team calendars.

Mid-project

Active work in WIP file, not directly in PROD.
Branching enabled for any changes to approved screens.
Accessibility spot-check completed: colour contrast, touch target sizes, focus order documented.
At least one mid-sprint pair critique completed.
Prototype flows named and starting points confirmed.

Handoff

All components sourced from the shared library.
Dev Mode annotations complete: states, responsive behaviour, edge cases.
Export settings applied to all assets with consistent naming.
Design tokens surfaced in Dev Mode rather than raw hex values.
Handoff page (04_Handoff-Notes) updated with any decisions not visible in the design itself.

Pro Tip: Run the handoff checklist with a developer present, not after the fact. Engineers will immediately identify gaps in component documentation that a designer reviewing alone will miss.

What MedwayWebDesign sees go wrong in client Figma projects

Three problems appear repeatedly in client projects, and each one has a concrete fix.

File sprawl is the most common. Teams start with good intentions but accumulate dozens of unnamed files within a few weeks, with no clear distinction between explorations and production work. The fix is not a tidy-up exercise; it is a naming convention and a project hierarchy enforced from day one, combined with a quarterly archive ritual that moves closed work out of the active project space. File sprawl directly extends delivery timelines because designers spend significant time locating the current version before they can begin work.

Missing component documentation is the second. Developers receive a file in Dev Mode and find components with no descriptions, no state coverage and no responsive notes. The result is a clarification cycle that can add days to an engineering sprint. The fix is to treat component documentation as part of the design deliverable, not an optional extra. A component is not complete until its description, states and edge cases are written.

Late developer involvement is the third, and arguably the most expensive. When developers are not invited to files until handoff, they encounter design decisions that conflict with technical constraints, and the team faces either a design revision or a compromised implementation. Inviting engineers with view access from the wireframe stage costs nothing and prevents the majority of these conflicts.

All three issues affect delivery timelines and increase project cost. Teams that address them before a project starts rather than after the first handoff cycle typically complete engineering implementation with fewer revision rounds.

How MedwayWebDesign can set up your Figma workflow

A well-structured Figma workflow is the difference between a design process that scales and one that creates friction at every handoff. MedwayWebDesign delivers end-to-end workflow setup for design and development teams: shared library creation and publication, file hierarchy configuration, Dev Mode preparation, contribution guidelines, and a structured onboarding session for both designers and developers.

A typical starter engagement covers the full setup in two to three weeks, delivering a production-ready library, a documented file structure, a configured Dev Mode handoff template, and a trained team that can run the workflow independently. For businesses building or rebuilding their digital presence, this foundation directly supports faster, more consistent web design delivery and reduces the cost of design revisions during development.

To discuss your team’s current workflow and where the gaps are, contact MedwayWebDesign directly through the business web design service page for a no-obligation consultation.

Editorial perspective: what teams consistently underestimate about Figma workflows

The most persistent misconception about Figma workflows is that the tool does the work. Teams adopt Figma, discover its real-time collaboration and component system, and assume that good workflow behaviour will follow naturally. It rarely does.

The evidence from client projects points to a consistent pattern: the technical capability of Figma is not the constraint. The constraint is the absence of explicit agreements about how the tool is used. A shared library that nobody maintains becomes a liability. Dev Mode that nobody has documented becomes a static screenshot viewer. A FigJam board that nobody archives becomes noise. The platform is only as useful as the governance layer built around it.

The critique altitude principle is a useful illustration. Figma’s own product design team distinguishes between early-stage feedback, which belongs in FigJam where the work is directional, and late-stage review, which belongs in Figma Design where precision is expected. Most teams collapse this distinction and run all feedback in the same environment regardless of the work’s maturity. The result is pixel-level comments on wireframes and structural approval of near-final screens, both of which produce the wrong kind of rework at the wrong time.

The practical implication is that a Figma workflow audit should begin not with the files but with the agreements: what is the naming convention, who owns the library, when do developers get access, and what does a completed handoff actually look like? Teams that can answer those questions clearly tend to have functional workflows. Teams that cannot, regardless of how sophisticated their component system appears, tend to have the same three problems surfacing sprint after sprint.

Sources

The sources below were used to build this guide and are worth reading directly for greater depth on specific topics.

Figma workflow explained for designers and developers