The way I've always tried to approach this is by pointing out problems, rather than offering solutions, especially where I'm in a position that I'm giving feedb

The way I've always tried to approach this is by pointing out problems, rather than offering solutions, especially where I'm in a position that I'm giving feedback to someone who is more of an expert in the activity than I am. Expressing things as problems automatically eliminates a lot of the minutiae about wording, color, etc. (since those are just subjective opinions and not reflective of a problem), and it lets people still feel like they're owning the work and not making changes they disagree with because they're forced to. Example: Providing solutions: "Move the 'widgets' menu to the top. And make it bold" Expressing a problem: "So, when I'm using the app, one of the first things I usually want to do is look at my widgets. It took me a few minutes to find out how to do that." The solution to this problem might be looking into whether accessing widgets is a common use case, or finding different ways of educating users about how to find widgets, or yes, even moving it to the top. But no matter which solution is chosen, everyone is going to come out of it with more information than if they blindly implemented the manager's uninformed opinion.