Personally, I'd add as much value as possible by deciding what are more critical discrepancies. Then I'd prioritize for fixing and explaining to the team why they are important. If there are development challenges to fixes, I'd work with the team to find a path forward. Possibly a shorter term fix and longer term plan. The more trust you build with the full team, the more they will trust you in the future and the more involved you can be when there are potential discrepancies.

I had the same problem with a new team I recently joined. They have the old design of our platform in some pages, the actual design in most of the website and new, marketing driven design, in other some.

So, because our clients are very conservative, and they don’t like a lot of changes very quickly, I suggest the devs and the PO’s to catch up to the actual design in the short-midterm. To accomplish this, we must built our design system first. And because we work in agile, we can make improvements very quickly.

Then, we can think to move to a new, fresh design. We have to achieve order.

In the previous team I was we did some things that can help you:

• If you have QAs in your team, they should be your best friends. They can help you mapping all the discrepancies.

• We try to take screenshots of what is live, and share it with the rest of the team and make quick sessions to resolve this.

• We use Figma (but if you use Sketch, it works), and we have two files. A Master (the file the devs should look at and is detached from the design system) and the Explorations file (attached to DS and with a flow section that is an exact copy of what it is on the master). This trying to stop future discrepancies.

• We push for design sprints for focused on consistency with our POs.

One thing I want to try is when the QA team certify a dev project, they take screenshot of it and summit to us on Jira. Then we put the same screenshot on the master file alongside the design. So it gains more visibility for the POs, QAs and devs about discrepancies.

Maybe could be useful.

The developers you're working with need to be considered in your design. They're creatives too with varying skillsets and will have different levels of polish and capability in their work. Front-end may not be their strongest area, so your design process needs to consider this in order to help them achieve the output you're gunning for. It can be a delicate situation to handle when it comes to talking about what people are and aren't capable of, but open, honest and professional discussions need to happen. You'll work better for it - and the end product will be much better for it.

work with the team ... and the more involved you can be ...

+1 on embracing cross-functional design reviews. I find discrepancies tend to happen when there is either a lack of or ineffective communication of the expected design. I would assess what discrepancies there are, and make time to actually sit down with the developer(s) to see what was mis/undercommunicated, to inform could have been better communicated for future reference.