Make design files (in Figma) great again

Were design files ever great?

Figma (or any other design tool) can be hell. Not because it’s a bad tool, but because we who design in Figma make it hell to navigate.

Forgive me, for I have sinned. And I will sin again.

The folder structure is a mess, the files have confusing names, there is no rational way to understand which screens are in which file, and opening a single design file is like opening pandora’s box. Some pages have names starting with “Doodles”. Several pages have page names ending with “OLD” or “Archived”. Some have page names including “2019” and “2020” (some improvement over simply naming it old, I guess). Some page names seem to indicate there are several projects within the same file, but not being part of these projects, I have no idea.

There’s nothing new about this, of course. It’s been this way since Photoshop was the main go-to design tool. When a typical file name would end with “new final final v2”. It may work for the person who actually created the folder structure and file names, but even they will struggle if they put away the project for a few months and come back.

Why do we keep doing this?

This issue has bothered me for a long time. Not only at Kolonial.no. It’s been that way in almost all companies and projects I’ve worked in. Having to take over some other designer’s project folders is a really bad user experience 9 out of 10 times.

Isn’t it time we did something about this?

Why should you even care?

Using and navigating our design files is a user experience in itself. The end users of our files are different, generally more tech savvy and with a higher tolerance for mess. After all, they don’t have the choice to just abandon your design files if they can’t find what they are after, or if finding the latest version of a design for the correct screen in the correct project is a nightmare.

It may not feel important right now how your colleague developers, product managers and designers will experience things. They will probably quietly suffer, because designers are often accepted as creative and messy.

Even if you don’t care right now that your colleagues will get frustrated, keep asking you where the correct screen is, or even incorrectly implement an old, outdated design sketch, think about this: You, the designer, are also an end user. If you make a mess now, it will also create problems for your future self.

Be excellent. Do your future self a favor now.

Shared design system components allow you to design and iterate quickly instead of spending time on creating and maintaining components across multiple files. Likewise, a shared way of organizing files gives you a great starting point, and helps you spend less time on tidying up and finding what you or others are looking for.

How this all started

A few months ago, I interviewed a young designer for a position with us. I’m happy to say she’s now one of our designers (👋 Mia). Looking at one of her design files was a revelation for me. The final big kick in the butt I needed to something about the problem.

Her file had such a nice page naming structure. I immediately understood what was what. Where to find the latest updated sketches. Understanding what was prototype alternatives, what was explorative designs, what had been discarded.

So I did what designers do well. Steal an idea and iterate on it.

First, I took a step back. I realized that this isn’t just about having a clear and easy to understand page structure in your files. There are several problems to solve:

1. Organizing the folder structure
2. Making it easier to visually identify the correct file
3. Naming pages in design files
4. Structuring screens and screen flows on a page

Let’s nerd out on the details for each problem.

Organizing the folder structure

This is the tricky part, and I don’t have a magical one-size-fits-all solution. Spotify has a well-written article on the subject, with a solution I think works well for many companies:

• 1 Figma team = 1 Product
• 1 Figma project = 1 product’s features or feature sets
• 1 Figma file = 1 feature or feature set

For the Logistics side of our company, however, this structure doesn’t translate that well to our setup. The vast majority of the projects we work on are related to a stand-alone tool (or app, which sounds much cooler), and there are many apps. Each of these apps are made for a specific area, such as picking or terminal. And each of these areas are connected to one of three stand-alone systems. So the structure looks like this:

• System
• Area
• App

This is how all apps (be cool, remember) are organized within each platform when we access them in our web browsers. Developers seem to be pretty good at this organizing thing. Come to think of it, they’re pretty good at solving those other problems I listed as well. We’ll get back to that later.

Now, the structure I mentioned is not set in stone. New systems or areas may be added. Areas may be renamed or split up. But, the point is, we have a fairly stable and understandable structure already.

To complicate things, though, we have several physical teams. Each app is the main responsibility of one team. We’ve discussed several approaches, each with it’s pros and cons.

We could replicate the System > Area > App structure. But this does not seem very user friendly. It would make each Figma team massive, and there would be a mix of projects and files you and your team is responsible for and not. A lot of information to filter out.

To make each Figma team more manageable, we ended up with this structure:
The responsibility for each app is divided between different physical teams. So we have a structure like this:

• 1 Figma team = 1 physical team
• 1 Figma project = 1 area, and the system it belongs to
• 1 Figma file = 1 app

An example of what this would look like internally, is:

• Delivery (Team)
• Bravo - Delivery (System name + Area name)
• Partner portal (App name)

There are cases where two teams work on the same app. But, when this happens there is still one team which is the main owner, while the other team contributes to smaller parts of the app.

Oh, and before you ask. Yes, there are a few files that are not directly representing an app, but they are still related to an area. So it still works out.

As I mentioned, this structure doesn’t work for everyone, even within Kolonial. Our designer colleagues working on customer facing solutions (website and apps for our customers) won’t be able to use the same structure at all. Then again, I’m sure they’ll figure it out.

Okay, first problem mostly solved.

Making it easier to visually identify the correct file

Do your file thumbnails look like this within your folders? Is this the visual equivalent of nails on a chalkboard? It is to me.

I don’t know how to tell these apart without reading the tiny title text below each thumbnail. And sure, the files can have file names that make sense. Then again, if there are sketches for several apps in one file, they might not.

If, and only if, the folder structure already makes sense, and we have one file per app, it’s still not all unicorns and rainbows. Custom file thumbnails aren’t new for most, but I might still have a few useful tips for how to use them.

First, color-coding can help. It can also make it worse if you overdo it. If you have five different colors, you’ll quickly forget what they mean. So if you do use color-coding, keep it simple. We use two states for thumbnails — active and inactive. Active projects have a purple background, inactive ones a dark gray background. Pretty intuitive, you don’t need to be a genius to decode it.

Second, emojis. Yes, they are loved and hated. Plus, Figma for some reason does not support all emojis.

Why, Figma, why?

Frustration aside; See how each thumbnail has a big emoji and next to the app name? I didn’t add them just because I want to seem young and cool. They serve a purpose.

One quick glance, and I recognize the project I’m looking for immediately by background color, emoji, and a big fat title.

There’s also a short description below the title, with a short plain-text description of the purpose of the app. So if you’re new to a project, or just poking around, it’s easier to understand what you’ll find inside the file.

Can you feel that buddy?

Naming pages in design files

Okay, so if you’ve figured out the first two steps. Most people should be able to find the Figma file they’re looking for without messaging you on Slack.

But then they realize they can’t find a particular screen they were supposed to look at. So you end up having to post a link to the particular screen inside the file anyway. Guess the job isn’t done yet.

I hope this doesn’t put me in a bad spot, but I took some screenshots from around our own Figma files. I am not without sin. I too have used page names like these, thrown in blank pages to have dividers, and so on up until very recently. And I still catch myself using unclear names and having to tidy up.

So what’s the problem? Well, for one I don’t really know where to start looking for the latest sketches that should be or have been implemented. Some might put the newest and most relevant at the top of the list of pages, others at the bottom, or anywhere in between. Also, within each page, some screens may be the latest versions, while others may be experiments or rough sketches.

What about prototypes? Are there any? Are there several? Are there more than one on a page? Impossible to easily discover.

What about page names ending with [OLD]? Other designers might use terms like “archived”, “junkyard” and so on. Why not use the same terms? More importantly, what is the intent the designer had with keeping those screens?

We ended up defining a set of page types. Each page type serves a specific purpose, and indicated to the person viewing the file whether it is relevant to look at or not.

Here is what we ended up with so far (we can always iterate):

• ✅ Spec
  The latest designs. This is what the developers in your team is supposed to implement, or which is already implemented in code. As you all know, not something which is set in stone, there could be further iterations. (Sidenote: Spec is not a great name, I know. Got a suggestion?)
• 🎈 Playground
  Where you can experiment with different alternatives without being afraid someone suddenly takes it as the final design. A good place for when you want to test multiple designs.
• ↪️ Prototype
  Where you can create prototypes, for yourself or for testing. Prototypes can quickly become complex and since Figma only allows one starting frame per page, you might need to create a new page for each prototype.
• ⚰️ Graveyard
  Where you can stash away old versions, because Figma’s Version History isn’t very convenient. Probably makes sense to have several of these graveyards, one for each major iteration.
• 🔀 Flow Chart / Process map
  If you’re mapping out the flow of things in Figma, or other charts and stuff.
• 🎛 Local Components
  Where you can keep the components/symbols you create in your work files in a safe place where you won’t accidentally delete them or mess them up.
• Cover
  A custom file thumbnail with short project info to make it easy to identify what you’ll find in the file. We’ve covered this before. See what I did there?

This doesn’t mean you can only use one page type once within a file. That’s why they’re called page types. You can have several.

You’ll probably want to create several prototypes. One page per prototype makes it a lot easier to test several up against each other.

You might have several iterations, and want to keep each one as a separate page, using the Graveyard page type.

You might even have several Spec pages. I’ve had projects where we not only create the designs for what is shown on a screen but also designs for physical labels. Even a physical trolley, actually. Makes sense to me to keep the sketches for these on separate pages, and name them accordingly. I used “Spec: App” for the app screens. Other, descriptive names for the other pages using the same page type.

Use clear page names, especially if you have several of the same page type in a file. If you have three Graveyard pages, put in the date they were last updated. Makes your life (or others’) easier in the future. And use a date format that cannot be misunderstood. Since we can’t all agree on date formats containing only numbers, “Dec 2020” or “25 Dec 2020” is pretty much fail-proof.

Structuring screens and screen flows on a page

Wow, I feel like the world is already a better place.

Let’s take a quick step back here. As you know, there are some important steps in all design processes. Talking to key stakeholders (designers, developers, PMs), observing usage, testing, gathering feedback, and discussions in design meetings were instrumental also in this process. All that input helped us iterate and to create a system that can work for everyone. Not all designers — everyone.

Alrighty then! Let’s enjoy this moment of enlightenment before moving on.

There were two big issues: navigating to the correct screens, especially within a long, complex flow, and keeping track of changes.

The first step here is to break it all up into smaller flows if there are several main processes with multiple steps. Each of these flows should also start with a frame containing a description of the goal of the process, the main steps, requirements, and so on. Keep it short, though, you don’t need to write down all details inside the design file.

Cleaning up and keeping things organized isn’t a lot of fun for most people, and documentation probably isn’t either. But it’s worth spending some time on it to avoid miscommunication.

The second step is annotations and changelog. I know, this also sounds super fun, right? I bet those words got your creative juices flowing. Well, there are a few things here to learn from our friends, the developers.

You know developers comment on their code so others (or their future selves’) will understand why things were solved like they were? What if designers did the same, to explain the details that are not self-explanatory in your sketches? For example, how is that list in your design sorted? What is included or excluded from your design, and why?

A changelog basically just means noting down the date for when a screen was last updated (or added, if it’s new) and what you changed. This makes it so much easier for everyone to be aware of what has been changed since last time. Things you may easily forget, and others may easily overlook. Again, use a date format that can’t be misunderstood — like 25 Dec 2020.

That’s it! All done!

Well, that’s probably not true. Things are never done in our line of work. There’s still things to improve. But, hopefully you got a few tips (and a kick in the butt) to help you get started.

We’ve set up a Figma template to kick start new design projects, which you can download here. Feel free to make it your own and share it!

Once you have started to make your design files great again, keep testing and getting feedback on how to improve.

This is the way.