Generally a dev and a designer will sketch out solutions together, and reconcile their ideas with the existing design system (where possible). After this is done they write JIRA tickets. The designer will attach any Zeplin links to a keylined (spacing, font-size, variables, etc) design that matches our front-end system.
Developer does their thang. If problems arise they sketch things out or increase scope (if scoping down doesn't provide a satisfactory outcome). Developer loops the designer in w a demo or link to staging to QA the thing and the ticket is closed.
Zeplin is useful for me because I can see when new work is being posted so I can make sure the designers are collaborating and being consistent. Generally the Zeplin file is the thing that's getting built (rather than a hypothetical blue sky flow in InVision or Sketch). That's our "API" of sorts between everyone.
We also have the ability to write usability citations to people who are willfully doing short term fixes against a deadline. As a design director this was very helpful. This lets them do the hack, finish the next project, and then return. The kicker being they actually can't start any new projects or create any more usability citations before their squad can break new ground. This has been very seldom used since the culture shifted towards usability and testing. At the beginning though it helped the PMs know how to make decisions when sales and CS may be breathing down their neck for a new feature (a performance payoff for their team).
Generally a dev and a designer will sketch out solutions together, and reconcile their ideas with the existing design system (where possible). After this is done they write JIRA tickets. The designer will attach any Zeplin links to a keylined (spacing, font-size, variables, etc) design that matches our front-end system.
Developer does their thang. If problems arise they sketch things out or increase scope (if scoping down doesn't provide a satisfactory outcome). Developer loops the designer in w a demo or link to staging to QA the thing and the ticket is closed.
Zeplin is useful for me because I can see when new work is being posted so I can make sure the designers are collaborating and being consistent. Generally the Zeplin file is the thing that's getting built (rather than a hypothetical blue sky flow in InVision or Sketch). That's our "API" of sorts between everyone.
We also have the ability to write usability citations to people who are willfully doing short term fixes against a deadline. As a design director this was very helpful. This lets them do the hack, finish the next project, and then return. The kicker being they actually can't start any new projects or create any more usability citations before their squad can break new ground. This has been very seldom used since the culture shifted towards usability and testing. At the beginning though it helped the PMs know how to make decisions when sales and CS may be breathing down their neck for a new feature (a performance payoff for their team).