How Spotify Organises Work in Figma to Improve Collaboration

Check out our Figma Ways of Working above, and have a read of this article to understand some of the rationale behind it. We hope this information will be useful for other design teams seeking more organisation for their work in Figma.

Defining our goal

At Spotify Design, we actively encourage everyone to explore problems together, get inspired by one another and find harmony across design solutions. So as we were planning the migration, we set a goal to boost this effort and guide us through the whole process: organise our work in ways that improve collaboration between designers. New tools such as Abstract and Figma offer the ability to work together like never before, but allowing multiple people into the same file doesn’t automatically lead to better collaboration. Our files would need to be organised in a way that is visible and discoverable by everyone. After all, you can’t collaborate on work that you can’t find.

This is especially true in organisations like Spotify. Our squad model is optimised for autonomy, which is beneficial for many reasons but can result in designers working in isolation. Not only are we spread out amongst cross-functional squads, but we’re also spread across multiple product areas—which we call “business units”—and numerous offices around the world.

New process, new challenges 

In our pursuit of greater visibility of work, we needed to be mindful of how we impacted speed and effort—two important factors in a designer’s workflow. Increasing visibility can be detrimental as it introduces more people, more structure, more rules, and more thinking to simple tasks. Our decisions could easily increase the effort required to keep work organised or make it slower to navigate to files, potentially resulting in fewer sketches, prototypes, and iterations. The challenge was to balance our need for both visibility and speed.

Previous attempts at storing our design files helped us understand how the migration might play out if we weren’t thoughtful enough. Some of the things we anticipated when designing the Figma workflow were:

• People naturally optimise for speed, creating personal workflows and carving out private spaces for themselves or their squad. While standards can improve speed in the long run, individual workflows seem more immediately beneficial. 

• People interpret structure in their own way using various mental models—teams, products, projects, people—and standards rarely develop organically. Guidelines have to be clear and intuitive to break through individual instincts. 

• While some people iterate on features and document specs within the same file, others separate them into different documents. Seemingly small decisions flow into processes with engineers and PMs and define their understanding of how to find work.

We had to take every detail of these behaviours into consideration before moving forward.

Ways of working 

So we had a goal, and we knew the challenges that lay ahead, but how did we tackle the problem? Design Ops used our trusted working group (WG) model and pulled together a crew of designers from across Spotify that were able to represent the design teams in their business units.

To start, the group defined a set of principles that reflected our objectives and would guide our ideas:

• Unifying: People should be organically exposed to other relevant work, regardless of where they sit in the org.

• Discoverable: Work should have a clear home. There should be no lingo, no hunting for files, and no getting lost.

• Manageable: Spaces shouldn’t become so busy that files aren’t easy to organise and access.

• Sustainable: The number of teams and projects shouldn’t grow to an untenable size, become irrelevant, or need to be frequently changed.

• Autonomous: Each team should be empowered to diverge from our recommendations, acknowledging that one solution may not work for everyone.

From there, we explored a spectrum of options that aimed to balance visibility and speed. Some increased the size of spaces where more people would work alongside each other, while others narrowed them down to smaller definitions with just a couple of designers working side-by-side. With a set of options, a stack of printouts, and even Figma prototypes, we conducted rounds of research with designers in our business units. Yes, we got that nerdy. We had file structure design workshops! 

Here’s an example of some of the workshop material:

The workshops allowed us to identify the most common mental models, test the intuitiveness of our ideas and give everyone a voice. Perhaps most importantly, it gave the design team some empathy for the problem we were trying to solve. We can be passionate about our personal workflows (we use them every day!) so sharing the problem with the team helped them recognise how differently everyone can think about these things.

The outcome

This process led us to the following three key decisions:

1. Teams will be organised by the products we build. 

2. Projects will be organised by a product’s features or feature sets. 

3. Specs will be centralised inside a single project in each team.

Organising Teams in this way communicates our expansive product suite at Spotify such as our mobile app, Spotify Kids, Ad Studio, Spotify for Artists, Anchor, and many other external and internal products. From our org overview you can immediately tell that design work from the whole company is right at your fingertips. The structure guides designers from different business units and squads to work together in the same space when designing for the same product, and it enables us to cleanly map our Encore (design system) libraries to each team.

These same attributes are reflected in the Team structure where a product's set of features are communicated through Projects. Emojis help us distinguish between specs, feature explorations, new initiatives, and a playground for quick ideas, and each Project is usually filled with work from only three or four designers so people still have a sense of their own, personal space.

Lastly, we took the opportunity to reconsider how and where we document our specs—the screens, states, and flows that represent our source of truth. Our decision didn’t immediately feel intuitive to the design team, but we held a strong conviction that its value would soon become apparent.

“Where’s the latest design?” is a message we send and receive far too often. Similar to how we’re bringing visibility to exploration work through our new Team and Project structures, we also wanted to pull specs out from individual files and into the open. Each Team (i.e. product) now has a single spec file, and within those files are pages that represent each of our features. As a designer hones in on a solution, they move their work into these centralised specs to document their decisions. 

Like the software we ship, these specs constantly evolve as old screens replace new ones, and components update to take on new forms and functionality. It’s a representation that we are all working together towards a unified product, sharing patterns and solutions with each other. And there is no "looking at the wrong thing," because there is only one place to look.

Where it all comes together 

Finally, the WG developed a playbook and incorporated this into the training we hosted when we onboarded designers onto Figma. The WG needed to do some polite policing, regularly checking the tool to do some light housekeeping—checking on rogue teams (often with random squad names), pinging people on Slack when we saw diversions to the conventions, and hosting demos to show people how to set up things correctly. We created a #figma channel for designers to ask us questions and even added some external folk from the Figma product team.

We have now been using the new structure for three months and so far, so good. For the most part, designers have adhered to the system, and we have seen instances of teams across the organisation collaborating on products, rather than hiding their work inside their orgs. We believe this will have the impact we set out to achieve, and we’ll continue to iterate as we receive feedback and notice emerging trends.

If you're going through the process of creating your own organisation system, remember to use your design team’s superpowers to help guide your structure—research how your own team works, test ideas with designers, and prototype solutions before agreeing on a structure that works for your team culture. 

— Shoutout to our Figma WG members: Achal Varma, Alex Cameron, Daniel Elg, David Owen Morgan, Ed Samour, Felipe Fiuza, Hanna Brazier, Ian VanNest, Jacqueline Sibert, Juli Sombat, Kamdyn Moore, Mattias Johansson, Michael Brand, Mikael Sundström, Nicholas Atkins, Patrik Nyblad and Shamik Ray!