Design Systems are lively organisms. And so is code. Both UX design and programming are creative and problem-solving activities even though we don’t use the same methods, tools or paths to come up with a solution. But we share the same goal : make a great product. For this product to succeed the whole team needs to build more proximity and understanding of each other’s challenges.
These are a few things I tried as the Product Designer in Treckea to foster mutual understanding and insightful discussions around UX.
- Name everything, name early and rename often — Ctrl+R rocks
- Name your pages as well
- Name your components
- Use versioning
- Use a library (team plan)
- Clean clean clean!
- “Reverse-design” from code
- Plan Weekly UX meetings
Let’s dive into this!
Name everything, name early and rename often — Ctrl+R rocks
Naming things (be it frames, pages, objects, components, even paths) and keeping them tidy is the best thing you can do, both for you and your team. Invest in this practice until it truly becomes a reflex.
Why is it so important?
- You’ll have less mental clutter. As shown in the examples below, if you name things properly you’ll spend less time figuring out what they are. It’s easy to imagine what “card header” is than what “frame555” is. The more explicit, the better. Don’t beat yourself trying to find the perfect name, you can always (bulk)rename later. A mediocre name is still better than “frame”.
- Everyone on the team will share the same taxonomy. Things have different names name for a reason: they’re different. That’s the purpose of taxonomy: giving the right name to things. If you name your elements of design according to the product’s taxonomy then it’s one more step towards shared understanding of what we’re all trying to accomplish.
- You’ll work faster. Designs and Design System grow very quickly. As you go on working on your project you’ll see that you will easily end up withhundreds (thousands?) of objects. If each one has a name, you’ll thank yourself when you have to dive into the depths of your system.
- If you name things early the name will propagate automatically. It means that everytime you duplicate an object Figma creates an object with the same name. Better duplicate “card header” than “ frame 555”.
- You will get significantly better at Information Architecture and taxonomy, which are two major skills a Product Designer should master. In Design, as in code, things must be named and are nested one into another. The DOM itself is a tree and we build things in trees or graphs.
- You will find things easily and rapidly, and reduce the cost of context switching. Not to mention that you’ll be able to search into you Design. If everything is called “FrameXYZ”, you can’t do this.
- When a design lead doesn’t work, you will detect it sooner. If the name (and the nesting and hierarchy of objects) is wrong then the design probably is too.
- Figma renaming feature makes it easy for you to bulk rename objects and thus change your mind on the naming of objects. If you want to change “card header” to “card top zone” and all its occurences, you’ll be able to do so with Figma renaming tool. But not if everything is named “FrameXYZ”.
- If you focus on finding the right names for the objects you will find it easier to apply all kinds of design principles such as Atomic Design. Also, if you spend some time with a front developer to clearly understand how developers create and maintain components it will help you name things accurately.
How to do it?
- Name top-level frames according to the application routes for instance. This will make it easier for developers to navigate through the designs and find their way through. And you’ll improve your understanding of how the app is built.
Having clear top-level frames names is also of great help when you are working in Prototype mode in Figma. In the example below it’s hard to know what frame to select as the opened overlay.
But if frames are named properly it’s a breeze!
- Name all objects and layers. We just saw the benefits for top-level frames (for they are the entry points on the left panel in Figma) but should I mention that you ought to name ALL your objects ? Groups, components, and even text labels, as shown in the left panel here.
Don’t wait to be too advanced in the design process : name your layers early, change the names (with bulk rename) as you progress and improve your information architecture.
Name your pages as well
In Figma, design files can contain multiple pages so that your work stays organized. You can create as many pages as you want and name them wisely. The way you name your pages generally depends on you design organization. If you don’t use a library, you generally keep components in different pages than your compositions. Here are 3 different examples.
- This example is a simple and single file organization with no library. I created 3 pages : one for my paper wireframes (which work in prototype mode 😜)️, one for the digital wireframes and a dedicated page for components. This works for a very simple project but would not be robust for a larger one.
2. In the Treckea Design System I organized pages according to Atomic Design principles. This way, developers can easily navigate to tokens (typography, colors, etc.), atoms (icons, avatar, badges, labels and form controls), molecules (mainly navigation components), components (things like cards, modals, alerts, toasts, etc.) and templates.
3. In the Treckea prototype file, which taps into the Design System above, I have arranged the digital prototypes into pages so that each page focuses on a specific functional userflow. Note how you can add spaces and special characters in your pagenames. That is how I created a visual hierarchy with spaces. The ► symbol indicates that the prototype mode is available (viewers can press play to interact with it).
I like to maintain a complete app prototype on the “root” page so that anyone in the team can make a complete interactive demo of the app by just hitting the play button. A lot to maintain but so useful!
Whatever organization, whatever project size, find the naming system that suits your needs and name your pages accordingly. It will help others understand how your work.
Name your components
Everything about frames is also true for components. It’s even more critical to have acurate names for your components because every time you create an instance of a component in your compositions, the component name will be applied to the instance. In other words, the components name propagates to all its instances.
Figma provides powerful and intuitive ways for grouping objects into “folders”, allowing you to collate objects according to their functional scope, or whatever structure you might want to use.
“Frame544” will propagate to all its instances, so don’t do that. (re)Name your components so that everyone know what they are. Including you when you come back from vacation.
Use versioning
Figma is magic and even has a time machine : versions.
In addition to saving your work seamlessly, Figma lets you save versions (like checkpoints) so label a version everytime you hit a major milestone in your design. Versions help you keep your file clean, organized and up-to-date. You’ll be able to remove any deprecated or unused object knowing that you can go back in time if you need to get it back. On paid plans, you can access the whole file’s history.
Use a consistent pattern for your version names. I personnaly use the “Friends” titling system :) It’s not the most efficient one because all versions begin with “The one with / where” and it take some place in the right panel, but I like the gimmick.
If you use versions you won’t be afraid to remove unused and deprecated components because you can always go back in time and restore them. Keep it tidy and fresh!
Use a library (team plan)
If you can afford a paid Figma license, libraries are one of the amazing benefits of a team plan. Basically, it’s like git but for designers.
Libraries are Figma files that centralize reusable components. When changes are made in your library, all files using components of your library are notified and can update (or not) to the latest version of components. This ensure consistency in your designs.
Think of libraries as shared repositories for components.
They are particularly useful when a team of designers is working on the same Design System but you can benefit from their features even if you are the only designer in your team.
Libraries facilitate the sharing of your designs because they provide the single source of truth and latest version of the objects you are working on. It’s particularly important that you keep them organized, understandable and clean. All tips mentioned in this post apply to your library contents.
Tess Gadd wrote a great article about her organization with Figma files and Flows that inspired me a lot for organizing my own work.
Clean clean clean!
If you are working on several compositions at the same time or if your are several designers on the same design, it is important that the team (both designers and developers) knows that the Design System is reliable (“I’m looking at the right object”) and fresh (“it’s the latest validated version”). That’s one of the hardest parts to achieve because you always need to be working on different leads and the system is a living organism in perpetual evolution.
To achieve reliability and freshnesh you can
- remove unused components. For this, I personally use a plugin called “Instance Finder” that helps me find all instances of a component in a Figma File. When I think that an object is not used anymore, before deleting it, I make sure no instance references it anymore.
- move or remove deprecated components. Deprecated components are objects that are still in use somewhere in your file while having a newer version in your Design System.
- find a signage to indicate the state of the work. There are many ways to help you get there : you can either put your Work In Progress in a dedicated page or dedicated frame of the page or add a tagging system like Igor Lanko’s or use some dedicated plugins like Status Annotation by Thomas Lowry
Many other plugins exist to help you maintain you designs clean and tidy. In 20 Figma Plugins, Carefully Selected By Experienced Designers you will find other plugins to keep your Design System organized.
“Reverse-design” from code
Your design system evolves and so does the code. It is inevitable that the two end up living different lives but you want to keep them as tight as possible. Some say developers have to stick to the design at all costs. I say we have to adapt to each other.
That’s why at regular intervals I do “reverse designing” sessions to adapt components and layouts to their actual implementation. With a frontend developer, we examine a layout or a component closely to spot any difference between design and implementation and we see how we can make the two converge. Sometimes I have to adapt the component, sometime my fellow developer has to adapt the code or the CSS theme.
On top of keeping design and code as homogeneous as possible those little “peer sessions” with a front developer help me understand the constraints of the front men and it helps them understand mine.
Plan Weekly UX meetings
Last but not least, to ease a shared understanding both of the designs and the process, I have established a weekly UX ritual through which I present the UX work in progress, discuss leads and dead-ends and give the team visibility on where I’m at.
I use a gitlab board — shared with all the team — to show the progress of my work. Since gitlab is the tool our developers use as our code repository, there is very little friction and no barrier to entry to the tool: everyone can see the board and what’s going on. Plus, I used the same conventions as our functional board (like gitmojis for instance).
I update each issue as I work according to this lifecycle
- issue is opened with a simple title (based on a feedback or painpoint) and description of the the design request
- issue is updated with paper prototypes that are then discussed in the weekly UX meeting
- issue is updated with the Figma prototype when ready and this prototype is demonstrated in the weekly UX meeting
- issue is ready for implementation and a corresponding issue is created in the functional repository
- issue was developed and passed the acceptance tests: yay we can close it!
Conclusion
I believe UX design is a social, collaborative and holistic activity. The closer the designers and developers work together and understand each other, the better the product will be.
If you manage to save some time every week for small tasks that improve shared understanding, you’ll get amazing results. Feel free to leave your own tips in the comments, I’d be happy to try them out!
