As designers, we think of ourselves as “user advocates.” Often, it’s a role no one else shares. Among everyone involved in making product decisions, you may be the only one who’s mainly there to champion the user.

But we can easily conflate advocating for users with fighting for them. In a fight, you have no choice but to defend your position, centering your priorities above those of others. Fights are zero-sum, and that’s how we can sometimes see our work: as a power struggle between ourselves and our teammates.

But advocating for a group doesn’t automatically mean that others have to lose. Even in a design-hostile environment, it’s possible to champion user needs without being domineering or defensive.

I’m going to walk you through a method for crafting design goals that I’ve found to be extremely effective in both tiny startups and large bureaucracies. You’ll learn to be a neutral facilitator of team priorities without abdicating your stewardship of the design process.

Our scenario

Let’s say we’re a designer for a fingerpaint-on-demand startup. When it came time to name their company, the founder wanted to evoke the physical sensation of the activity:

Logo for Smear.

When you order a session through Smear, the company exploits a gig worker for $2 an hour to bring paint to your house. Right, now you can either use them yourself or give the driver an extra $2 an hour to paint alongside you.

But now Smear plans to go upmarket and target the obscenely wealthy. For $95 an hour, you can now invite drivers into your living room and watch them paint for you. No need to wash the paint off your hands! Just sit back, relax, watch someone slather paint all over their big fat fingers, and meditate on your life.

Ad for Smear Gaze: Enjoy the vibes.

Company leadership is unsure whether to market Smear Gaze as a stealth ASMR thing for zoomers or a new wellness technique for millenials, hence the ambiguous messaging.

Anyway, lots of customers love Gaze. But a vocal minority complains about the bright, loud colors the painters use. They find them to be “a violent assault on the eyes” (direct quote.) As the design lead on the Customers team, we need to find a way to satisfy this group.

Our goal statement might look something like this:

Gaze customers should have more choice in their session’s color palette, because we believe that will increase median customer sat.

So far, so good. After brainstorming lots of ideas, we come up with this theme selector page for the checkout flow.

A webpage mockup for choosing a color palette for your Smear session.

But when we show this during a design review, our colleagues don’t critique whether our work fulfills the goal. Instead, their feedback undermines the goal itself.

We leave the meeting dispirited. Whenever our team has an idea to make the customer’s life better, it feels like everyone else pushes against it. It’s like their roles incentivize them to diminish the user’s experience.

By the end of the day, we resolve to fight for our original goals. Unlike everyone else on the team, we’re here to fight for the user, and no one else we work with seems to care about that. If we can just get everyone to understand our work’s importance to the business, maybe we can finally start shipping great product.

Time to reflect

Alright, let’s stop and think about what just happened. Does it really have to be this way? What are we overlooking here?


Well, a few things.

Software development is a team sport.

If the team can’t implement or support our work, our product will be mediocre. It doesn’t matter how great our design is.


For example, if our design ignores technical constraints, it might ship with usability or performance issues that negate its positive qualities. If it reduces driver satisfaction, that will eventually reduce customer satisfaction by proxy.

Fighting for the user isn’t about blindly arguing for our ideas. It’s about helping everyone in the company figure out how to contribute to an excellent experience.

Our narrow perspectives shape our opinions.

When we’re immersed in our work, it’s easy to assume our current priorities are the most effective way to achieve our goals. But that’s not always the case. When we assume we’re the sole authority on what’s best for our users, we can end up accidentally fighting for something that hurts them.

For example, our role at Smear is laser-focused on designing for a single persona. Our compensation might even be tied to their success. So it might be easy to forget that we’re working in a two-sided marketplace, where both customers and drivers need to be successful. An effective design would need to reach beyond our role and take that into account.

When someone expresses a different perspective, they’re not always disagreeing.

In other words, what seems like the start of an argument might just be a misunderstanding. In these cases, it’s possible to come up with inclusive solutions that satisfy everyone.

For example, maybe the logistics manager can’t source the colors in our mockup but can find others that look just as nice. And perhaps, if we dig deeper on the technical requirement, we’ll discover the site can only display four raster images per page, but CSS gradients or inline SVGs are okay:

A webpage mockup for choosing a color palette for your Smear session, using gradients instead of photos of paint colors.

Even if this isn’t the aesthetic we originally wanted, it still manages to achieve our goal.

When we equate fighting for the user with fighting against our colleagues, we overlook opportunities for win-win solutions.

We tend to reinforce this zero-sum mindset in how we format design tasks. Often, we have a user story or goal statement at the top and append it with notes, design principles, or constraints. Like this:

User story

As a Gaze customer, I want to have more choice in my session’s paint colors, because this will make me more satisfied in the product.

Draft requirements

When checking out, let customers choose from a variety of color themes.

Notes

  • Most colors will be low in stock. Consider making them harder to select.
  • Paints for every theme need to fit in a medium-size car.
  • Dev can only display 4 colors per page.
  • Bizdev wants Crayola colors above other themes.

We’re quite literally placing our priorities above anything that might diminish or negate them. When we document information like this, we’re missing an opportunity to stay open to new information or different perspectives.

Obviously, it’s impossible for designers to be truly neutral here. Since we’ve already come to the table with a goal statement, we’re already biased on the best way to move forward. But we can certainly try our best. We can help our colleagues feel like they can share their priorities with us early on, instead of assuming we won’t listen. We can help them feel a sense of ownership in our design process, instead of making them feel like they’re constantly pushing back.

The process below is valuable for teams of any size. But you can spend as little or as much time as you want on each step. On some projects, it’s taken me 15 minutes to run through them all, while others can take a few weeks. It depends on the project size, number of stakeholders, and the level of trust you’ve built up with them.

How to engage the team in our design goals

1. Ask for feedback on the goal up front.

In the story above, we assumed our goal statement was the most important thing we could work on. But we never asked anyone outside our team if they agreed! That meant we wasted a lot of time designing something that others were guaranteed to push back against.

We can save ourselves some headaches by asking teammates to critique our goal statement upfront before we even start exploring solutions. That will help surface the same issues we heard in our design review much earlier in the process.

2. Rephrase each point of feedback as a goal.

Now it’s time to document each point of feedback. But instead of writing down how our colleagues wish to constrain our work, we want to capture a positive vision of what they’re trying to achieve. For each point of critique, we can follow up with our colleagues to try and understand what’s driving them.

For example, after following up with the vendor relations lead and asking five “why”s, we might define their goal as:

We should make it less likely customers will order colors in short supply, because we believe that will keep wait times short.

This framing is a lot less prescriptive and gives us more flexibility when we start exploring solutions.

(Note: when paraphrasing someone’s goal, repeat it back to them to confirm it reflects what they actually meant to say.)

After writing down everyone’s goals, we’ll end up with a big list, like so:

  • Gaze customers should have more choice in their session’s color palette, because we believe that will increase median customer sat.

  • We should make it less likely customers will order colors in short supply, because we believe that will keep wait times short.

  • Drivers’ cars should still be able to store all the paint they’ll need for the day so that they don’t waste time and lose out on wages.

  • We should uphold our contract to prominently display Crayola™ colors so we can avoid legal liability.

  • Colorblind users can still successfully complete the checkout flow, letting us maintain or increase our conversion rate.

  • Gaze customers can clearly identify the colors they’ve ordered so our support team can easily troubleshoot problems.

There are a few more perspectives represented here than we heard in the design review! When we take the time to ask everyone for feedback, we’re creating space to hear from people who aren’t always comfortable speaking up in meetings.

3. Share a list of every goal.

We still need to earn our colleagues’ trust that we’re not yet treating our goals as more important than their own. So, for the sake of transparency, we’ll add the list to our issue tracker and forward the link to everyone before meeting.

Avatar for jrubenoff
jrubenoff commented

Hey all: before we meet, here are the goals we’ve collected so far.

Goals

  • Gaze customers should have more choice in their session’s color palette, because we believe that will increase median customer sat.

  • We should make it less likely customers will order colors in short supply, because we believe that will keep wait times short.

  • Drivers’ cars should still be able to store all the paint they’ll need for the day so that they don’t waste time and lose out on wages.

  • We should uphold our contract to prominently display Crayola™ colors so we can avoid legal liability.

  • Colorblind users can still successfully complete the checkout flow, letting us maintain or increase our conversion rate.

  • Gaze customers can clearly identify the colors they’ve ordered, so our support team can easily troubleshoot problems.

Before we’ve even started building consensus around these goals, everyone now has a map of the organization’s competing priorities. We can use this as a foundation to start building empathy across disciplines.

4. Get everyone to buy into each goal.

Eventually, we want to rank each goal by its business impact. But before we can do that, we all need to agree these goals are worth solving in the first place.

So hold a meeting if our team’s in an office, or ask people to comment on the issue async if our team is remote. First, ask them to review each goal in the list. Then, ask two questions:

  1. Are there any goals here you don’t understand?
  2. Are there any goals here you disagree with?

In part, this is an exercise in building empathy. People can’t rank priorities they don’t understand. But this is also an opportunity to identify whether any goals are based on flawed or incomplete information.

For example, Smear’s community and logistics teams might not talk to each other often. If the logistics lead is poised to launch a program that leases bigger cars to drivers, they might argue the community manager’s goal isn’t that important. When we explicitly ask these questions, we’re giving stakeholders a space to sync up and reevaluate whether their current priorities make sense.

5. Brainstorm what’s missing.

Now it’s time to get the group to build up our work! After everyone’s agreed on the list, ask whether they can think of any other goals that aren’t yet written down.

This can serve as an opportunity for stakeholders to fill in our blind spots. For example, we might have no idea that Smear is working on pigment management software for paint factory. At this stage, the vendor relations manager might encourage us to get feedback from that team’s design lead.

It’s also a good opportunity to brainstorm our project’s externalities and negative side effects. For example, most Smear customers are very loyal and have no complaints about the original colors. There’s a possibility they could see the introduction of more subtle palettes as a betrayal of the brand’s roots. If the team wants to make sure this group stays happy, it’s worth writing that down as a goal.

6. Prioritize the goals together.

Now here’s where it gets interesting. Once we have a complete list of goals, we’ll facilitate a group discussion about how to rank them.

To evaluate each goal, we’ll ask the group two questions.

We can kick off the discussion by answering these questions for our own goals: making a case for their business impact, and articulating our personal incentives for solving them. But after that, our goal is to facilitate and listen.

By the end of the meeting, we should have a final list of ranked goals. But ultimately we’re trying to do three things here.

A. Understand how important each goal really is.

Instead of automatically giving everyone’s feedback equal weight, we’re asking the entire group to consider each goal objectively and agree whether it’s worth ranking above or below their own interests. This will give us a more realistic understanding of how to evaluate our ideas later in the design process.

B. Validate whether our original goal is worth our time.

Earlier, I mentioned how some goals in the list may be based on flawed or incomplete information. That includes our own! During this exercise, we might discover someone’s stubborn pushback on project feasibility actually reflects the majority consensus. If they make points we haven’t yet considered, we might come to agree with them.

Other times, we might discover our goal is incompatible with another that has a greater business impact. Since this whole process is about thinking creatively to transcend zero-sum arguments, this should happen infrequently, but sometimes it can’t be helped. For example, let’s say Smear, after tense price negotiations with suppliers, decides to freeze next year’s paint spending beyond their current inventory. That doesn’t leave a ton of room for discussion.

When this happens, it may be easiest to end the meeting early and reassess what to work on. On the other hand, if our colleagues’ goals help us identify something else that might be more impactful for our audience, we can use the meeting to build consensus around that instead.

C. Learn how the organization’s structure impacts our work.

Ideally, everyone who participates should be happy with the rankings. But the list will inevitably reflect our organizational politics, and so that might not always be the case. Stakeholders might be engaged in turf battles or have competing incentives. An office bully in the room might make others reticent to advocate for their interests. Goals rooted in a founder’s personal desires might go to the top of the list, even if they undermine the business on balance.



Because we’re not yet emotionally invested in the project’s success, this meeting is a good opportunity to analyze what those incentives are. If good design truly can’t happen in our company, why? By the end of the meeting, we can jot down a list of systemic organizational issues and start thinking about how to improve them, without boxing ourselves into the mindset of fighting for this specific project.


Here’s an example of what the ranked goals might look like once we’re done. It can take many forms: we might have a numbered list, or maybe just a “Nice-to-have” section for goals that aren’t extremely important or urgent but worth documenting regardless. The format is less important than whether it accurately reflects the sentiment of the group.

Goals

  • Gaze customers should have more choice in their session’s color palette, because we believe that will increase median customer sat.

  • Colorblind users can still successfully complete the checkout flow, letting us maintain or increase our conversion rate.

  • Gaze customers can clearly identify the colors they’ve ordered so our support team can easily troubleshoot problems.

Nice-to-have:

  • We should make it less likely customers will order colors in short supply, because we believe that will keep wait times short.

Notes:

  • Lamar and Anne will coordinate around leasing larger cars to drivers.

  • The Crayola™ contract is more flexible than we thought. Ron will try to renegotiate.

7. While working on solutions, judge them by how many goals they fulfill.

Now it’s time to start thinking through solutions. But it can be hard to summon the creativity needed for rigorous design exploration when we feel overburdened by constraints. So, let’s put the list aside for the time being, and brainstorm solutions for the main goal we started with. (Unless, of course, the previous meeting made us question its value.)

Once we feel like we’ve generated as many solutions as we can, we can try to evaluate them by the number of goals they fulfill. Pretty quickly, we’ll start to see which goals we can realistically solve in tandem and which we can’t.

It’s possible (and sometimes likely!) that we won’t be able to solve everything in the “Must-have” list. The good news is, since everyone’s discussed each goal at length, we already have a decent understanding of the problems that will cause. The groundwork we laid in the previous steps will help us plan our strategy for communicating our decisions back to stakeholders.

8. Share design decisions back to the group.

We’ve just spent a lot of time making sure our colleagues felt heard and included in the design process. But that will only come across if they know we actually listened to and cared about their feedback. We need to be transparent about the decisions we’ve made.

Once we’ve decided on a solution, it’s helpful to follow up with stakeholders to tell them why we chose it and which goals we decided to incorporate. We can do this during a design critique, but if those are sparsely attended, an email or comment on the issue will suffice.

Avatar for jrubenoff
jrubenoff commented

Quick update: here’s a quick Figma mockup of my current thinking around the theme selector.

I came up with rough names for each theme, which hopefully:

  • Helps make each thumbnail distinct for colorblind users
  • Gives the support team’s job the info they need.

Very open to copyedits here!

For the paint supply problem, I’m assuming we can retrieve supply metrics from the server and hide / fade out colors that aren’t readily available. (Caveat: the page might look a bit sparse if many colors are out of stock.)

Lamar and Anne, I’m ignoring driver car capacity for now, but please keep me updated on whether we need to alter this list.

Ron: I can’t seem to find an elegant way to highlight Crayola’s colors with this layout (especially if they’re in low supply!) Happy to revise this if the contract can’t be renegotiated.


Here’s a summary of every step:

  1. Ask for feedback immediately after writing a goal statement.
  2. Rephrase each point of feedback as a goal.
  3. Share a list of every goal in an email or issue.
  4. Get every stakeholder to buy into each goal.
  5. Brainstorm which goals aren’t yet on the list.
  6. Prioritize the list as a group, discussing how important they are to the organization and to each stakeholder.
  7. After brainstorming solutions, judge ideas by how many goals they solve.
  8. Share design decisions back to the group to confirm we took their goals into account.

Even though we primarily think about our work as user advocacy, so much of it falls under the umbrella of organizational transformation. To produce good experiences, we need to bring our colleagues with us. Including the team at this stage is the first step in creating work that the entire organization is excited to support.