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.
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:
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:
Now, this could be customized to fit your needs but we found that this structure works great for us.
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:
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.
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 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.
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.
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*
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!
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
Award winning design agency. hello@won.agency
