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?
Note: we're definitely not fully agile, but we're building towards it.
Our first approach resulted in designs deviating from mockups. Our second approach doesn't feel agile or correct.
We originally would provide abstract links and tell the developers to match it as closely as possible
Here's a sample abstract link: https://app.abstract.com/share/aaec8bba-f473-4f64-96e7-bff41c70ff8a?mode=design&selected=root-0D96514D-DEEB-4B05-A00B-4EEB38A353A3
If you click the inspect tab, you can see the spacing between all the elements.
Issues with first approach:
- The developers didn't have a "UI checklist" to follow. They would end up disregarding the abstract design half way through and just wing it. This led to designs that did not match the provided abstracts.
- The abstract design doesn't communicate responsiveness — like which elements are pinned to the right edge of the page, or which elements stretch as the viewport gets larger. stretch with the wouldn't fully go through every spacing requirement.
- Tedious to update abstract links with design changes. As a result, instead of updating the abstract link, we'd just put "adjustment notes" in the ticket. Since the abstracts were often outdated, the developers couldn't confidently refer to them for spacing and other styling.
To ensure the developers matched the designs, we started writing out every single design requirement as its own stand alone ticket.
For example, here are some tickets we've written with thee new system:
- "style the button as follows"
- "make the button spacing as follows"
- "pin the button to the left side of the viewport"
This completely solved our issues with the design not
Issues with second approach:
- Doesn't fit with the User Story method of ticketing (how can we keep track of 30 design tickets that's related to a single user story?)
- Tedious to write so many tickets
- Clutters up the Kanban board. QA has way too many tickets to review (and is mostly a waste of time, because I feel like QA should be testing functionality, not design)
So what would you suggest?
"They would end up disregarding the abstract design half way through and just wing it."happened. Was there a technical reason that they just decided to not do what they were asked to do? My company follows your "first approach" exactly (albeit with a different tool) and we don't have this issue.