27

How do you give feedback on design implementation to developers?

9 months ago from , Founder and CEO of Flawless App. Designer + Developer

I'd love to understand how other designers are sending feedback on design implementation to developers. Especially, when you're working on mobile apps.

It seems like the overall process of giving feedback on the coded app is quite tedious and time-consuming...

How do you do it now?

Also, would be cool to understand what type of feedback you're usually sharing with the developer.

38 comments

  • Rob WoottenRob Wootten, 9 months ago

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

    26 points
    • , 9 months ago

      Thanks again for the response! And during these quick design review sesions with developer what are you usually looking at? And also, when you're sitting next to developer, are you trying to fix/tweak small things in a real-time?

      2 points
  • Mr FannybatterMr Fannybatter, 9 months ago

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

    12 points
  • Craig RozynskiCraig Rozynski, 9 months ago

    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

    6 points
    • Ahmed Sulajman, 9 months ago

      Thank you so much! That's a very detailed approach to feedback indeed.

      How long does it usually takes to create the document, write all the descriptions and upload appropriate screenshots to Dropbox?

      0 points
  • Mattan IngramMattan Ingram, 9 months ago

    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.

    5 points
    • , 9 months ago

      Wow! That's so cool when you as a designer can fix visual issues in implementation. It's quite rare actually.

      Are you working with web-only products or you have some mobile products as well? And if so how you approach issues if it's a mobile app, for example? Are you fixing some minor visual issues there as well?

      0 points
      • Mattan IngramMattan Ingram, 9 months ago

        Yes primarily web apps, but we do have a React-Native app thats gets built for Android and iOS, so it still uses styling similar to CSS.

        However one issue with this approach is that I am essentially a full-time designer AND the full-time CSS guy. I think tech companies need to dedicate more resources to people who are specifically good at HTML and CSS and can work with designers.

        3 points
  • Joel Van WertJoel Van Wert, 9 months ago

    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!

    4 points
    • , 9 months ago

      That's a very good point indeed. It's much better to use existing tools that developers are familiar with.

      And when you'retaking to them face-to-face are you usually iterating over design implementation in a real time? I mean when you sit with the developer are you tweaking design implementation somehow to test different variations? (like different font size, spacing etc.)

      1 point
  • Kwame Afriyie, 9 months ago

    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.

    3 points
    • Ahmed Sulajman, 9 months ago

      Thank you so much! :) Could you please also elaborate, what sort of feedback are you usually giving to developers?

      0 points
      • Kwame Afriyie, 9 months ago

        Feedback could be around a wide variety of things.

        A good example is spacing issues, is actually a big one because it does not always translate well from zeplin to production.

        2 points
  • Rob WoottenRob Wootten, 9 months ago

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

    3 points
    • , 9 months ago

      Yeah, that's true. But it seems like at least among product companies, 80% of teams are working from the same location. Obviously, it depends on the size of the company and many other factors, but it just seems like a lot of designers are able to walk over the developers' desk and quickly discuss the design implementation.

      1 point
      • James Young, 8 months ago

        I would say that's much less than 80%. In the last 15 years of being a UX person, I've had an onsite development team maybe 3 of those years.

        0 points
  • Nimrod Gavish, 9 months ago

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

    3 points
    • , 9 months ago

      Wow! Thank you so much for such a detailed overview of the process. It really helps a lot.

      You've mentioned that you're using market.io but just for capturing videos/screenshots.

      It seems like they have the ability to create issue/card/etc directly within the tools the team is using (like Trello, Asana etc.). But you prefer to make everything in google spreadsheet if I understood correctly.

      Do you think it's less flexible to us the automatic creation of these issues or it's just a process that you have in your team?

      1 point
      • Nimrod Gavish, 8 months ago

        I find the google spreadsheet super easy to use and available and accessible for everyone

        0 points
  • Kyle DucharmeKyle Ducharme, 8 months ago

    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.

    2 points
  • Robbie Sherrard, 8 months ago

    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.

    2 points
  • Ramiro RuizRamiro Ruiz, 9 months ago

    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.

    2 points
    • , 9 months ago

      Thank you so much! Are you using Airtable for something else in your team or just for Design Reviews?

      Also, by an "ideal look" column, I assume you mean the reference or design that was provided to the developer, right?

      0 points
      • Ramiro RuizRamiro Ruiz, 8 months ago

        Right now just for reviews, I have a personal table just to keep track of my to-dos. Yes, the “ideal look” column can be the image of the original design or what I generally do is make a screenshot after I apply the “advised solution” in the inspector (is mostly about adding or changing some CSS rules).

        0 points
  • Andrew C, 9 months ago

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

    2 points
  • Rob WoottenRob Wootten, 9 months ago

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

    1 point
  • Jason FestaJason Festa, 9 months ago

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

    1 point
    • , 9 months ago

      Jason, thank you so much! And what type of feedback are you usually sending to the developer?

      0 points
  • Chris KeithChris Keith, 9 months ago

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

    1 point
    • Ahmed Sulajman, 8 months ago

      Thank you, Chris! Are you using Skitch on your mac to comment on the screenshot or you're using it right on iPhone to make all the annotations there?

      0 points
      • Chris KeithChris Keith, 8 months ago

        I do all annotation on desktop. I use QuickTime capture to keep a mirrored version of my iPhone screen readily available to copy screenshots

        0 points
  • CGR MattijsCGR Mattijs, 8 months ago

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

    1 point
  • Philip A, 8 months ago

    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.

    1 point
  • Hamish TaplinHamish Taplin, 8 months ago

    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.

    0 points
  • Kip HolcombKip Holcomb, 8 months ago

    I make the minor tweaks myself and submit pull requests to save tons of back-and-forth with them.

    0 points