Figma Flow

Developers & Designers speaking in one language

01. What is Figma Flow?

Figma Flow is a collaboration model for Figma, created by Flow Platform Team. Heavily inspired by BDD and state machines, well suited to collaboration and scaling the product development process. It takes best practices from software development to the designers and product management world.

02. Key Benefits

Guided process

Figma Flow is the way of working with your whole product team on your product designs. It is defining a process where you are solving a single problem (scenario) at a time. Using it, your whole team knows what to do when.

Common naming convention and project structure

Most of the graphic design tools are giving you a lot of flexibility regarding names and project structure. Therefore it is essential to agree across the whole team/company standards. Keeping standards in your projects will save a lot of time later.

Version Control

Most of the projects are iterating fast, trying to apply all the findings and results of the experiments. That means you have to adapt your designs quickly. Sometimes developers are implementing the current version, but designers are working on the next one already. That means you have to keep many versions of the design.

03. Basic concepts

Structure of a project

At the beginning the project contains two files in it:

  • File:UIProject Name
    • Page:WIPProject Namecontexts
    • Page:Version NumberProject Namecontexts
    • Page:WIPProject Namecomponents
    • Page:Version NumberProject Namecomponents
  • File:Version NumberProject NameScenarios (ready to develop)
    • Page:Scenario Description
    • Page:Scenario Description
    • Page:Scenario Description
  • File:WIP Project Name Scenarios (as work in progress scenarios)
    • Page:Scenario Description
    • Page:Scenario Description
    • Page:Scenario Description

Example:

View example UI file

Scenarios

Scenarios describe interactions between user roles and the system. They are written in plain language with minimal technical details so that all stakeholders (customers, developers, testers, designers, marketing managers, etc) can have a common base for use in discussions, development and testing.

Scenarios should be phrased declaratively. Don’t make references to UI elements, screens, etc. Try to make it meaningful. Point out the role of a user in a scenario.

Key takeaways:

  • you should start by defining the main scenarios of your app
  • the main scenarios are those, which are generating the biggest value for the end-user

Example:

For Todo type of app it will be something like:

  • User adds Todo
  • User marks Todo as done
  • User deletes Todo

Even simple app has a lot of scenarios. Just imagine how many paths users can take. Why consider only a single scenario at the time? Because it gives you a focus you need to design the best user experience. Remember - a user has only one mission at a time.

The scenario is a sequence of contexts.

Contexts

Contexts are environments where end-users are taking steps of their journey.

The single context for a web app is a onefold situation, e.g. Login View. But when the user is receiving an e-mail, his context is mail client window. It is worth remembering that some parts of the user journey are taken outside the solution you are building.


Key facts:

  • every context is a master component on the contexts Figma page
  • in scenarios, you should use only instances of context components
  • a sequence of contexts is representing a single customer journey - a happy (or unhappy) path

Suggested context types:

  • desktop
  • mobile
  • email

For the desktop app, the single context will be for example [Login context] or [Dashboard]. The scenario is a sequence of contexts.

The first design of the context can be just an empty frame (we suggest to add just a text label for convenience).

Naming convention

Most of the contexts will have similar states, for example:

  • loading - while the context is initiating, data indicator (like spinner)
  • loaded - when the context was fully loaded
  • action - when user is interacting with the context
  • waiting - when the data was submitted and the app is waiting for backend response
  • success - context with success message
  • error - context with a fail message
Naming convention of states example
Naming convention of states example

As you can see, one context will be, in fact, multiple frames with different states.


To compose a context,you should use components from

UI/version Components page.

UI/version -

Components page.

Components

Components are design system elements that you are going to use in multiple contexts.

Naming convention

Components also have context type in its name as the first part. Then you have a name and the variant. The last part is a state in which this component currently is. For Button Component it could be:

  • normal
  • hover
  • pressed
  • inactive

Naming convention of components example
Naming convention of components example

04. How to collaborate

The team

We believe that the best results you can have, is working on scenarios with a whole product team. We are thinking about the product team as a group of key players, e.g.:

  • Project Manager

  • Tech Lead

  • UX/UI Designer

  • Communication Manager

  • Growth Lead

Project cycle

Typical project cycle:

  • 1 Define scenarios
    • a

      for the first iteration think about the main ones, those which generate the most significant value for the end-user

    • b

      create new scenarios or move forward with the unfinished ones

  • 2Discuss every scenario with your product team
    • a

      try to empathize with the end-user

    • b

      make some sketches

    • c

      check how others are solving a similar problem

  • 3Let UX Designer do his work:
    • a

      the designer should start with creating simplified contexts

    • b

      put the contexts in one line on a scenario page

  • 4UX Designer presents scenario steps
    • a

      discuss a potential solution with the whole team

    • b

      get the acceptance of every team member

    • c

      if there is no more comments or concerns, mark scenario as ready

05. Coming Next

We have a few more concepts to describe here. In the next version of Figma Flow we are planning to add:

  • Scenarios grouping
  • Figma → React Components generator
  • Figma plugin for the process automation

For now, we want to gather as much feedback as we can to improve this version before we add even more documentation. Sign up for the newsletter below to learn about new features before they come!

06. FAQ

  • Why Figma?

    We are using Figma because we found it an excellent platform for collaboration. However, it is possible to apply the same way of thinking and executing in other environments.

  • Is it good for bigger projects?

    We are using Figma Flow for projects with 400+ screens and thousands of components. It helps us a lot!

  • Do I need any plugin?

    No, (for now) Figma flow is plugin-free. All you have to do is stick to the naming and component rules.

  • Who is behind the Figma Flow?

    We are the Flow Platform team. Product managers, developers & designers, dreaming of fast and efficient product development process. We've created the Figma Flow for our purpose, and now, we're sharing it for free to the world.

  • Is it free?

    Yes, and it will always be!

07. Sign up for our newsletter

Want to be first to know about the Figma Flow updates?

Leave your e-mail below. No spam - we promise!