Ask DN: How do you track small and large design changes?

4 years ago from , Detroit Labs

Something I've been struggling to get a real handle on lately, especially with larger (longer) projects, is keeping the development team informed of changes of all sizes happening throughout development.

While creating new cards for changes is something we do, sometimes quick, small changes can get lost in the sprint. Most recently I tried maintaining a design changelog post I pinned in our team's Slack channel, which contains notes about changes and decisions made throughout the project. Does anyone do something similar, but differently?

Our tools include Slack, Zeplin, JIRA and InVision primarily as a tool to present to clients.


  • Nelson TarucNelson Taruc, almost 4 years ago

    You list JIRA as a tool, but you don't use it for design changes? I'd recommend making EVERY design change (even moving something by one pixel) its own JIRA ticket, and tagged as a bug or enhancement for priority's sake, and estimated (I'm assuming you're an Agile shop).

    Generally, we stop at the screen level, so if a screen has multiple changes, we'll lump those together into one ticket (assuming a dev can knock them all out at the same time).

    In my current job, all our designers have access to JIRA and are trained to write up their own tickets. Then the product owner can build sprints accordingly and prioritize dev vs. design needs.

    Does this make the backlog sort of large? Yeah, but most POs like having a second set of eyes on their products. More importantly, you will never lose track of a ticket as long as it lives in JIRA.

    1 point
    • David Klawitter, almost 4 years ago

      Thanks for responding Nelson. I feel foolish saying it now, but we don't typically track our design work in JIRA or similar (each project team determines what is best for them). We're in the services business, so each of our teams operate independently and to this point have only had a single designer. Processes and tools have differed between teams and it wasn't until this most recent project that this sort of workflow caused significant pain, hence the post. We can certainly do better there.

      0 points
  • Misha Scholte, almost 4 years ago

    Some changes are just destined to get lost in the void. I've learned to accept it.

    But your question is pretty broad. Do you have a specific example? A scenario? What kind of changes are we talking about?

    We basically inform the team on-the-go (we sit next to the developers), but we do not expect them to implement them immediately. We write up an issue in JIRA explaining the desired changes, convince the product owner why we believe the change is absolutely necessary and then hopefully, it will end up in one of the upcoming sprints.

    1 point
    • David Klawitter, almost 4 years ago

      After seeing your response and Nelson's it's clear to me that the answer to my question is quite simply to use JIRA, which isn't where we typically track design. There are a couple of reasons why, but they're probably just excuses to avoid using JIRA.

      0 points