Single Source of Truth

Problem

When I first joined Pipedrive in 2018, we were around 15 members in the design departement. By 2021, the team had grown to 50+ people. During those three years, the management team started to get more and more negative feedback regarding design specifications. The problem was starting to get out of hand and we decided to investigate.

After conducting key stakeholder interviews, our discoveries were as follows:

• Stakeholders (Product Managers, Engineers, Content Writters, etc.) struggled to find the latest version of a live feature
• Functionalities weren’t always clearly documented anywhere
• Projects were mostly created from scratch and ended-up being not aligned between teams
• Security was poorly managed, external stakeholders could sometimes access business sentive data

Since at the time our Design Operation department consisted of only one person, he had little time to spend looking at design documentation organisation. This meant that some teams were using location-based names or that the files of a single project could be split between many teams.

---

Role

As Product Design Lead, part of my role was to create and improve designer processes both before, during and after missions. Because we had to move extremely fast with Campaigns App (13 missions in 6 months), I became really interested in the most optimal way of defining what was currently live, what was being engineered, and what needed small improvements.

---

Approach

Since this project was touching every single designer in Pipedrive and would require quite some operational effort, we decided to start by defining a proper scope.

There are three different levels that needed to be tackled:

• How should the design organisation structure Figma on a high level (teams, projects)?
• How should each product area organise Figma on a low level (files, components)?
• How can we efficiently communicate designs overtime to multiple stakeholders?

---

Solution

Figma teams and projects structure

We started by creating an underlying set of Dos and Don’ts for team leaders to understand the logic behind the new proposed structure.

Dos	Don’ts
Use problem spaces for team names	Use location or feature names for team names
Use the “Specs” project for what is 100% live after a mission has landed	Randomly mix mission and specs files
Update the “Specs” file in the team where it belongs	Create multiple “Specs” files for the same feature in different teams
Give project access only to stakeholders who actively need it	Give project access to anyone
Remove access when stakeholders don’t need it anymore (eg. change of tribe or role)	Leave permanent access to stakeholders regardless of organisational changes

Team level

To organised our department properly, we started by defining teams and aligning the way projects were created among them. Here is a few examples:

• Design system – public web
• Design system – web app
• Sales
• Leads
• Marketing
• Settings
• Billing
• …

Project level

One level down from teams in the file tree, we have projects. The most important part for us was to provide places where:

• any stakeholder could find anything live in the product
• team stakeholders could find tweaks needed to fix the live product
• designers could express their creativity during projects
• designers could have non project related explorations

To meet reflect those needs, each team is structured with the following projects:

• Specs: source of truth with what is 100 %live for users, open for to all company
• Launchpad: contains launchpad tasks, open for team members
• Playgrounds: contains non-mission related exploration, open to only designers
• Mission projects: contains all mission related iterations, open to only mission members

Figma file structure

Regarding file structure, we’ve interviewed stakeholders to understand what was needed for them to efficiently use design files. Based on our interview results, people needed to find:

• a feature main views
• particular feature states
• the feature functionalities
• who is responsible for a particular feature designs

To meet those needs, we created the following sections

• Masters: main feature views (usually filled state)
• States: feature states (e.g. loading, empty, error, etc…)
• Flows: feature prototypes (e.g. create item, delete item, duplicate item)
• File thumbnails: name of file owner and problem space

This section list is by no means exhaustive and different sections could be added as long as the four previously mentionned were present.

---

Challenges

The main challenge presented itself during the project implementation. Pipedrive design department had felt the pain of switching design tools when moving from Sketch to Figma the previous year. At the time not much attention had been put into structuring design teams and files so that the department could grow exponentially. This year, no one wanted to ask designers for extra operation work. But it has to be done and Design Leads formulated a plan to overcome any added friction.

First, they organised a management workshop to get all Leads on the same page. Then, they got back to their respective teams and gave designers a full day to focus on reorganising their files. Designers weren’t expected to finish everything in one day but had to finish the project over two months with a clear deadline.

---

Results

The teams in which this project was piloted gave a lot of positive feedback. They reported:

• Easier to find latest version of a live feature
• Being less scared of overriding master files during project ideation
• Reduced time to create or update design files

It was quite fun to work on this project because it was the first time I worked on design ops related topic at that scale. I had to collaborate with multiple Leads and Designers and I was able to test it and tweak it with Designers from my own team.