Figma files organization’s tips from the Doctolib team

Jérôme Benoit
May 7 · 8 min read

Fact one: Figma is THE design tool of the Design Team for more than a year now at Doctolib.
Fact two: our team has more than doubled, from 11 designers in Q1 2020 to 27 designers today.

This impressive scale has had different impacts on our tool and the way we use it. Every designer has a different level of knowledge on Figma, different methodologies, and of course her/his own background. That’s why processes are a key factor in maintaining structure, clarity and avoid clutter in Figma.

Three aspects must be considered to ensure the robustness of our Figma files:

  • Architecture of our Team Space in Figma
  • The shape of a file
  • Users’ role: access and permissions

Architecture of our team space

A bit of context

For instance, we have one domain managing all B2C topics, one dedicated to Patient File and Consultation, one handling the Agenda (video consultation…) and many other domains. The whole is representing about 30 to 35 features teams from now.

The Product Team structure
The Product Team structure

Basically, we replicate this logic on our team space architecture, so concretely it means each domain has a dedicated Project on Figma. For other topics, such as Design System, Prototypes, Archives, or cross-functional features, specific Projects are also created (I’ll come back to this later).

Readability in the blink of an eye

Exemple of a domain space, with thumbnails of features. By the way, we love acronyms at Doctolib 🙂

The shape of a file


Our three templates (Work File, Archive, Proto) ready to be duplicated
  • Work File is the type of file where magic happens. More seriously, we define this type of file as a functional and rational scope (for instance: booking funnel, practitioner’s profile…)
  • Prototype File is used only for prototypes shared with third parties. We’re notably using Maze for our user research and to be shared, we must set access to everyone with the link. As we do not want to share all our working files with everyone, creating a dedicated file is the safest solution we found.
  • Archive File is used to keep every work we’ve done. Nothing should be deleted. Once a feature is implemented, we clean the work file and put all benchmarks, iterations and related content in an Archive file, in order to lighten and avoid clutter in the source file.

Layer structure

Speaking of localisation, and as it’s a tricky topic to address, we choose to duplicate a feature layer once the initial language of feature has been validated. For example, once a the design is validated, the tech scoping has been done and the french UX writer has adjusted content, the designer duplicate the feature layer and ping the german and italian UX writers to review the content in their respective language. Finally, three layers are displaying the same feature, but this way, UX writers can use copy-pasting plugins without messing with other languages.

Nomenclature and structure of layers depending on templates

We also use “navigational layers”. Basically, the aim of these layers are only to navigate from the Work File to the Prototype or the Archives. They are located in the Work File, as they are mainly used by Designers. Stakeholders like PM or User Researchers are using the Share Links, and does not necessarily needs to see the overall project.

Navigational layer to reach the related Archive File. We use the same concept for Prototype.

Organisational Components

This components are:

  • Status banner. With three variants: In progress, In review or Complete, and displaying the date of last update and name of the designer that made those updates.
  • Sub-headers, used the create section
  • Screen titles, more readable than frame names
  • Sticky Notes, with 4 variants of colors to facilitate annotating screens
Exemple of a validated feature, where iterations has been removed, and status banner indicating last update, name of the designer.

Life and flow of a feature

  • Creating the file by duplicating the Working File template (if the feature is not an improvement of a current one, in this case the designer should reuse the current file)
  • Then, all the iterations are being created in the same layer one above the other, and flagged with the component sub-header.
  • If necessary, a prototype is being created. In this case, there is the Prototype Template.
The four types of sub-headers depending on the progress of the feature

Once the feature has been validated by stakeholders and the designer has made the last refinements, this one should:

  • Change the status of the layer from 🛠 to ✅ and move it to top with all the other validated features
  • Adjust the variant of the sub-header component to display the Validated version (green one as above)
  • An Archive file is created, and all iterations, researches and benchmarks are moved into this file, to only keep the implemented version in the working file, so we have a clear source of truth.
  • The validated layer should be duplicated for other languages (with icons: 🛠🇩🇪 or 🛠🇮🇹)
Life and flow of a feature, from creation to archiving

User’s role: Access & Permissions

Default settings for all templates are:

  • Access: “Anyone at Doctolib with the link” (SSO/SAML logged)
  • Permissions: 👀 “Can view”

There’s a small trick for prototypes, when a prototype is live and used for testing, the access should be set to “Anyone with the link”. Obviously, we got back to normal once the user research phase has ended.

For invited people to a file, we differentiate depending on users status:

  • Design team member: ✏️“Can edit”
  • Every Doctoliber: 👀 “Can view”
  • Third Parties: 👀 “Can view” then ⛔️ “No access” when the access is not required anymore (typically, when the Maze is not live anymore).

Theory vs. real life

You know what I mean… 😉

New feature or sub-feature of an existing one?

Following our above mentioned guidelines, should the designer create a distinct new file, or add a new layer on a file that is not clearly identified as a file containing covid-19 vaccination infos? I mean this may not be obvious for a PM seeking info on such topic to open file named “Opening Slots Management”, even more if this PM is working on another feature team and is not familiar with the feature team’s scope.

What about cross domains features?

Example with transversal features like navigation or specific flows (a document uploader for instance). Regularly, when a topic arise, it’s linked new feature developed by a specific feature team, but this topic exceed the feature team’s scope.

Putting aside the governance issues, what should the design do:

  • create a dedicated file in its domain [ABC] Axxxx Bxxxx Cxxxx? In this case no-one will look for a Document Uploader on the space of a Feature Team owning medical inboxes.
  • Should the designer create layers on each files where the Document uploader is used? In this case, it’s totally impossible to maintain, and update (except if you’re creating powerful organism components).
  • In terms of vision also, the feature team should also work with the other feature teams using this Document Uploader to ensure consistency accross the product and thus, provide a good user experience.

Let’s talk localisation

Since few months that we implemented this method, we gathered good feedbacks from Doctolibers, and really made progresses in clarity and efficiency.

This way, we industrialize and standardize our delivery, which is more and more important as the team is scaling. We never stop iterating and adjusting our processes, so this method will certainly evolve in near of mid-term future. I feel that, soon, we will address issues around cross-domain features. The more time goes on, the more it will be intricated to fix. Stay tuned I’ll keep you posted on our progresses.


Improving Healthcare for Good


Founded in 2013, Doctolib is the fastest growing e-health service in Europe. We provide healthcare professionals with services to improve the efficiency of their organization, transform their patients’ experience, and strengthen cooperation with other practitioners. We help pati

Jérôme Benoit

Written by

Design Ops fueled with passion, currently working to improve the healthcare system @ Doctolib.


Founded in 2013, Doctolib is the fastest growing e-health service in Europe. We provide healthcare professionals with services to improve the efficiency of their organization, transform their patients’ experience, and strengthen cooperation with other practitioners. We help pati

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store