A few direct suggestions:

1. Discuss this issue with your team. This is a team process, and they should have some input on how you work as a collective.

2. For small changes, work out a process with your team that allows you to review a build before it goes out. You should have the ability to hold a release back if you don't think it's ready. Document anything you'd like fixed, prioritize it as a team, and focus on a few things at once. Be flexible.

3. Larger changes should not come as a surprise to your developers. Get them engaged in the feedback and your rationale before you run off making decisions on your own. This way, you build trust and help to maintain focus on important UX issues for your team.

Lastly: tools, frameworks, and process will never trump a good relationship with your team. Making collectively agreed upon design decisions via communication is your most important job. The little details that annoy you will be much easier to address if your team trusts you and your process is focused.

What I am about to suggest might not work for you, but I will explain how we deal with it.

As designers we observed the problem you describe.

Instead of just delivering static mockups, we have changed some of our processes entirely to a) include front-end development template delivery (for web) b) have access to the native codebase.

If you want to change the spelling of a word, it doesn't make sense to go send an e-mail about it. Just change it in code and send it out for approval.

This way the design change is embedded in the single source of truth (i.e. the app code) and it can't be missed.

I realize this involves designers starting to code and it might not work for every type of change, nor do we want any (starting) designer to have access to any codebase (that has to be stable), but in general I think designers, especially senior UI designers, need to move closer to development sometimes so just avoid some of these communication problems entirely.

Sprint demos. A squads dev lead, pm and design (or a combo of these, but ideally all) need to show their work every week. You critique and write polish tickets in JIRA for them. Then at the next demo for this project the changes that happened or didn’t happen are apparent and able to be discussed as a team.

This keeps feedback mostly about what you’re actually releasing (design mockups are useful but always a best guess as to what the future will be), it puts the team through the fire together and builds camaraderie, and it keeps decisions visible.

There’s a few things you need to enable demos: agile and OKRs, a focus on outcomes and not release output (if a feature isn’t done and you need extra time that’s a success not a failure), be comfortable having dev and pm design alongside you (this is agile btw), and you need to structure direct feedback so it isn’t just a barrage of negativity. I like to use the positive/negative/questions/ideas framework to structure feedback.

Hi Jan,

Here in at our Team we work with Trello but the issue is the same. As a designer I want to communicate to my dev in a way that he's going to listen to it and do the fix, especially if it's an easy one like copy/change an illustration/new style for a button etc etc.

For your developer to see it and listen to it, I think the best place to in his Github via github issues. I use www.marker.io to capture a screenshot, annotate it and create in 1-click a Trello card ( you're going to do a github issue ).

Your dev will see that issue with a clear screenshot, the url of the page where you want to make the change, some browser information and you can even attach a new design if you want.

I think that's the easiest way to be listened by your devs if you can't fix these small glitches yourself.

Also, I may be a bit biased because I'm the founder of Marker.io :-)

Thank you all for your amazing answers! I am overwhelmed by the amount and quality of the replies I got from you guys. Good job!

Apart from few interesting tips, most of you still seem to annotate design changes manually. Doesn't matter what tool, but it seems like most of you still go back and document the design changes on your own. Either in some annotation tool or as comments on changed elements - but the problem is still there - you get distracted from the creation process to document things you've already done.

I believe there is an opportunity to complete automate this documenting part. Imagine you upload two versions of the designs - one older and one newer - and the app automatically tells you exactly what changed - down to the layers level.

I tried to visualise it during the weekend: https://cl.ly/rhmK/

Would something like this make your life easier? Or do you consider the problem so small that it's not worthy solving? (inserts forever alone meme).

https://marcosvid.al/sketch-notebook/

We are working on this problem at usepastel.com - happy to answer any questions you may have aloke@usepastel.com

Talk to them. Don't just send documents in hopes that they complete all the needed changes. Real world chat gets you there way faster and builds rapport with your dev team.

Currently, I am doing it manually in Photoshop with SpecKing - http://wuwacorp.com/specking/ - Looking to improve this process with new tools though.

Let's say I sent a design to devs for them to start coding it. After a while I have to change something in the design, based off some feedback or after metrics come in.

I develop everything I design myself, so that specific thing is not a problem, but in our team we do have a clear rule about design phases. We have four of them and many people take part in them, including stakeholders and developers:

• research
• planning
• visual design
• implementation

We don't allow ourselves to go into any phase, unless the first one is done. So if you have to change something in the design, based off some feedback or after metrics come in, then your research phase was not done yet.

• In research, you gather metrics, ideas, loosely defined wishes and goals for what you are supposed to design.
• Then in planning, you allocate, gather plan all the resources you'll need, from design to implementation. This is also the right phase for low fidelity design work, like wireframes and prototypes and to gather last decisions that have big impact on the visual design phase.
• Following visual design, where you actually sit in front of the program of your choice to create mockups that show how the final product will look and feel.
• and of course implementation itself. Where you... implement.

If you honour the boundaries between design phases, then there are no questions unanswered when implementation happens.

Your Situation shouldn't occur, because if you don't start designing until you have all needed information, then there won't be any implementation that needs to be cancelled. Vice versa, when implementation has started, don't design anymore. It is done. Do not start development unless design is completely done.

The only thing that won't make this process painful are barriers and respecting them. A clearly defined process can be a guideline for all and prevents conflicts and frustration from arising.

I agree with Paul. I would like to add that i upload the changes to Zeplin and then leave a comment for them before i walk over and talk to them.