How I went from a design punching bag to a lead designer

For the longest time, I thought being a designer meant being the punching bag of your team. You have to take the opinion of every stakeholder you work with (customer success, sales, engineering, customers, product manager) and, sometimes, the stakeholder views conflict with each other.

Seven months later, and with a new product director that implemented processes and helped guide the way, I learned that I never needed to be a punching bag; I was just terrible at managing my stakeholders.

The Problem

Being a designer meant it was my responsibility to uncover customer problems and pain points through user research. However, as expected in a tech-startup, the issues were everywhere. In addition to the customer pain points, I needed to work with engineering for technical feedback and other stakeholders for design feedback. On top of that, we did not have a product-making process, which made communicating with stakeholders very challenging.

I tried to accommodate every feedback possible in the worst ways, which resulted in no happy stakeholders and no outcomes.

So what did I do?

It’s not “just a button”

One of the biggest challenges I encountered as a designer was when other stakeholders would underestimate the research necessary within a project or tell me the band-aid solution to a bigger problem.

This conversation often sounds like this:

“It’s just a button” — Underestimating the scope

“I believe you should just do this” — Unvalidated assumption

“[Solution] is what I need” — Workaround solution to a complex problem

The worst part is, I would listen to them without further questions. There was massive discussion around edge cases and scope increases when it came to the design reviews. This debate caused team conflict and entire pivots to cut the project.

Thankfully, our new process incorporated conducting proper user research for every project. This research allowed us to:

• Understand the problem better
• Challenge any assumptions with evidence
• Design the optimal solution for the problem instead of band-aid solutions.

An example I want to use is the changelog project. A changelog is a record of all the changes made to a user. Our stakeholders used the changelog to manage our customer’s billing and wanted an improved changelog experience. We quickly realized that the project became a changelog redesign, which did not align with the epic’s goal.

Upon diving deeper into the problem, we realized that we needed an automated billing system instead of a changelog. This solution is far more scalable, user-friendly, and solves the customer’s problem. However, it’s also a costly feature. But we also understood the amount of value this feature would deliver to the customers.

We now have a scalable, automated billing solution for our Teams customers.

If you did the research, your opinion matters

Previously, I never questioned my stakeholders about their design solutions.

I did not own the project, and being a pushover, I also never challenged their proposed solution. This mindset killed potentially brainstorming other solutions & research validation.

With our new team arrangement, I began to understand the role I play as a designer, which is:

• Own the user research
• Understand the problem
• Champion my customer
• Own the solution

As a designer on the product-led growth team, my team’s OKR is to increase the number of customers per CS member. One of the biggest challenges preventing this is billing, where CS spends at least 30 minutes a day on top of their daily work. Reducing the unnecessary billing workload will give CS their time back.

Understanding those metrics is when my mindset changed. My solution needs to have a direct impact on the metrics.

Also, being the person who conducted the user research and the customer interviews, I am the problem expert, and as the most knowledgeable person on the subject, my opinion matters. To champion my customer, I need to take ownership and lead the project as the lead designer.

Now I am involved in every stage of the product making process:

• I help set the vision & roadmap.
• I help write the user stories for sprint grooming.
• I work closely with the engineers to identify all the edge cases.
• I measure and track how my feature is doing.

Stakeholders are your allies, not your enemies

Ever been told “the scope is too big” or “this isn’t feasible” from the engineers while your stakeholders try to creep the scope up?

Your stakeholders are not blowing the scope up for fun. It’s the only time they get to express all the problems they’ve been encountering. They think that if the solution doesn’t get made now, their problems will never get fixed. They most likely don’t understand what the product-making process is like, so they only want what’s best for them.

And it’s not like your engineers don’t care about the customers. I’m fortunate that the engineers I work with are customer-centric & care about UX. But there are also other values that engineers value like code quality, scalability, feasibility & execution time.

The key is to align the team on understanding the problem and being customer-centric.

For example, when certain elements would be too much work or certain information wouldn’t be feasible to pull off without increasing the story points, I asked myself:

• Can the users still complete the task without these elements?
• How much impact would removing this information have on the user experience?
• Is the solution aligned with the goals of the epic?

I validated my assumptions with the customers and shared the results with all the stakeholders. Through user testing, I confirmed that the user could complete the user flow without those elements. If users can still complete their tasks, then we don’t need it.

However, suppose those elements are critical to the user experience and deliver significant value; we can work with the engineers to invest the time to provide that value. But do keep in mind, the customer value also has to be aligned with the goals of the epic.

For example, the first iteration of my billing design revolved around seeing what products, coupons, and upcoming invoices the customer has.

A part of my design with the coupons was having coupon expiration dates. Upon further investigation, it turns out Stripe did not provide coupon expiration dates. Therefore, to get that date, we needed to manually write the calculation ourselves, increasing the scope more than anticipated.

I spoke with my users to see what this data meant to them and its importance. It turns out the date doesn’t have much value unless it came with follow-up reminders. As a result, we did not include coupon expiration dates for V1. We will include it when we work on billing reminders, but that’s another story.

The team needs to understand what it means to be customer-centric. Should the coupon expiration date be critical to the user experience, we would have prioritized the task.

Stop playing the broken telephone game

Before, when working with multiple stakeholders, I was playing the broken telephone game. I didn’t know when to update all the stakeholders. I would align engineering on something while not updating the rest of the stakeholders. This lack of communication left stakeholders unaligned, confused, and unhappy, making my job harder.

The new process we started following has drastically helped include all stakeholders during the problem review, solution design, and solution review sessions. All the key stakeholders were present when we made important decisions.

However, just having those sessions does not improve communication. If stakeholders have conflicting opinions, the meeting will not end well. This pushback can delay the project.

Understand how your stakeholders are feeling about the upcoming meeting. Message them individually to gauge their feelings. Chances are, if they don’t like the direction it’s going, your meeting will not be a success.

If you have a document prepared, share it with the stakeholders ahead of time. So they can see what’s there, what to expect, and leave comments before the meeting. Not all stakeholders will speak up during the meeting. Knowing your stakeholder values before the session allows you to bring their voice to the table, should they not speak up.

After the meeting, remember to summarize what you went through, what everyone agreed on, key points brought up, and what your next steps will be.

Use emojis & bullet points to make your slack posts as legible as possible. Don’t give stakeholders essays to read. Give weekly updates, and if things are moving a little slowly, give end-of-week updates to keep your stakeholders informed.

After every discussion with engineers or sprint grooming session, I write a list of every action item and share it with all the stakeholders. This communication helps me and my stakeholders stay on top of the changes.

Outcomes

We all have the same end goal, just a different journey in mind. It’s up to you to work with your team to deliver on that end experience; keep your stakeholders updated every step of the way.

By becoming better at stakeholder management, I realized the entire product-making process also become more effective. By understanding my teammate’s and stakeholder’s values, we aligned and agreed on design solutions that champion the customer. Through communication and transparency, we kept everyone updated so there would be no surprises.

Stakeholder management is one of the complex things designers don’t consider as their job — good stakeholder management results in happier stakeholders and a team that works towards a common goal. Now I can say I am no longer a design punching bag.