Welcome to the Figma series brought to you by Design at Scale™ – Academy(↘︎Link). After five articles and almost 100+ messages, “How do you …” here are two articles that will bring you closer to practice. I personally try to avoid these types of “five best things for designers” as I find out that most of the time, they only apply to very small groups and actually have very little effect on integrating scalable design functions.

Today’s article is more of an opinion piece than a refresher. In the past, I wrote a few articles reflecting the naming convention(↘︎Link) and organisation of files(↘︎Link). Check them out, if you will. 

Reference.

Let me start by phrasing some of my colleagues' designers who have taken the liberty to share their structures and opinions about Figma structure. You can find the list at the end of References. The only thing that I want to highlight here is the minor adjustments that we designers often miss when describing these structures. We often think that design is the only discipline that needs to be considered in Figma space where, where in fact, we are actually inviting other disciplines to watch the movie.

Imagine for a moment that every designer is a Film Director and brings his entire crew to watch the “Product” Movie. That way, you craft every detail to be findable, exciting to consume and organised to understand—unless you are the director of a specific sadomasochistic genre or some horror movie. You’ll most certainly get some thriller out of it, but not the one that you would expect, leading to successful, stress-free delivery.

My Space – Your Space

We designers grow from a team of one to a team of ten to a team of one hundred; we often carry “My Sace” with us. Is that something that you do too? And if so, what advantages does it have for you and your team? Despite the fact that we humans are all lazy, keeping “My Space” and “Your Space” organised takes a lot of effort, and therefore, people tend to focus on “My Space” first as they can find their documents faster. 

In circumstances where you are a sole trader and a wo/man band, it is kind of obvious that “Your Space” is effective “Clinet’s Space”, and therefore, you are in full control of the environment. In a team of ten, the dynamic changes, and you need to keep things for yourself as well as communicate with others. In this case, we start embracing single client/proposal space as well as department repository and, of course, “your space”. For those who are building new start-ups and need to document + the platform where you run your DevOps (↘︎Link) and project/product management.
Large media Agencies and Product Studios have usually Figma Organisation(↘︎Link) and manage multiple spaces together. Sharing the tokenised design libraries and assets.

Now, despite the setting, the proposition (client) usually has a theme, if not the entire brand. This way, you can tailor your/our Space how you wish people to recognise the files. It allows you to cluster the information by client, industries, asset type viewports, etc. 

Team of 1, 10, 100

This brings us to a fascinating point. The team usually have the following structure: 

• Design Libraries
• Resources
• Online
• Networks
• Clients
  • Aviation
  • Broadcast
  • CTV 
  • Car 
  • Finance 
  • Hospitality
  • Nutrition
  • Sport
• Integrations

(On top of the Business, Time-Sheet, Invoices and all Project management things.)

The above will be debatable in different industries in which you work. You might also see differences when some designers combine all libraries in one place, and some redistribute them across the proposition. Neither one of them is particularly beneficial, and each one has several disadvantages. 

Looking at the Design at Scale™ – Figma space, here are some rationale for how we scale it from 01 to 10:
DaS™ 1.0 DesignSystem (↘︎Link)  
DaS™ 2.0 Online 
DaS™ 3.0 MTD – Method (↘︎Link) 
DaS™ 4.0 GRD – Grid Magazine (↘︎Link)
DaS™ 5.0 ACD – Academy (↘︎Link)
DaS™ 6.0 SPY – Supply (↘︎Link)  
DaS™ 7.0 Resources
DaS™ 8.0 Mentoring
DaS™ 9.0 Integration 

As you can see, despite 01(↘︎Link) , 10(↘︎Link), or 100(↘︎Link), the structure remained the same. All designers have the same access, and all sections play their purpose.
1.0 . DS collects all design systems for online presence, book, print, Service Design(↘︎Link), Product Design(↘︎Link), Marketing(↘︎Link), Instagram(↘︎Link), LinkedIn(↘︎Link), and keynotes, now called Slides(↘︎Link). It is remarkably useful to have one DS for everything consistent with typography, colour, spacing, and tokens. 
2.0 Online covers all Online presence and its evolutions
3+4+5+6.0 covers all four pillars of the DaS™, where we deep dive into different versions of the Method and all necessary presentations. Grid magazine tiles, Academy resources and designers Supply all with one thing in mind – consistency.
7.0 Resources are inspirational files, while
8.0 Mentoring is files about our students and their journey with us.
9.0 Integration summarises five years of social media campaigns and posts across all different media spaces.

Naming Convention

As you can see there is a clear distinktion between names. There are essentially seven different groups of name and tiles, let me explain why.

• CORE – represented by the CORE DASTM. DS
• MTD – represented by DaS™ MTD – Fime_Name
  (only because there is no time nature it is always the latest)
• GRD – reprepsented by Y23 DaS™ GRD – Fime_Name 
• ACD – represented by Y23 DaS™ ACD – Fime_Name 
• SPY – represented by Y23 DaS™ SPY – Fime_Name 
• BUFF – represented by Y23 DaS™ LIN – Fime_Name or Y23 DaS™ IG – Fime_Name 
• BOK – reprepsented by Y24 DaS™ BOK – Fime_Name 

This will allow me to have full capability and three different tiles for each.

Now, whoever searches the GRD in Figma, Jira(↘︎Link), or Confluence(↘︎Link) will get any Grid-related Articles and Resources PNG in three sizes: Grid Magazine, Medium Magazine, and Social Media. We allow the very same search in the file, but in this case, we are getting a little ahead of ourselves. 

The name of tile labels is carried on to Confluence, where each file has its own representative. And it’s not completely artificial. In order to create the assets in the place, we need to know where it go and therefore, there needs to be a definition and purpose for the graphics. That is why the names of the Figma file + Jira Ticket(↘︎Link) and Confluence Page(↘︎Link) match – we would like to waste time searching for anything else entirely all the time. 

Tiles 

Or let’s move on to a fun part. I’m sure if you are designer you have designed one. And if you are design leader you have the privilege to design some other for the department, or design function within your organisation. 

Tiles carry visual queues and, therefore, need to fulfil the function of navigating. Considering the fact that the tile needs to communicate the following:
1. Brand 
2. Name of the File 
3. Version (Optional yet beneficial)
4. Author 
5. Series, Release (Optional yet beneficial) 
6. Status (or some sort of flag that communicates where the file is)
7. Design Library (Optional yet beneficial)
8. Device (if for an individual device, even in the case of multiple devices)
9. Type of file (Optional yet beneficial)

This way we can clearly identify the Type, Status and Author let alone the name. This way and with colour we cna clearly identify what is going on and where we are with the files.  

Sharing

Our Figma space structure reflects the Atlassian structure. That way, we have the same naming convention, and our shared files become very easy to find. No elaboration on the name of the file or what version of who saved it and where. MTG is the method and can be found in the Method folder and MTD File as well as GRD si Grod Magazine and can be gouda in the GRD folder with GRD files and GRD Confluence pages with Y23 / GRD / Medium / … / Hero_Asset.png

I’m not saying this structure is perfect. However, it allowed me as one-man band to start and scale into team of 5 now who continuously collaborate with this great cause.

This brings me to the point: If you want to discover more about how these little details that we can control very well can help your organisation be a better designer and leader, reach out to us at https://designatscale.cc so that we can share our knowledge with you and make the world a better place.

Happy scaling through design!

Hey, I’m Jiri Mocicka. A London-based Designer, Trusted Advisor and author of Design at Scale™ – A method that allows individuals to shape the future organisation through design. Grid Magazine – brings weekly articles about product design development. An Online Academy helps designers find their feed in teams of 01, 01, and 100, supported by Supply, which is a collection of digital artefacts that helps you to become a 1% designer. 

Have a question or are hesitant to ask –join our Design at Scale™ Community to reach out like-minded individuals who scale design propositions.