I walk over to their desks and say "Hey, do you have a minute to review the UI?"

I walk over like https://youtu.be/Vhh_GeBPOhs , and then have a conversation.

I share a Google Sheet.

I also mark up screenshots, save them to a Project/Feedback folder, and Dropbox link to it in the spreadsheet when needed.

Update: Everyone's using JIRA these days, I've been using that more often. Also had a good experience using https://app.pageproofer.com

We are creating a google spreadsheet with all the issues we found. Each issue gets few columns to be filled:

• Area in the product - our features are usually affecting few places in the product, sometimes these places are owned by different developers so this arrangement is more effective.

• Priority (P1, P2, P3) - very important in order to be able to release without finishing everything

• Description - explaining the issue, current behavior, expected behavior, explaining how to recreate the issue.

• Screenshot of the issue / Video in case it’s a flow that needs to be fixed (we paste links we capture with marker.io / loom)

• Type - Server side / Front end (When its not clear I leave blank for the Dev team to fill)

• Status - Open, In progress, Ready for QA

For the columns of area, priority, type and status I add the predefined values as drop down options so it will be possible to filter the list (all open issues, all issues in server etc)

When all blockers (P1s) and P2s are fixed we usually release and all the leftovers, the P3 we move to JIRA issues.

We find this workflow good and efficient for the whole team. Sometimes few designers are involved in the UX QA process, in this case we also add a column for the name of the designers who reported the issue in case a developer needs a further info.

Hope that helps :)

Realizing now that not all designers have the luxury of being co-located with their dev team.

Ask the engineers and team what the best way to provide feedback to them is....then do that or better yet, work together on something that works for both parties!

Your engineering team is already using Git Issues, Pivotal Tracker, Trello, or something along those lines to fix issues or bugs with the rollout of a feature. They may also be doing face-to-face review sessions. I always find it best to put design feedback directly into a format they are familiar with. Putting feedback into your engineering teams tool is also a great way to keep track of your requests. I also go talk to them face-to-face if there is any confusion or issues with what I am requesting from them so we can work through it together.

Best of luck!

I fix the CSS problems and ask the devs to merge or rebase my changes.

But really it depends on the issue. I often fix things myself, but it is simply a misuse of a standard component from our design system I will point the dev to the documentation and show them where it differs to hopefully prevent the issue from occurring again and make the dev better at using the system.

Right now I am giving the feedback through Slack, Trello or Asana.

With Trello or Asana, I can give the developers feedback and set them as tasks. Then we discuss each piece of feedback as the developer works through them.

Our "Experience Team" is made up of myself (design) and two front-end developers, and we oversee all user-facing features with the remainder of the dev team (~20) focused on the foundation of the product, admin features, etc.

Our team uses Basecamp for requirements and Marvel for hi-fi mocks, and these are developed off of up until the devs are at the ~90% mark. Then, the developer and I get on a Zoom call (we're 100% remote) and do CSS/JS pairing to put the final polish on the product, tackle interactions, etc.

This process has helped a TON to save time, cut down on context switching, and ensure that the product is consistent & polished, regardless of which dev is working on it.

I'm a front-end developer, and one of my favorite things for feedback are tools like BugHerd, Usersnap, or DebugMe. Not 100% sure they'd work for mobile app development, but for in-browser QA stuff, it's the best possible thing to avoid the constant back-and-forth.

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).

When I'm not implementing my designs I do Design reviews where I document anything that needs to be fixed on Airtable where I have columns for: title, type (back / front-end), priority, status, assigned person, section, page, view (desktop/mobile), long description, advised solution (mostly CSS code that fixes the problem), current look (screenshot), ideal look (screenshot), days old (days that has passed since).

And its been working great, very clear and faster for both parties to document and fix any problem.

Tried usepastel.com, works great but costs money. Therefore switched to the old good google spreadsheet :)

They ask ME for feedback. We do "bench tests" and it's a standard process. After a dev finishes a task, they ask me to use it and point things out that need fixing. It's generally for the bigger things as I do any minor UI/CSS related fixes myself. It works well.

Wow, some amazing comments here.

It’s also about building a strong and trustworthy relationship with your team. If you can maintain a positive attitude in a team based environment your 80% there.

Michael Scott, “We’re not in the paper business, we’re in the people business.”

We manage everything in Trello. I will typically use an app called Skitch to draw arrows, lines and text on screenshots for maximum clarity.

I use Trello right now but shifting to Git Issues as some developers express pain of having to learn Trello's card UI.

I review the PR in Github and leave comments as I would also do for a code review. I can also pull the branch and make changes myself. Luckily, I sit next to them so can also provide feedback in person but I think everyone finds it helpful to have feedback documented in a PR so they don't miss anything.