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?

  • 3
    Having your UX process separate from the Scrum Team is an agile anti-pattern. So are "stories" like move this widget 1 pixel to the left. You might want to rethink your approach.
    – Todd A. Jacobs
    Jul 15, 2020 at 16:31
  • 1
    Did you try something like the second approach, but instead of raising a tonne of tickets use bullet points in a single ticket? Where possible, tickets should represent separate tasks. If it doesn't make sense with your workflow to first add the button, then later for someone else to pin it to the left side of the viewport, then you have no business raising two tickets. Jul 15, 2020 at 17:51
  • 2
    Or to put it another way: if you need to communicate 10 pieces of information to a developer in order for them to do the job right, there are many ways to do that other than raising 10 tickets :-) Jul 15, 2020 at 17:53
  • 1
    One thing I've seen that isn't mentioned here: there are design mockup tools you can use to make responsive mockups without writing code. That might be an incremental improvement over using photoshop. (I am not very familiar with such tools, or I'd make an answer.) Jul 15, 2020 at 18:24
  • 1
    I'm confused why "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. Jul 15, 2020 at 19:28

3 Answers 3


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.

  • "the platform you are developing in builds a whole additional abstraction on top of the HTML/CSS layer" or even, the HTML/CSS layer builds in a whole additional abstraction beyond what the designer has accounted for. For example, developers are the pedantic sorts of people who ask questions designers hate like, "OK, so you've told me all the spacings in pixels, so what if the viewport isn't the size you think it should be?" This is why CSS pixels aren't really pixels any more: the developers realised they were just being too pedantic! Jul 15, 2020 at 18:01
  • And yes, for viewport size you can say it's just something that anyone designing for the web absolutely needs to know about and decide for themselves as part of the design. But identifying annoying edge cases is a core part of a developer's job: less core for graphic designers. So, if it's not viewport size then your developer will find something. Jul 15, 2020 at 18:04
  • 1
    I think your comments re-enforce the challenge of design and development being two separate efforts. The developer shouldn't be trying to throw a wrench in for the designer and the designers shouldn't be throwing their art over the wall to development. Together, they can use their knowledge and skills to come up with a great solution.
    – Daniel
    Jul 15, 2020 at 20:11
  • 1
    Agreed: rather than throwing wrenches you want a collaborative process where you can ask a question at the earliest opportunity, which prevents time being wasted working on bad assumptions. So in the case of viewport and spacing, the minute the designer draws a big rectangle and marks it it "800x600 px", someone can say "OK, about that...", before the designer spends an afternoon figuring out how many pixels to allow for each compontent. Jul 15, 2020 at 20:16
  • Please allow me to contribute some materials to help you enlarge your soapbox. Jul 15, 2020 at 23:20

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.


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.
  • 3
    I actually think people are over-eager to skip (3) due to trust. As the developer on the ticket, I want people setting requirements to "trust, but verify", and a design coming from outside the dev team is a requirement. The designer knows what they meant, as well as what made it into the design spec, so I always want the person who wrote the spec to review the result if possible. Likewise I will if possible consult the person who reports a bug to confirm that the fix addresses their problem, not just what they wrote, or what I thought they meant by what they wrote. Jul 15, 2020 at 17:46
  • @SteveJessop, I added that parenthetical remark because those reviews could be seen as something that causes delays. But I agree with your comment that you should want to have those reviews. Jul 16, 2020 at 5:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.