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?

Question

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.

First Approach

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:

1. 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.
2. 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.
3. 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.

Second Approach

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:

1. "style the button as follows"
2. "make the button spacing as follows"
3. "pin the button to the left side of the viewport"

This completely solved our issues with the design not

Issues with second approach:

1. 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?)
2. Tedious to write so many tickets
3. 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?

Answer 1

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.

Answer 2

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.

Answer 3

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.