Unlock exclusive free benefits that come with your purchase, thoughtfully crafted to supercharge your learning journey and help you learn without limits.

Here’s a quick overview of what you get with this book:

Next-gen reader

Figure 1.1: Illustration of the next-gen Packt Reader’s features

Our web-based reader, designed to help you learn effectively, comes with the following features: Multi-device progress sync: Learn from any device with seamless progress sync. Highlighting and notetaking: Turn your reading into lasting knowledge. Bookmarking: Revisit your most important learnings anytime. Dark mode: Focus with minimal eye strain by switching to dark or sepia mode.

Interactive AI assistant (beta)

Figure 1.2: Illustration of Packt’s AI assistant

Our interactive AI assistant has been trained on the content of this book, to maximize your learning experience. It comes with the following features: Summarize it: Summarize key sections or an entire chapter. AI code explainers: In the next-gen Packt Reader, click the Explain button above each code block for AI-powered code explanations. Note: The AI assistant is part of next-gen Packt Reader and is still in beta.

DRM-free PDF or ePub version

Figure 1.3: Free PDF and ePub

Learn without limits with the following perks included with your purchase: Learn from anywhere with a DRM-free PDF copy of this book. Use your favorite e-reader to learn using a DRM-free ePub version of this book.

Unlock this book’s exclusive benefits now Scan this QR code or go to packtpub.com/unlock, then search for this book by name. Ensure it’s the correct edition.
Note: Keep your purchase invoice ready before you start.

One of the most persistent challenges in product development is the interaction between designers and developers. While both disciplines work toward the same goal—creating functional, user-friendly products—they often approach problems from entirely different perspectives, leading to friction and miscommunication.

What’s the problem?

Designers and developers are two essential forces in product development, but they often struggle to understand each other. As a designer, it’s important to remember that what you create in Figma isn’t the final product—the production code is. However, despite working toward the same goal, many teams face miscommunication that goes beyond just different terminologies and perspectives.

The challenges run much deeper than word choices. Designers and developers operate with fundamentally different mental models. Designers work with fluid, relational thinking, placing elements freely in space and considering visual hierarchy and flow—much like how Figma’s free-canvas approach works. Developers, on the other hand, operate within structured, hierarchical frameworks shaped by how code, databases, and systems are organized. They think in terms of top-to-bottom sequences, nested structures, and rigid organizational principles. This fundamental difference in spatial thinking creates natural tension when translating design to code.

Additionally, there’s often a knowledge gap around existing technical infrastructure. New designers, and even experienced ones joining a project, may lack the historical context of how current systems were built, what technical constraints exist, or what potential blockers might arise from legacy code. Understanding the production environment and existing technical architecture is crucial for creating designs that work within real-world constraints, not just in an ideal vacuum.

Here are some common terminology differences between Figma and code:

Table 1.1 – Terminology difference between Figma and code

Understanding these differences is crucial to ensuring a smoother workflow and more effective collaboration between designers and developers.

How to fix it

To bridge this gap, designers and developers must actively work toward a common understanding:

• Involve developers early: Bringing developers into the design process from the start ensures technical feasibility and helps avoid late-stage surprises. Make sure everyone understands the purpose behind design decisions through clear design annotation. I highly recommend walking through the entire design with developers, explicitly describing each screen and interaction rather than assuming anything is “obvious.” This serves two crucial purposes: developers can challenge your solutions and gain a deep understanding of user flows and interactions, while you, as a designer, can catch hidden flaws you might have missed during the design phase or that went unnoticed during design critiques.
• Establish a shared vocabulary: Document and define key terms that designers and developers use differently. This makes communication clearer and reduces misunderstandings. Consider using tools such as Storybook or similar documentation platforms to create a shared reference point where both teams can see how design components translate to code, helping establish common terminology and understanding.
• Use Figma’s Dev Mode: Leverage Figma’s developer handoff features to provide precise specifications and make it easier for developers to inspect design elements.
• Encourage cross-team learning: Designers should develop a basic understanding of development constraints, while developers should familiarize themselves with design principles.
• Create a feedback loop: Regularly review designs together to ensure alignment and address potential issues before they escalate. Remember that this loop goes both ways. Designers should also be involved in QA processes to verify that implementations match design intent, helping prevent details from getting lost in translation. Make sure everyone knows their roles and responsibilities, and establish clear points of contact so team members know who to reach out to when questions or ambiguities arise.

There are two primary ways to establish continuous feedback loops:

• Scheduled weekly feedback sessions: This is the most common approach, where teams set up recurring calendar meetings for feedback. Designers present their progress, and other designers and developers discuss any necessary changes or improvements.
• Daily asynchronous feedback: A more fluid approach, which I personally prefer, involves integrating feedback into the team’s everyday workflow. At Dotidot, designers and developers provide feedback asynchronously at the end of each day using Loom recordings. This fosters a culture where feedback is a natural and ongoing part of collaboration, rather than being confined to structured meetings.

Even if your team lacks hybrid designer developers, following these practices will save significant time, reduce confusion, and create a more seamless workflow between both disciplines.

We’ve all been there. You sit in a meeting room (or on a video call) listening to someone explain what each screen does, what happens when you click this button, and why they chose that particular color. Meanwhile, you’re thinking, “I could have understood this in half the time if it were properly documented.” Design meetings are essential, but when they become repetitive explanation sessions rather than productive decision-making discussions, they drain energy and slow down progress.

What’s the problem?

Endless design meetings often consume valuable time without adding significant value. While collaboration is essential, excessive discussions over the same design elements can lead to delays, frustration, and decision fatigue. Instead of refining and progressing, teams can get stuck in cycles of unnecessary revisions and redundant conversations.

A key difference between junior and senior designers is how they approach documentation and handoff. Experienced designers go beyond aesthetics—they consider functionality and development requirements upfront, reducing the need for excessive meetings. By structuring Figma files effectively and using built-in collaboration tools, teams can minimize disruptions and maximize efficiency.

How to fix it

To break free from the cycle of excessive design meetings, we can leverage screen annotations. Effectively using screen annotations helps convey the full story behind your design. It’s important to note that these are custom-built components that we create and use in Figma, not built-in Figma features. You’ll need to design and build these annotation components yourself or as a team to use them in your design files. Here’s how to utilize them better:

• Figma file structure: Before diving into specific annotations, establish a consistent Figma file structure that serves as a single source of truth for your entire project. I use a standard seven-page structure in all my projects:
  • 01 – Getting Started
  • 02 – Project Name
  • 03 – Documentation
  • 04 – Components
  • 05 – Playground and Exploration
  • 06 – Archive
  • 07 – Cover

This unchangeable structure helps me easily duplicate files and start new projects quickly, while developers know exactly where to find what they need. We’ll dive much deeper into this file organization approach in Chapter 4, where I’ll share the detailed methodology behind each page and how it enhances designer-developer collaboration.

• Designer notes: Add context directly next to your design with designer notes. Avoid using comments or Figma Dev Mode annotations, as Dev annotations require all users to have paid seats. Comments can be used even from viewer seats (free), but can be easily lost, and they aren’t shown at first glance as easily as designer notes.

Instead, rely on prepared elements for clarity.

Figure 1.4 – An example designer note

This card demonstrates how to provide additional context within Figma designs. The note explains that filtering is based on the provided documentation and highlights specific parameters used in the project. Visual annotations direct attention to essential elements, ensuring clarity and fostering collaboration.

• Copy note: Provide specific copywriting instructions to ensure developers understand how to implement text accurately within the design.

Figure 1.5 – An example copywriting instruction

• Variant annotations: Don’t duplicate your design just to showcase small changes. Duplicating entire designs can create confusion about development complexity. At first glance, a project may seem much larger and more complex than it actually is. Additionally, excessive duplication can overwhelm developers, making it easier to miss crucial details buried within an abundance of similar-looking screens. Use variant cards to illustrate differences clearly and help developers grasp the full scope of adjustments. For example, opening a Figma file with 10 screens might appear overwhelming but could represent small changes on a few screens. Variants streamline first impressions, time estimation, and overall clarity. However, when variant logic becomes too complex to explain through annotations alone, consider using prototyping instead (if the budget and time allow), as interactive demonstrations can sometimes communicate functionality more effectively than extensive written explanations.

Figure 1.6 – Dropdown use case

Here’s an alternate version of the tab variation case:

Figure 1.7 – Tab variation case

• Highlight nice-to-have features: While agile workflows prioritize speed, it’s sometimes beneficial to design beyond the Minimum Viable Product (MVP), which is the simplest version of a product that includes only the core features needed to satisfy early users and gather feedback for future improvements, to showcase the broader idea. Use visually distinct elements to denote nice-to-have parts (for example, a feature such as Search).

This approach improves communication with stakeholders, ensuring they see the complete vision and grasp your intent more effectively.

Figure 1.8 – Nice-to-have cards in a design

• Ticket cards (Jira plugin for Figma): Link your Figma designs directly with project management tools such as Jira by adding ticket cards. These cards can display responsible team members and task statuses right in Figma.

Figure 1.9 – Ticket card for new design project

• Flow headings: Include flow headings to outline logical sections of your design. This helps collaborators and developers understand the structure and implement the design as cohesive, story-driven blocks for quicker development.

Figure 1.10 – Flow heading for a new section in a design file

All of these annotations are crucial for every Figma handoff. Remember, a good design file isn’t just about frames with designs; it’s about effectively transferring the right information from design to development, product owners, testers, and other stakeholders involved in the implementation process.

Loom video walk-through

Record videos for everything! Loom is an incredible tool—you just click and record, and your video is automatically uploaded to the cloud. You can then paste the link directly into Figma. Everything is clearly explained, and anyone can revisit the video as needed.

I shared my workflow on LinkedIn:

1. Record a short Loom video explaining the feedback or a new feature idea. I include examples and walk through our app directly in the video.
2. Loom AI automatically generates a transcript of the video.
3. I use the transcript as input for ChatGPT, paired with a custom prompt tailored to our Jira ticket structure (description, requirements, acceptance criteria, etc.).
4. Within seconds, I have a complete Jira ticket ready to go! I add the Loom video link to the ticket for reference, ensuring clarity for designers.

Figure 1.11 – Loom video gallery

Organize your video library systematically to prevent chaos. Use a consistent naming convention, such as YYYY - Area - Initiative Name, for all your recordings (for example, 2025 - Onboarding - Mobile App Redesign). This makes videos easily searchable both in Loom and when referenced in tickets. Create a dedicated page or section in your Figma file specifically for important videos and links. Developers and team members are often pressed for time and want everything served in one convenient location rather than hunting through multiple tools. Having a Video Library or Key Resources page in your Figma file with all relevant Loom links ensures that critical context is always accessible without requiring people to search through chat histories or project management tools.

Picture this: you’ve just finished what you believe is your best design yet. Every pixel is perfectly placed, the user flow is seamless, and the visual hierarchy guides users effortlessly through the experience. You hand it off to the development team, expecting them to be as excited as you are. Instead, you’re met with concerns about API limitations, performance issues, or existing system constraints you never knew existed. Suddenly, your beautiful design needs significant compromises, or worse, a complete rethink. This disconnect between design vision and technical reality is one of the most common sources of friction in product teams.

What’s the problem?

Designers often lack awareness of technical limitations, which can lead to missing details for developers. While designers excel at understanding user needs and business goals, gaps in technical knowledge can create challenges. Legacy tech debt, platform constraints, and performance considerations are often overlooked. Without early collaboration, these issues surface late in development, causing costly revisions.

How to fix it

The following steps will help designers to know and understand the technical limitations early in the design process, ensuring that the collaboration will be faster and smoother for both sides:

• Involve developers early: Bring developers into the design process from the start to identify technical constraints before they become blockers.
• Assign a developer partner: Designate a developer as a support resource for the project to provide real-time technical insights.
• Use Figma’s spotlight feature: Leverage quick, real-time calls to align on design feasibility without unnecessary scheduling overhead.
• Clarify technical needs: Ask developers for input on system limitations, reusable components, and performance considerations upfront.
• Document technical constraints: Keep a shared space where designers, developers, and product managers can reference key limitations and best practices to avoid repetitive issues.
• Leverage AI tools for technical understanding: When in doubt, leverage AI tools that are fantastic at understanding technological limitations and try to understand why something can/cannot be done. There is no need to become a code expert, but becoming a design expert requires an understanding of code limitations.

By fostering an open dialogue between design and development, teams can avoid misalignment, reduce unnecessary rework, and build products more efficiently.

You know the feeling. You’ve just finished explaining the latest design iteration to your development team, they’ve started coding, and then it happens. A stakeholder suggests “just a small change,” or user testing reveals an insight that requires rethinking the entire flow. Meanwhile, your developers are caught in the middle, unsure whether to continue with the current version or wait for the next iteration. What should have been a straightforward development cycle turns into a confusing juggling act where everyone is working on different versions of the same product. Managing design changes effectively isn’t just about version control; it’s about maintaining team sanity and project momentum.

What’s the problem?

Frequent design changes are inevitable in many projects, but they can create confusion and inefficiencies. A major challenge arises when development teams are already working on one version while designers are iterating on a newer one. This leads to uncertainty about what should be implemented, potential rework, and a frustrating experience for both designers and developers. In one project with a large insurance company, we faced this exact issue—multiple design iterations were being worked on simultaneously while the older version was still under development. Developers struggled to build a product that kept evolving beneath them.

How to fix it

To manage continuous design changes effectively, consider these two primary approaches:

• Branching for isolated iterations: This is an advanced feature that should only be used for big, complex projects where multiple people are working simultaneously on the same file. Think of branching like creating a separate workspace where you can experiment without affecting the main file that others are using, for example, if you’re working on a design system component library with multiple designers, or developing a major feature for a large enterprise company where several team members need to contribute simultaneously. When you create a branch, you’re essentially making a copy of the current file where you can make changes safely. Once your changes are finalized and approved, you can merge them back into the main file. This prevents your experimental work or iterations from disrupting the live version that developers or other team members are actively using.

It prevents unnecessary changes from affecting the live version.

Challenges: Requires Figma’s Organization or Enterprise plan; designers may be unfamiliar with branching workflows. To overcome this, consider a developer-led training session on Git-based workflows.

• Versioning for clear change management:
  1. Manually create a version checkpoint before significant updates.
  2. Label versions clearly (for example, Onboarding_Flow_v1.2) to document progress and provide a stable reference.
  3. Use version descriptions to highlight key changes, reducing confusion for developers and stakeholders.

By adopting structured version control and branching techniques, you can reduce confusion, minimize rework, and create a smoother workflow between design and development teams.

How many times have you found yourself staring at a Figma file wondering, “Is this the latest version?” or “What exactly changed since yesterday?” Maybe you’ve been in a meeting where someone references “the version we discussed last week,” but nobody can figure out which one that was. The difference between teams that struggle with version confusion and those that maintain a crystal-clear project history often comes down to understanding when and how to use manual versioning strategically.

What’s the problem?

Many teams underutilize Figma’s versioning features, missing out on its full potential. The tool offers two types of versioning—automatic (autosaves) and manual—but manual versioning, when used strategically, can significantly enhance workflows. However, teams often struggle with knowing when and how to create manual versions, leading to inefficiencies in sharing and collaboration. Without clear guidelines, this powerful feature becomes underused or misapplied, limiting its impact on productivity.

How to fix it

When you decide to create a manual version, it should be at the end of a workflow cycle. This could be when you’re preparing a version to send to stakeholders or clients, or when you’re working in two-week sprints and need to hand off a stable version to development. The exact timing varies across different teams I’ve worked with, but understanding how to create effective versions is more important than the specific timing.

Here is how to create a version in Figma:

1. Click on the arrow next to the filename at the top left of your Figma interface.
2. Select Show version history from the drop-down menu.

Click the + button next to Version history in the right panel. Every version can have a name and description. Let’s talk about naming first. You can use several naming structures to maintain consistency:

• By Milestones: ProjectName_MilestoneName_vX

Example: Dashboard_v1 or Onboarding_Flow_v3

• By Date: ProjectName_YYYY-MM-DD

Example: Onboarding_Flow_2025-01-15

• By Sprint or Release Cycle: ProjectName_SprintX or ProjectName_ReleaseX

Example: Onboarding_Flow_Sprint12 or Onboarding_Flow_Release2.1

• By Stakeholder Review Stage: ProjectName_StakeholderType_Stage_vX

Example: Onboarding_Flow_Review_v1 or Onboarding_Flow_Feedback_v2

Consistency is key—ensure the same structure is used across all your files to avoid confusion.

For descriptions, keep them concise but informative. Use them as a changelog to highlight differences from the previous version. Here’s a quick tip: leverage emojis for clarity:

• ✅ Approved changes
• ➕ Additions
• ❌ Deletions

The following figure showcases the Figma version modal, where you can document and track all changes for future reference, ensuring clarity and seamless collaboration.

Figure 1.12 – Figma new version modal

Once you’ve established versions, you can easily copy the link for a specific version and share it with developers or stakeholders. However, note that older versions are view-only—people can’t comment on them. A workaround for this limitation is duplicating the version into a separate file where comments and edits can continue. Meanwhile, keep the “hard” version as a separate file to maintain a clear record. Just remember to archive or close older versions to prevent an overflow of active files.

Versions that have been handed off to development or stakeholders should never be edited, even though technical workarounds exist. Editing defeats the entire purpose of version control. Once a version is shared, treat it as locked and create a new version for any subsequent changes. This maintains the integrity of your project timeline and ensures everyone is referencing the same stable point in your design history.

There’s nothing quite like the panic that sets in when you realize you might have accidentally shared confidential client work with the wrong people. Or when you discover that your “quick internal mockup” with placeholder text saying “This feature sucks” somehow made its way to a stakeholder presentation. Figma’s sharing settings seem straightforward at first glance, but the devil is in the details. One wrong click on Anyone instead of only people you invite and suddenly your private design exploration is discoverable by anyone online. Getting sharing permissions right isn’t just about security; it’s about maintaining professionalism, protecting sensitive information, and ensuring the right people have the right level of access at the right time.

What’s the problem?

Managing sharing permissions in Figma can become a challenge, particularly when dealing with external collaborators or large teams. Improper settings, such as leaving files open to “anyone,” can lead to unauthorized access, unintentional edits, or even the mishandling of sensitive content. Additionally, using group email addresses for collaboration can limit individual accountability in comments. Without a clear structure for separating internal and external files, informal content can unintentionally reach professional audiences, creating potential embarrassment or confusion.

How to fix it

Figma has a standard level of sharing permissions—not overly complex—but there are a couple of valuable tricks I’ve learned the hard way during my career:

1. If you open the file link to anyone, ensure that the What can they do on View setting and Viewers can copy, share, and export this file options are unchecked. This will save you from unnecessary problems caused by unintended editors accessing the file (trust me, it happened to me!) and provide some guardrails against unauthorized copying of your file by anyone online.
2. Understand Figma’s different invitation levels to manage seats effectively. You can invite people at three different levels: directly to a specific file (most restrictive), to a project (moderate access), or to the entire team (full access). Each level has different implications for your seat count and billing. When sharing with external stakeholders or clients, consider inviting them only to the specific file rather than the entire project or team to maintain better control over access and costs.

There’s more...

For better security, consider adding a password to the file or avoid using Anyone as an access setting altogether. Instead, add specific email addresses. When inviting a large number of people, you can copy and paste multiple email addresses at once, or use group email addresses such as marketing@company.com or figma@company.com. Group access works seamlessly, as Figma doesn’t limit access from the same account being used by multiple people. The only downside is that comments from group accounts won’t display individual names unless explicitly noted.

For Organization and Enterprise plans, you gain access to Activity Logs, providing a detailed overview of who accessed your files and what actions they performed.

Do a regular seats and activities check-in to uncover potential problems. If done regularly, this can take a half hour or less.

Enterprise users also benefit from the Password Protection Required feature, which enforces password use for all shared files—adding an extra layer of security.

Another smart approach is to establish a system where files shared externally, such as with clients or partners, are clearly separated from internal ones. This minimizes the risk of accidentally including informal content in professional files. Let’s be honest—most of us have added memes or jokes in Figma files for team fun at some point. I once experienced the embarrassment of such a file being shared with a client’s C-level executives. Luckily, they found it amusing, but it was a lesson learned! To avoid such situations, I recommend tagging shared files with an emoji and text in the name, such as [🔗 SHARED WITH CLIENT] File Name. This simple step can save you from potential awkwardness in the future.

Figma changed my perspective on design when I realized how deeply it integrates collaboration into the core of the experience. However, many designers still don’t take full advantage of its potential. I’ve mentored numerous young designers who are hesitant to ask for feedback.

“What if someone finds out I’m not that good?” they often ask me. My response is always, “So what?”

Design is fundamentally about solving problems, and humans are naturally better at solving problems together. If we could hunt mammoths as a team, why can’t we share an early Figma file? Here’s the reality: designers aren’t supposed to handle every single edge case of a product. That’s what engineers excel at. Our role is to support and unblock when something is missing or unclear. The design-to-development process isn’t always linear, where design ends and development starts. It’s an ongoing collaboration where feedback becomes your best ally in design.

I frequently tell my team that having them to rely on allows me to work faster. I don’t need everything to be perfect before sharing—it’s through collaboration and early input that we achieve our ultimate goal: building the best possible product.

There are countless ways to foster this collaborative feedback process. While it takes experimentation to find what works best for you, I’ll share a few methods to get you started.

What’s the problem?

Many designers hesitate to fully embrace Figma’s collaborative features, often avoiding feedback due to fear of judgment or exposing their skills. This reluctance hampers the potential of collaborative problem-solving and slows down design progress. The lack of early input leads to delayed iterations and missed opportunities for improvement. Establishing a culture of open and effective feedback is crucial for leveraging Figma’s full potential and creating the best possible products.

How to fix it

Effective communication is crucial for a product’s success. In recent years, the rise of remote teams and increasing workloads have made seamless communication even more critical. Teams must work proactively to ensure clarity and collaboration despite these challenges.

One way of doing this is by sharing feedback through a Slack, Teams, Webex, or other channel. Sometimes, you need feedback from people outside your design team. At Dotidot, for example, we often turn to our automation strategists or performance marketing geeks for their opinions—they align closely with our users’ perspectives and often provide insights smarter than ChatGPT :D.

To streamline this, we created a dedicated Slack channel specifically for design feedback. It’s crucial to make the request as straightforward as possible to keep people engaged over time. Every message should include the following:

• Title of the request.
• Brief description of the problem or assumption.
• Include a video explanation for more complex issues.
• Link to a specific section in Figma (not the entire file).
• Deadline for responses to help them plan their time.
• Mentions of all relevant team members for feedback, along with those who can contribute to the discussion in the thread below.
• Recording of every design critique. Yes, here it is again—Loom. You might think I own the company, given how often I mention it, but I genuinely love the tool. Whenever we have a quick call or live design critique, we always record the session and link it directly in Figma next to the design. This allows designers to focus on the discussion—thinking critically about the design—instead of scrambling to write comments or notes. After the meeting, you can revisit the recording and review specific parts as needed. Loom’s AI-generated chapters make it easy to jump to the sections that matter most.

If you plan a long meeting (though in 99% of cases, long meetings aren’t necessary), consider breaking it into multiple shorter videos instead of one lengthy Loom recording. This approach will help you move faster in the future and make it easier to revisit important points.

By the way, these video recordings also serve as excellent training materials for new team members. They can quickly learn from past challenges or mistakes, significantly speeding up the onboarding process.

Unlock this book’s exclusive benefits now Scan this QR code or go to packtpub.com/unlock, then search this book by name.
Note: Keep your purchase invoice ready before you start.