28

How do you share UI issues and bugs with your developer or development team?

6 months ago from , ux/ui designer

Whether it be just an in-person conversation, put it straight into a project tracking software like Jira, making a spreadsheet or list of some sort - what have you found works best for you and/or your team?

I'm currently in the more spreadsheet/list zone as I work with remote development team, and it has its obvious flaws with effective communication. So looking for any recommendations on processes or solutions!

(I realize shooting for "pixel perfect" is an arguably antiquated term and we should concentrate on the experience more so - but first cuts are rarely flawless as we're all humans doing our best.)

34 comments

  • Selv Grimm, 6 months ago

    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.

    46 points
  • Chris KeithChris Keith, 6 months ago

    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.

    10 points
    • Scott ThomasScott Thomas, 6 months ago

      how do you break your tickets down?

      1. Overall Summary what needs changed
      2. Reference page
      3. Design Reference
      4. Templates/models that are effected as well
      5. Task list with detailed changes like (Increase the padding on .class to 1em)
      6. Annotated Screenshot
      0 points
      • Chris KeithChris Keith, 6 months ago

        That's about right. Love that you called out the "templates/models" point. Many times a UI fix affects a component that is used system-wide, so it's super important that communicate that.

        0 points
  • Jamie LovelaceJamie Lovelace, 6 months ago

    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

    8 points
  • Mattan IngramMattan Ingram, 6 months ago

    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.

    2 points
    • Aaron Wears Many HatsAaron Wears Many Hats, 6 months ago

      +1 for the pain that is using Pivotal. What a joke.

      Do you guys get lumped with using Time Doctor as well?

      0 points
      • Mattan IngramMattan Ingram, 6 months ago

        Fortunately no, we have a good culture about trusting employees and everyone is remote so time tracking gets awkward. I don’t get companies that feel like it’s a good idea to track employees like that.

        1 point
        • Aaron Wears Many HatsAaron Wears Many Hats, 6 months ago

          I know right. Its probably the single biggest issue I have with my current situation.

          0 points
          • Arthur Simon, 6 months ago

            I always ask if the company tracks employee time in the interview phase. If they tell or imply that they do, I lose interest working for that company.

            0 points
  • Kip HolcombKip Holcomb, 6 months ago

    Make a ticket or code the fix myself and make a pull request. If it got through the Design QA phase, I'm to blame anyway.

    2 points
  • Scott ThomasScott Thomas, 6 months ago

    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.

    1 point
    • Dana Smith, 6 months ago

      Curious on why you stopped using BugHerd?

      And cool, I always thought of UserVoice as a more end-user facing thing, I'll have to relook at that too.

      1 point
  • Brendan Mahony, 6 months ago

    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!

    1 point
    • , 6 months ago

      You described some of my same issues exactly! I see Toybox has some Jira and GitHub integrations which seems key - so dev team friends don't have to look anywhere new for these items.

      I'll def have to check it out!

      1 point
      • Brendan Mahony, 6 months ago

        Amazing! And yes - we have integrations with several Project Management tools (and Slack!) to:

        • Help you save time by not going back and forth between the site you're QA'ing and the PM tool you're logging bugs in.
        • Make sure the engineers you're working with don't have to search in Slack, email, spreadsheets etc. for all the different bugs :)

        An idea I'm also interested in is whether having an "official tool" (rather than a spreadsheet) for design QA will help give it the clout it deserves within the product development process. Let me know if you have any thoughts about that!

        Lastly, if you get a chance to try it out - I'd really love to hear your feedback!

        0 points
  • Mikolaj Dunikowski, 6 months ago

    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.

    1 point
  • Ahmed Sulajman, 6 months ago

    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.

    0 points
    • , 6 months ago

      I tried to see if this was asked before and couldn't find! Thanks for the link

      0 points
  • Toby NegeleToby Negele, 6 months ago

    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.

    0 points
  • Andrew Acree, 6 months ago

    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.

    0 points
  • Rey AlejandroRey Alejandro, 6 months ago

    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.

    0 points
  • Anneliese HAnneliese H, 6 months ago

    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.

    0 points
  • Noukka SigneNoukka Signe, 6 months ago

    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

    0 points
  • Aloke Pillai, 6 months ago

    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

    0 points
  • Mark RedmanMark Redman, 5 months ago

    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

    0 points
  • Andrei Urse, 6 months ago

    I am interested in this too!

    0 points