Unless you're a sole freelancer who never collaborates, what we do is a team sport. In larger or more fast-paced orgs, you'll at some point hand off your designs to someone else. Maybe that's a production artist, a developer, or even another designer who needs to step in if you become unavailable. This almost always results in some level of confusion. You can keep this confusion to a minimum though, by organizing your files and over-communicating.
I spent my early career in production roles, where I inherited files from other designers & had to clean them up to send to vendors (or in some cases, was the vendor getting a massive, unorganized file). Later, when I was primarily front-end development, I had the same issue - often receiving messy PSDs with few notes.
Some of y'all have never worked in production, and it shows.
I'd end up working as a forensic investigator sometimes, trying to decipher layers, states, die lines, etc. Where is this font they're using if it's not in the package folder? Where does this button link to? What does the menu look like when it's open? Why isn't a single layer named?!
It makes it so much easier to hop into a project you didn't start if there's some basic file organization.
As a result, I'm very cognizant of keeping my work clean and clear so anyone coming in to work on it later won't have an uphill battle. Here's what I practice to ensure anyone who comes into a project can get up to speed quickly.
Group and name layers
Let's say another designer has to make a revision to a file on a day you're out on PTO. Not having a lot of project background or familiarity with the file, it's easy to miss an object as you move a section up a row, because it's not in a group.
Yes, this is 100% a real world example. It's a small thing that adds up over time.
I get it, deadlines are always tight. You're working through your design process, in your creative zone, and stopping to rename Group 42 to section.callout--reverse is a pain. Even if you aren't so detailed as to name a group to a pseudo markup/class name convention (my dev side is showing here), at least group modules together.
It's also helpful across the board to have a shared language for different modules. Maybe I think of this section as a "callout". The dev thinks it's a "banner". The client calls it the "promo". When we all touch base again, are we talking about the same thing? A shared language in an organized source of truth makes sure everyone is on the same page.
Pro Tip
Auto-Layout in Figma has become my new best friend. I can layout my design files the way I'd structure my HTML. Need to move a section up or down? Group all the sections, add Auto Layout, and then just reorder the section in the layers panel. The outer group is basically my main element, each subgroup a section. I literally just hit CMD + [ ] to reorder the layers. So easy. And your file stays super organized.
Create saved type styles
This makes your type rules more clear to anyone jumping into a project to iterate on a layout. Is this font style global? Does this h2 scale down on mobile? I'd know if there were type styles saved already (like classes!). All the major apps have this function - make the most of it.
Take notes
Design isn't always as subjective as people think it is. If you're doing your job, the UI design should be tied back to the brief, the strategy document, and work within a budget. There are reasons behind the design decisions we make and we have to be able to speak to them.
But again, if you're in an agency, you're juggling more than one project at a time. There's a reason we have this section before another, but damned if I remember what the hell it was.
As I hit stopping points in my design process - like finishing a page template - I'll take a break and jot down a few notes about the main ideas, goals, and reasons for the choices I made. I like to write a long-form paragraph in Notion, because I'll rely on it when I present over Zoom. And believe me, it will come up in the presentation.
I used to leave tour points in InVision, but when I switched over to Figma, the comments were harder for clients to find. But if you use InVision for client presentations I highly recommend adding your rationales in tour points.
Figma comments are fantastic for dev notes though. If I have a mix of dev notes and client-facing rationales in comments, I'll keep my red line info off the artboard and give it a laptop emoji. This'll make it easier for a dev to scan to see their notes.
Over-communicate
They best projects I've worked on involved design & dev communicating regularly from the start. That means developers should give feedback before the clients sees something, just in case what we've designed isn't feasible (or more likely is feasible but well outside the scoped timeframe).
I like having these regular touch points too, since it means we aren't just throwing a design over the wall and hoping for the best. But if that happens, over-communicating is a two-way street. If a developer has questions - and I've missed annotating an interaction and it ends up being unclear - the last thing I want is for them to just guess.
Cultivate an open-door, ask me anything policy, so these questions can comfortably be asked. It'll save time and headaches down the road.