How should we hand-off and ticket UI designs to the devs to ensure the developed design matches the provided UI mockups, while still being agile?

Agile thrives on collaboration between people, rather than building walls around each team and throwing things over it.

The ideal situation would be that the designers work in the same team as the developers and create their designs as the software is being developed, with the technology used to deploy the designs. This way, the designer is the one who actually implements the design.

If that is not achievable and the designers must remain in a distinct team from the developers, then I would go for a variant of your first approach:

1. The designers provide an abstract link showing the design for a story/feature. This is delivered as late as they can responsibly manage, preferably just before the developer needs the design to complete the implementation.
2. Before starting implementing the design, the developer sits together with the designer to discuss the design (what aspects could not be captured in the abstract link, which parts must be pixel-perfect and where does the developer have some slack to deviate, etc.)
3. The work is not completed until the designer confirms that the design has been implemented as intended. (as trust grows, this could be skipped)

This addresses the issues of how you did the approach in the following way:

• By making the design as late as possible, the number of changes between when the design is made and when it gets implemented should be limited. That makes that there is less frequently a need to update an abstract design.
• The review step should catch the points where the developer deviates from the design without involving the designer.

Let me challenge the frame of your question a bit:

Why do you have such specific requirements that change for every ticket?

Is it really necessary to have different margins between buttons on different pages? Is it necessary to have different styles for things on different pages? Isn't the job of a designer to create a recognizable style for the whole application?

Your designer should have a style guideline for the whole application. There they can define things like default margins, common padding sizes, image sizes, how buttons in general look like in your app. Which colors to use when.

Their own work should not consist of feeling it should be 7px today, because it's a Monday and it looks nice. It should be 7px because the style guide says that 7px is how this application does it.

So all you have to do is use the abstracts and the design guideline in the tickets. If you have a "Definition of Done" you could even put it there, so you don't need to spell it out in every ticket.

The point is: if you have changing requirements in every ticket, I'm sorry, yes you have to spell them out. But you should not have changing requirements, unless you want your app to look like a crazy 13 year old on their first espresso. Good design has rules. Write them down and pass them to your design implementers, so they can play by the rules.

I've seen this happen with design so many times. It's a structural problem with how people and teams are organized. Now, I feel like I should say that cross-functional teams are not required to be agile. Scrum does require them, but I don't see that you are specifically using Scrum. That said, the structure of "Design team creates some design and the dev team implements" it is directly leading to what you have here.

When you have a team of designers that are creating a design, there are two ways they can go. First, they can use a tool like photoshop that renders graphics in such a different way than the web that trying to perfectly translate between them is a joke. Second, you can use a tool like this in which the designer is all but building an HTML/CSS web page.

Then, the developers try building it, but the tool has obfuscated a lot of the HTML/CSS details in some weird attempt to shield the designers from scary code.

The simple solution, designers should build the HTML/CSS part of the app and be done with it. If they can do what you linked, they can build the HTML and CSS presentation. It'll be even easier if the designers and developers are working hand-in-hand in the same team.

A few quick caveats:

1. a common excuse I've heard is that it's too technical. Sorry, but I have to call BS. A fine artist is an expert in the properties of graphite and paint. A musician understands how their instrument is constructed and how it functions. It's just a medium and the graphic designer needs to understand the medium they are working in.

2. that said, there may be ramp-up time. I highly suggest some pair programming to build the skill (and the expert should be the observer/helper, not the doer)

3. another possibility that would actually invalidate my whole answer is that the platform you are developing in builds a whole additional abstraction on top of the HTML/CSS layer so that even though it all turns into that in the end, you can't actually enter the HTML/CSS. I've seen this plenty of times with CMS's. These can take some solutions far more creative than what you'll get on a Q&A board and, frankly, probably deserve a serious conversation about what that framework is bringing to the table for you. Generally though, choosing to use an abstraction like that works best when you are designing strictly within the pre-set bounds of that framework.