Four thoughts:

1. 
   

   With Figma’s new ability to push individual components as updates, you can document changes if you make the screens themselves individual components. This is a bit of a mind-bender but is one potential way of tracking these frame changes.

   
   


2. 
   

   Not a plugin but something like Zeplin would let you document changes fairly easily. But the downside is that takes you outside the Figma ecosystem and becomes two things to manage.

   
   


3. 
   

   Rather than give devs access to a potentially changing document, duplicate your frames to a new file and label that a design freeze version that is locked and should be then off limits to designers after that point.

   
   


4. 
   

   If it does change midway through a sprint, what’s wrong with the devs just updating it? Are you really making changes that drastic during a sprint? Maybe the change is not a plugin but a change in policy where design is subject to change until X days into a sprint.

   
   

If it were up to me, I’d recommend option 3+4 (it’s what I do), 1 and then 2. You’d hope at some point that the dev + design process is more collaborative vs. confrontational.

Thanks for the reply. And all of your thoughts are correct. We are not changing things very drastically, if at all. I was hoping for a way to create a CYA for us so that the blame game can’t happen. We have come a long way with our teams and collaboration. We already have a process in place similar to what you suggest in #3, and we are doing our best to communicate any changes with the team, if and when things happen. I think the next step is to create a frame status to just be an extra gate for designers to make sure that they are communicating any changes when a design has a “ready for dev” type of status.

there is also an request for something like this here: See version history per layer/element

would be SO helpful to see the actual changes, we are also having issues because the lack of.