6 Powerful Things To Implement For A Scalable Design Environment

Working with design can be messy. I’ve seen plenty of design environments in Figma that looked so bad that I had to spend a whole day crying in the shower to fully recover and be mentally prepared to tackle it. (Still repairing from the scars until this day).

Having a great design ecosystem optimizes workflow and communication through all stakeholders and of course the design team.

In this article, I will share some of my experiences working in a design environment. Obstacles and problems we’ve faced and how we tackled them. It’s the learnings from 8+ years of working in design environments and a ton of research that's been curated into 6 tips.

Note that all design environments are different and have different needs. Some of the tips may be obvious for some and some may be totally new, either way, this structure has been successful for us and the friends we’ve worked with.

#1 Projects (Right File At The Right Project)

Organizing your projects is crucial for a better workflow. The sooner you apply this method the more grateful you’ll be. As mentioned earlier, I’ve been working in design environments where it took me 17 open Figma files later to find what I was looking for. Let’s break them down for you:

1. ⚡️ Product
   This project is dedicated to new features and improvement work on our product (App Design, Website, etc). It also applies to physical product designs, e.g debit cards for fintech.
2. 🎨 Design System
   This project holds our style guides and components. These files need to be cohesive and intuitive for the whole team to easily understand.
3. 🔥 Marketing
   The project is dedicated to our marketing, website, and community work, which includes docs, blog posts, presentations/decks, social media, etc.
4. 🕹 Playground
   This project is a place for new ideas, Figma training sessions, etc.
5. 🗄 Archive
   We don't delete anything — just archive!If we do major updates, duplicate the old Figma file before editing it and move it here directly. Then change the version number of the duplicated Figma file to a newer one.This is for always keeping track of new changes and having the possibility to go back and see previous design decisions.
6. PS. We use emojis to faster understand what page is what.

#2 Thumbnails (Find Projects At A Glance)

Without this, you’ll find it both hard and time consuming to find what you’re looking for and to know which version is up to date. As mentioned earlier, I’ve been working in design environments where it took me 17 open Figma files later to find the right one and to know which one was the latest version.

Figma’s default thumbnail is simply a screenshot of your first page. Therefore it can look very cluttered and doesn’t give you the right context you need.

We solved this by simply saving the first page in the Figma File as a Cover-page (More about this in Tip #3.). Designed beautifully with the company's style guide. This has a huge impact on finding the right file at a glance at the right time. We simply follow this structure:

1. Date
2. Project Name + Version
3. Status

Now, this could be customized to fit your needs but we found that this structure works great for us.

#3 File Structure (Know Where Each Phase Lives)

Each project file has different needs and setups. For example, a product file may look different from a presentation file. We created various types of boilerplate files to duplicate and use to save time and be consistent in the structure. To understand how this process works, let’s take a deeper dive into the file structure:

1. ▪️ Cover
   As mentioned earlier, we save this spot for the thumbnail.
2. ---------------
   This is the simplest way for us to create a divider. That is its only function and should be added between each section.
3. ✅ Master
   This is the mother of the source. On this page, we’ll ONLY have final designs that are ready for production.
4. 🧭 User Flow
   A place where we visually show the journey of the user flow.
5. 🕹 Prototype
   When creating more advanced prototypes it’s common to move around/duplicate elements for smart animations. This is when this page come in handy.
6. 📝 Wireframes
   This is our playground where we try different concepts and wireframing.
7. 🔍 Research
   Here is a place for mood boards, links to articles, or documentation.
8. 🗄 Archive
   We don't delete anything — just archive!
   If we did some screens that we don’t feel belong on any of the other pages, simply move them here. This is for always keeping track of changes and having the possibility to go back and see previous design decisions.

#4 Design Systems - 50 shades of #GREEEY

Oh my god, this is one of the most crucial things to have in an early stage. Let me tell you a little horror story I call “50 Shades of Grey” (based on real events).

A couple of years ago I was working at a company that had its own SaaS product. The product had been up and running for 5 years and had been handed over by plenty of designers.

On my first day, while firing up the project, one of the developers came to me and said: “Oh, so you working on that project. Fun. The project with 48 colors of gray. I actually counted all of them”. It totally blew my mind. Later that same day I realized that the project indeed had 48 colors of gray and their primary blue color had more than 10 shades on their CTA’s.

Now, because of scaling quickly and other priorities, we didn’t have the time to fix this issue. This is the price you have to pay for not having a solid design system in place at an early stage. Imagine going back and repairing this on the 60+ screens for both desktop and mobile. It cost both money and time. Rumor has it that it still hasn't been fixed.

I will go deeper and cover all the insights I’ve gained in creating a scalable design system but this article would be too long so let’s save that for another time.

#5 Components (Automate Design Changes)

When scaling and designing different types of tasks such as SoMe Content, Email Templates, Presentation Decks, etc… We realized that it was extremely hard to keep track of which mockup screens had the latest design changes. We had to go through them manually and replace each one of them. This took a lot of time. Time that could be spent on more important things.

We created a method for this

We created components of each screen and made a library out of them to use throughout all design files. So whenever we changed a screen, we simply published the changes and all other design files would get a notification saying “Hey! There are some new changes, would you like to review and apply these to this file?”. This way we still had the option to keep the mockups as they were or apply the changes to automatically update all mockup screens on the areas we used them.

This didn’t work out of the box though

By creating a component of a screen you lose some features. By extinguishing fires we created new ones. One critical feature we needed was the sticky topbar and navbar (The “Fix position when scrolling”-feature in Figma). While creating components, our whole prototype setup was wrecked. There was no sticky "Header" or "Footer", just a very long vertical slide on each screen.

We had to go back to the components and find a solution. We came up with a structure that had 3 frames inside a screen component.

1. Top Navigation Bar
   
2. Content
3. Bottom Navigation Bar

And we set constraints for each element. See the picture to understand how. All three sections are actually the same main component. We just hide specific element for each part. I will write another article about this to explain more in-depth how it works.

This way we still had our prototype working and were able to quickly update all mockups throughout the whole design ecosystem. *phuh*

#6 Name convention (Bridge Between Design, Dev & Product)

So now when you’re done with all the screens, created the prototypes, and user journeys your finally done! Or actually… are you? We noticed that on the handover to the developers, they had a hard time knowing how to mention the right screens on their tickets. Some screens look almost identical but have different states.

So we had to go back once again to the drawing board and figure out a way to communicate clearly on how they can talk about each screen.

We did a ton of research and tried different ways until we ended up with an approach that made sense and worked great for us.

It’s a name convention framework that looks something like this:

The improvement was enormous and made life easier for our dear developers. But also for us designers. We went from “We need to fix Create Account State 5 Repeat PIN Code” to “We need to fix screen 1260” real quick!

‍

Thank you for reading this insight.

I hope this insight helped you understand the importance of building a scalable design environment in an early stage. If you found this valuable please feel free to share it with your friends aka industry colleagues and if you have any questions, please let me know. I'd be happy to answer them as well as I can.

Best,
Sam

‍