Figma files organization’s tips from the Doctolib team
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
As many agile companies, the Product Team at Doctolib is divided in domains, each domain divided in features teams, each feature teams composed of Product Managers, Engineering Managers, Developers, Product Designers and UX Researchers. UX writers are transverse to the feature teams and participating to every projects depending on the localisation of the feature, and Product Designers are working for at least two feature teams.
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.
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
To ease the understanding and help stakeholders finding quickly a specific project, we set up a basic rule: each file must have a formatted thumbnail, specifying the Name of the Project, the feature team involved, and a screenshot. This thumbnail is of course located in its own layer with a normalized name: 🖼 Cover.
The shape of a file
Templates
To maintain standardisation and facilitate the creation of any file for designers, templates are a great help. Three templates are available: Work file, Prototypes, Archives.
- 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
Each template has the same logic but different type of layers. The use of icons is a best practice to ease the identification of validated and/or implemented features whereas ones that are still work in progress.
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.
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.
Organisational Components
In parallel of the layers, we use components that are added to our design system Oxygen.
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
Life and flow of a feature
When the creation of a feature is launched, and the kick off has been realized with all the stakeholders, the concerned designer has to:
- 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.
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 🛠🇮🇹)
User’s role: Access & Permissions
First of all, we follow two boyscout rules: Never give Edit Rights outside the Design Team, and never select “Anyone with the link” access by default, except for Prototypes.
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
We all know that real life is not a long quiet river, and everything is not that simple.
New feature or sub-feature of an existing one?
When does a topic becomes a feature? Let’s take a hot topic: we need to integrate a tag displaying covid-19 vaccination available doses or slots. That means the designer has to create the dedicated chip and add it on few different screens depending of different feature teams.
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?
Almost the same issue, but not related for the “size” of the feature, but more with the overall vision of our products. What about feature that has an impact on all the product, 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
For now, Doctolib is implemented in France, Germany and Italy. That’s quite simple to handle with only three countries. But if we create a layer for each language for a feature, it means a file containing 4 features will have 12 layers… If we had 12 countries, we would have 48 layers…
The multiplicity of layers could be really annoying and is not scalable at all.
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.
