I make a strong coffee/tea, and with the mug in hand walk into the part of the office where developers build their nests. Those of them that notice me take a deep breath and turn their gaze away, hoping I did not arrive with something for them specifically. As I move by their desks, I look for the one/team responsible for the project in question. I take a chair, sit down and start with "there is a fuckup".

First I ask "Why?". Then I ask "How long?"

Then I say "Ok, I'm going to put it on the to-do list with the proper priority. Let me know how's it going".

And after a while, I get a ping on slack that it's done.

Or one of them comes by my desk and says that it can't be done. At that point, we start the Kove'noth ritual, which is standing in the middle of the developers part of the office and scream what the problem is. Devs are very competitive and nothing brings them more joy than being able to solve a problem deemed unsolvable by another dev.

This system haven't failed me yet.

Our team manages everything in Trello. I always, always include annotated screenshots for UI fixes. I’ll use Sketch or Skitch to mark them up and provide context. If the fix is motion or animation-related I’ll include a gif or mp4.

In both instances I’ll show the “current” and “desired” states side by side with highly specific directives that are actionable (this is key): “increase this margin by 8pt.” Or “this element should be vertically centered between these two elements.”

The devs I work with consistently thank me for being painfully specific and including annotated visuals, even for simple fixes. The slight bit of extra time I spend to create more detailed tickets saves a ton of time overall because the engineers have all the detail they need without any further back and forth.

We use Jira along with Marker (https://www.marker.io) just drawing arrows showing what the problem is. If its a motion related one, record it with something like Kap (https://getkap.co/) to get a movie file

I put it into Pivotal (the worst project management software I have dealt with so far) and tag it as "UI" and "Bug", and then I assign it to myself because I'm the only CSS person at the company.

Then I passively aggressively guilt trip myself into fixing small UI bugs because merging multiple PRs is sometimes more satisfying than working on a big one that takes a couple of weeks.

I used to use Airtable or Google sheets to record all of the issues. Within the sheet, I'd have multiple columns, which included:

• Priority (P1, P2, P3)
• Details (usually the CSS changes with some notes)
• The page URL
• Screenshot of the issue on the web page (would often annotate using Skitch or Annotate)
• Sometimes would take a screenshot of the Artboard or refer back to InVision.

After creating this, I'd either put this into Jira or work with the engineer from the spreadsheet directly. I've also done the whole "awkwardly sit over an engineer's shoulder for hours" and go pixel by pixel. I often find this to be nice and uncomfortable :)

The problem I usually faced was design QA was never "official" or viewed as important. Because of this (often times) all of the bugs I'd record would end up never getting fixed - womp :(

This frustrated me so much that I built a tool to help solve this problem for designers. You can check it out/try it for free here: www.toyboxsystems.com - would love to hear your thoughts!

At Futuramo, we created a tool specifically to solve this problem, called Futuramo Visual Tickets Futuramo Visual Tickets. It's free up to three users, so just check it out and see, if this works for you. As the name implies it's mainly visual and we use it in-house to develop software products. Hope I could help.

In the past we used BugHerd to capture screenshots of the error. This help use try to recreate and locate the bug.

Other times was the client created a very long spreadsheet, which then prioritized what they care about the most. Once they did they we moved them into Jira.

Recently we started using user voice to capture bugs and feature requests.

Hi Dana, We have an online review and approval tool in Beta, called MediaMarkup, see: www.mediamarkup.com This could be used to collaborate on uploaded screenshots or pre-recorded videos, it supports, PDF, images and video files. Please feel free to signup and try it. Mark

We are working on this at usepastel.com - key idea is that real-time visual feedback needs to be on the actual UI in the browser

I work in a rather large company, and we work in feature teams. So if I'm in our test version of the app (which will have updates before the public version) and it's not our feature or a team close to me, I give feedback through the app. We have a shake to give feedback with a screenshot that you can draw on - That gets turned into JIRA tickets for the right team. If it's a team I'm close with, I usually walk by, tell the situation and Slack them a screenshot. If it's my team, I mention it to the team, then create a JIRA ticket with the appropriate link to the screen if it's a design thing (we use Abstract). If it's a bug, it either gets picked up because it's critical or turned into a JIRA ticket. We have weekly "small fix" sessions where a lot of these tickets get picked up. I've recently learned how to do copy changes myself so now I can help out with some things :D

Where I work, our UI/layout related tickets are normally separated from more UX/functionality tickets. From a process standpoint, the first batch of visual layout/UI related issues are typically flagged by our designers during a 'creative review' pass that they do, before it goes into QA–from there, the UX/feature stuff get flagged. Although they're filed 'separately', both design-dev (and QA) have full visibility on these issues to avoid duplicates and overlaps.

In terms of where they live, they currently get logged within our project management platform.

Loom video the issue then create an outline or todo of what needs to happen or what is the issue. If it's very confusing, have a google hangout call.

If it's a critical bug it gets prioritized immediately and gets taken now or in the next sprint. If the bug is something minor we add it to our polish spreadsheet. During sprint planning, we like to add a few polish items into the sprint that are small enough to squeeze in.

If I remember correctly, Figma at the beginning of 2018 devoted a full week or two to bugs and fixes. I have seen my own team struggle with priorities between quarters and I feel like not spinning wheels and doing something productive is a good thing to keep in mind.

Hey, Dana!

I've asked a similar question a while ago. Maybe you'll find some interesting approaches there as well :)

It seems like the problem of communicating the feedback back to developers is quite common across organisations of different size.

Ideally UI issues and bugs are being tracked in the tool devs are already using for dev work. Github for example. That way everybody's in the loop for both dev and UX issues.

I am interested in this too!