Put your foot down. I wouldn't even ask. 'We are switching to InVision for gathering feedback for reasons X, Y, and Z. It is very straightforward to use: follow this guide I have created for how to get started with the tool and see tips on how to provide useful feedback to the UI team.'

Breadcrumbs can be really useful if your users are digging down through your deep architecture one layer at a time and have some use for jumping back up the hierarchy 2 or more layers.

They're not especially useful if your architecture is shallow. Also not useful if a typical flow has you jumping between categories or skipping deep into your architecture from hubs. Most ecommerce sites do these things. In this case, breadcrumbs are irrelevant to the user's flow and introduce potentially distracting information.

I would recommend keeping your architecture as simple as possible, account for jumping between categories/hierarchy, naming your pages extremely clearly, and distinguishing elements of your hierarchy clearly. For example, pages with many products should look different from a page with one product.

Don't A/B test this.

I don't see it.

It's [myfirstname].[mylastname]@gmail.com

Looks great.

I don't think you need the menu. Your homepage is essentially a menu.

Don't remove information on hover. When I hover over a project on your homepage, I lose the name, which I need to interpret the information I see and make a decision.

Worrying about WHO is an authority is a waste of time. Does that make your design process better? Does it produce better outcomes?

Someone who is highly qualified and skillful in design could give you unproductive opinions. They focus on something trivial, they make assumptions, or they have some malignant bias.

Someone who is not at all qualified and knows nothing about designing things could give you very productive opinions. They understand the problem you're solving deeply, they are the intended audience for the solution, or they are skillful in describing their reactions to your thing.

It would seem like a much better use of your mental energy to focus on how to get useful feedback from people, and setting expectations as to how that feedback is handled.

practice

Very hard for me to say. As I suggested, it's up to you and your team to iterate on what works best.

In theory, an automated process that spits out diffs in design files at the right level of granularity could help your workflow. An integration on top of that with task-tracking software would be the obvious next step. That said, for me, this issue is mostly solved by having a focused, iterative working style with my team.

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.