>
You are not presenting a quantitative basis for a change. That "work me out of a design" is as diminishing as direct request.First, you are still thinking in terms of a top-down decision where the boss has to choose between deciding what is best, or delegating that with no further input, whereas I'm talking about creating a collaborative dialogue which may or may not result in change at all.
> Please, answer to me why are you concerned with such minutiae next to project completion? Is the Statement of Work you have prepared with designer not detailed enough?
I'm describing a generalised approach based on the examples in the article. If you think this is a literal example of what to focus on, then I might as well throw back at you that what you are describing with SOWs sounds a lot like the fixed, rigid waterfall approach where everything is set in stone at the start, which in the words of Winston Royce himself "is doomed to fail".[0]
Which brings me to my second point: for the sake of the example I'm assuming here that this is not a bike-shedding situation where a manager just wants to change something for the sake of feeling like they added something to the conversation (in which case your only hope is to add something so trivial that it functions as a lightning rod - see the Duck story of Battle Chess[1]).
Let's assume that the boss in this scenario has a reason to want to change something better than bike-shedding. Whether it's a good or bad one is to be determined. Instead of assuming either, the best option then is to engage in a (brief) dialogue to figure out said reason. The designer, being the expert, should be the best person to guide the boss and help decide the validity of said input.
So the goal of this conversation is not to propose a change to "blue and huge". The goal is to approach the design from the point of view of the designer; focussing on the points that still somehow feel uneasy is just efficient since that is most relevant. By asking the designer to work us through the design process we get to ignore the first gut-feeling "solutions", letting the designer keep ownership and acknowledging that they know what they are doing.
If you approach the conversation like this, most of the time it will quickly become obvious that that one of the parties forgot to take something into account: maybe the shade of blue would align more with company colours, despite not popping out as nicely; or maybe it's the opposite: the darker shade would look better, but the designer decided being consistent with the overall look of the company was more important. Furthermore, discussions like this are immensely helpful for making it clear to the designer what metters most to the client. In the end the designer can walk away with a better understanding of their client's wishes: "ok, I'll have to figure out a new balance between aligning with the the company colours while still having some pop in the overall look - and I have a bit more leeway than I originally thought."
[0] https://www.youtube.com/watch?v=NCns726nBhQ&t=8m45s
[1] https://en.wikipedia.org/wiki/Battle_Chess#Development