As a software developer tasked with design responsibilities at our organization, I frequently encounter challenges in securing alignment between our design decisions and the preferences of our CEO. Despite presenting evidence and rationale for our design choices, gaining approval remains elusive. To address this issue, we've implemented various strategies, including:

  • Providing data-backed studies to bolster the validity of our design proposals (from different platforms / websites).
  • Proposing A/B testing as a means of objectively evaluating different design iterations. (we currently don't have the resources)
  • Seeking support from team members to reinforce the merits of our designs.
  • Tried the "get rid of the duck" method.
  • Advocating for incremental refinements to gradually align our designs with the CEO's vision.
  • Opting to present major design changes towards the end of meetings to allow for further consideration.

Despite our concerted efforts, the persistence of dated design elements in our implementations underscores the need for continued exploration of additional approaches. My question is; How can I best tackle a stubborn boss?

  • 5
    Do the dated design elements cause concrete problems? Commented May 10 at 13:27
  • 4
    You clearly don't like the the constraints you are being given by the CEO, but what are the actual consequences of those constraints? Are your customers complaining? Is the profitability of the company reduced? Are you losing new business opportunities? If so, then you must make a case for change based on the revenue that is being lost. If not, then why do you need change? Is it just to keep up with the latest fashion?
    – jayben
    Commented May 10 at 13:30
  • 6
    @Wojtek322 The best approach is to have the sales team make the business case to the CEO. In many companies, the CEO listens to the sales team far more than to the developers.
    – David R
    Commented May 10 at 14:11
  • 2
    @DavidR Good idea, the previous job of the CEO was also in sales.
    – Wojtek322
    Commented May 10 at 14:14
  • 2
    Please enlighten us as to what "get rid of the duck" means. Google directs me to wildlife removal sites. Commented May 10 at 21:34

6 Answers 6


After working with a bunch of CEOs and higher ups, I can tell you that creating more business and expanding revenue is one of their top goal. Your current boss probably sees this as not so viable usage of the company resources.

For them, putting you into something that can expand business/revenue takes the priority over some older apps which again, just as you said in the comments, is working fine.

Until you can put up a very convincing use case explaining how it can benefit/retain the current customers and can attract more business even, your boss will see this as a low impact investment.

  • This is classic developer mindset. Ultimately, an improvement that doesn't earn more revenue literally is "doing nothing". Sure, it may be "more scalable, more responsive, more ____", but large majority of the population are not developers, and they don't actually care because they're not paying more money for it.
    – Nelson
    Commented May 14 at 1:49
  • 2
    Developers need to learn to think this way. Pretend you have two ways to spend your money. One gives you increased revenue. One doesn't. Which one do you choose? To justify development costs (your time is a real cost), you need to show returns. Very simple concept. Maintainability HAS a return, but most developers are "too lazy" to actually learn the cost-benefit analysis and stays primarily in their perspective.
    – Nelson
    Commented May 14 at 1:52
  • another way of saying that is that you need to focus on business outcomes and not on the technical bits. Ask yourself "What are we buying with this change?" Commented May 18 at 0:10
  • Maybe there could be someone on staff who understands both business concerns and how design (over the long term) affects that? Commented May 18 at 12:24
  • Someone people will listen to, I mean. Commented May 18 at 12:44

What is the priority of the design changes vs. other work that needs to be done? Elegance is a fine thing, but may not be the most important thing, and any change risks new bugs;you need to justify the (quite real) cost and risk in business terms. Preferably quantifiable terms.

And preferably well defined and justified for each individual change, so this revision can be applied incrementally rather than requiring a leap of faith.

If you have a ticketing/task-tracking system, enter these ideas in it, and let them be triaged along with everything else.

Make it work. Make it good. Make it great. In that order.

  • And, "Write it all down." (Cat's Cradle) Commented May 18 at 12:33

When working on a project keep track of who the stakeholders are and what their individual goals are, as well as how much influence they have on the project.

In this case, I'm going to assume that the CEO is the where the buck starts and stops. It doesn't matter how "correct" your ideas are. If the CEO holds all the power, you need to adhere to their vision. This doesn't mean you can't have plans and resources in position to recover if the vision doesn't end up being practical.

This is a really common problem when management stakeholders don't see the value in the design or work processes of a team. The value of the processes can frequently only be proved when something goes wrong. At some point, you just have to accept that you will likely have a failure and hope that it's not too catastrophic and you have the ability to recover.

Last thing, from the comments you mention that the Sales team blames the outdated design for losing business. Don't depend on Sales to help you with the pitch to change the design. Outdated design is an easy blame for Salespeople, there will quite frequently be other factors that don't want to be mentioned. On the flip side, outdated design is an easy rejection reason for customers that don't want to mention their actual rejection reason.

  • 2
    "If the CEO holds all the power, you need to adhere to their vision." Your answer is sorely lacking a mention to CYA after that sentence. Not all leaders will accept responsibility for their decisions, and will gladly dump the blame on a loyal subordinate that followed their directions if things go wrong or turn out poorly. Commented May 10 at 16:45
  • 1
    @WillemRenzema: E.g., youtu.be/d8JZWfaffUA Commented May 10 at 18:47
  • 1
    If the leader has full power over an organization and is in full control of the vision, there isn't any need for a CYA. No amount of CYA will save you from blame. IMO, the only thing you can do is be prepared with contingency plans if the leader's vision fails.
    – Yourn
    Commented May 13 at 12:04
  • These days we have a short French word for "contingency plan" - 'resume', as in: resume the job search. All good things must come to an end. Commented May 18 at 12:31

You need to turn down the conversation about technical this-and-that, and turn up the conversation about how your proposed approaches increase:

  • Reliability
  • Scalability
  • Maintainability
  • Ability to better support the product once it's up and running

Translate these four factors back to dollars / work-hours saved, and THEN you'll have management's ears.

  • Right, but I think all that emphasis has to be made before people see anything. Assert that the entire design had been created to optimize those things (happiness + money). People are visual and focus on what they can see. If they see first and you answer questions later, it is too late. Get Management's ears before getting their eyes. Commented May 18 at 12:18

It's somewhat less common in professions perceived as more technical but everybody always has an opinion on design and many feel the urge to request changes no matter what. If I am reading your question correctly, you are a team of one and don't have a network to rely on but this is something designers talk about all the time.

So where to start? There are actually entire books on this. Articulating Design Decision has got excellent reviews and seems like it could be very useful to you (I have a copy but haven't read it cover to cover personally). A search for the word “stakeholder” on ux.stackexchange.com also brings up many relevant results.


You haven't specifically mentioned it in your question, but I'm assuming that your product has competitors, since nearly all products do. One reliable way to motivate an executive is to point out areas where your product is falling behind the competition. If you can point to competitors' products and say "this application looks more modern for these specific objective reasons", that will help to sell your case.

Ideally, the reasons that your competitor's product looks more modern (or, that your product looks dated) should be easy to understand even for a non-designer. For example, it's easy to point out overuse of high-contrast drop shadow or bevels and emboss. You could even make real-world analogies ("excessive drop shadow makes an app look dated just like floral wallpaper makes a home look dated"). It can be much harder to articulate concepts like negative space or reactive design.

  • Show the competitor's first, and when they go "Ooooh!", say, "And this is what ours looks like." Sold. Commented May 18 at 12:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .