Why building credibility is a critical part of growing as a designer
How to Influence without Authority, the Soft Skills that Will Advance Your Career
There is a hidden barrier, ~4โ5 years into a Designerโs career, that often influences your career trajectory.
Around this time, most designers realize that creating a great User Experience is more than just following directions: itโs about influencing people to make the right decision.

After all, it doesnโt matter how well-designed a solution is if your stakeholders donโt want to use and build it. In the words of Jeff White, former UX lead at Amazon:
UX Designers need to do two things really well:
1. Design good stuff
2. Get people to agree itโs goodThatโs it.
Thatโs the job. โ Jeff White
When you encounter this, you realize your communication skills, which you might have neglected, become critical in influencing stakeholders to create a great User Experience.
Itโs at this point that most people make one of three decisions:
Gain more authority to make decisions by becoming a manager
Stay an Individual Contributor (IC) Designer and learn to influence without authority
Quit and do something else.
If you plan to stay an IC Designer, hereโs a quick guide on influencing without authority.
Influence without authority and the need for trust
Every designer eventually discovers that their bosses arenโt always right. You might gather feedback directly from your users that they dismiss due to personal biases. Businesses might think a feature is essential, but their users might not care about it.
The problem is that most designers hold low-to-mid-level positions in the organization. Weโre not executives or superstars, so we canโt demand that the rest of the team follow our orders.
Instead, weโre often left trying to advise and influence stakeholders to make the right decision. To do this, we need to build trust through communication.
In Articulating Design Decisions, Tom Greever states that thoughtfully addressing a problem and articulating solutions is critical to building trust. People trust you more when you show that youโve put thought into a solution.
Even if they disagree with your solution, they know they can trust you to provide solutions based on logic and reason.
Understanding how to communicate around problems is often the first step of this process, and thereโs a framework, Why-What-How, that can help.
Why-What-How: how to avoid saying too much
However, Jeff White, former UX Design lead at Amazon, has recommended a slightly different order to be more effective for designers:
1. Why: Why did you make specific design decisions? Why did the Business need this redesign?
2. What: What was the outcome? What did you deliver?
3. How: How did you achieve these results? What was your design process?
Hereโs what to consider.
โWhyโ: The most critical question for your audience
To truly communicate effectively with others, you need to communicate the โWhyโ of the project effectively. The โWhyโ is essential because the audience may be dropped into a new project without context.
Luckily, there are only 4 โWhysโ for most Design projects:
A business goal or outcome: A business wants to reach a particular goal, Metric, new target audience, or more
User pain points and problems: Users have specific, severe problems that drive your design recommendation
Technology constraints: This is something we need to do due to the way that the backend is configured or based on current technology
Decision rationale: An explanation of why you need someone to make a particular decision (i.e., โI need you to do this becauseโฆโ)
For example, if your design portfolio piece is about the time you re-designed the home page, first you need to explain โWhy someone paid you to re-design it.โ After all, if everything was fine with the homepage, why would they spend the time, money, and effort to fix something?
Was it because:
The website was okay, but not meeting business goals?
Users were having specific frustrations with the current site?
It was okay on desktop, but horrible on mobile devices?
Your CEO noticed that we were leading them to do the wrong action (i.e. โCreate an accountโ, instead of โScheduling a demoโ?)
Without addressing the โWhyโ, you might cause your audience to ask, โSo What?โ, because they donโt understand what problem youโre trying to solve. So, defining the โWhyโ is the most crucial step of this process.
After that, we can move on to the โWhatโ.
What: the tangible output (UI, Workflows, Deliverables)
After defining โWhyโ you started with the project, you can move into something more familiar with, deliverables. While you can show them your Figma or Figjam documents, remember not to confuse this with the โHowโ category.
The main thing to remember is not to confuse this category with the โHowโ category. For example, while you may want to explain how โX led to Y,โ that may not be necessary, depending on the context.
Here are a few ways to do that:
Spend time discussing previous designs and problems. Perhaps your previous design was fine until you uncovered new information. If so, highlight the issue with the previous design as you lay out what you did.
Show a before and after design: If the design change is that drastic, sometimes a visual speaks 1000 words. However, this isnโt always the case.
Ensure design artifacts have enough context: Design artifacts like personas arenโt as immediately understandable as UI. Ensure you show โWhyโ theyโre helpful and โWhat you didโ around them.
Lastly, we can worry about the โHowโ.
How: Keep your process concise to answer one question
The โHow,โ in many cases, is mainly for other designers rather than a general audience. As a result, depending on who youโre writing for, you may want to keep this as brief as possible.
You might feel disheartened, especially if you love and tell others about the design process, but remember that youโre trying to influence decision-makers with this format. To do that, you must speak to the level of your audience and deliver what theyโre looking for.
In many cases, what you need to talk about is one key thing:
โHow did you develop your solution, based on changing needs?โ
For example, perhaps your previous design seemed perfect based on your understanding of the problem. However, you gathered additional user feedback, which changed your understanding of the problem.
As a result, how did you change things to adapt to a changing problem? Communicating this doesnโt just help you present your work; it can also help you refine your portfolio.
Many designers like to squeeze everything into a particular process. I canโt tell you how many generic portfolios Iโve looked at where every single project someone has done โmagicallyโ fits into the Double Diamond.
This is not what happens in the real world. There are complications, constraints, bad project managers, extenuating circumstances, and more. Those are things that people want to know about because thatโs one of the most common questions that you hear in interviews:
โTell me about a time when you ran into (conflict with stakeholders/vague requirements/a shortened design cycle, etc.). What did you do?โ
What to communicate:
How did your understanding of the problem change based on (user feedback/stakeholder interviews/data/etc.)?
How did you come up with your solution based on these changes?
What ended up happening? Were you still able to deliver a good result, regardless of complications?
Practicing this framework will enhance your communication skills, making you a more effective designer and increasing your chances of career advancement.
To be a great designer requires communication.
Iโm a big fan of Jeff Whiteโs saying, โWrite first, design Later.โ Often, we have an apparent idea of what weโre designing (or what we want to do) in our head, but communicating it to others is much more complicated than we realize.
When designers encounter this problem, they tend to rely more on their design skills instead of polishing their communication skills.
However, this can easily lead to issues where designers follow directions and create features the business wants, even if itโs bad for users.
Learning to show intentionality with communication and build trust is critical for influencing decision-makers to make the right decision, even if that requires creating friction with your bosses.
So, if youโre considering staying an IC designer, you should practice clear communication. This can allow you to influence without authority and get your team to make better decisions.
Kai Wong is a Senior Product Designer and Data and Design newsletter writer. His free book, The Resilient UX Professional, provides real-world advice to get your first UX job and advance your UX career.