August 2020 : Engaging the team in your design goals

As designers, we think of ourselves as “user advocates.” Often, it’s a role no one else shares. Even if other stakeholders are sympathetic to user needs, we may be the only team member incentivized to champion them.

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:

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.

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.

But when we show this in our design review, the team never gets around to critiquing whether our work fulfills the goal. Instead, their feedback undermines the goal itself.

• The vendor relations lead says: “Our paint factory is running short on most of these colors. We should indicate this in the UI so customers are less likely to pick them.”

• The Drivers community manager says: “Our drivers barely have enough storage space in their vans for one paint color. They’re already complaining about how they don’t have extra room in their cars. Now we’re asking them to carry 16 colors? This is going to cause a revolt.”

• The engineer says: “Our templating language has this weird bug where it can only support four images per page, including the logos in the header and footer. We know it’s bad, but we can’t fix it before the deadline.”

• The Strategic Partnerships VP says: “We just signed a deal with Crayola™, so you’ll need to place their two colors up top. Also, let’s schedule a follow-up meeting to see if we can strengthen the relationship by removing the other 14.”

We leave the review dispirited. Whenever we have an idea to make the customer’s life better, it feels like everyone else can only push against it. It’s like their roles incentivize them to diminish the user’s experience.

By the end of the day, we’ll 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:

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:

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:

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.

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.

If our team’s in an office, we can do this in a meeting. If they’re remote, we can ask them to comment async on the issue.

We can start the meeting by asking participants to review each goal in the list. Then we can ask:

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 we’ve based any goals on flawed or incomplete information.

For example, Smear’s Community and Logistics teams might not talk to each other often. If Logistics is launching a program soon to lease bigger cars to drivers, they might argue the community manager’s goal isn’t a priority.

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, we can ask them to suggest any other goals we haven’t yet written down.

This is 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 the paint factory. This would be a good time for a team member to suggest we ask them for feedback.

It’s also a good time to brainstorm 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.

• How important is this goal to the organization? That is, how strongly does it embody our core values or design principles? If the entire company has a set of OKRs, how likely will a solution to this goal advance them? Because these are shared norms, these discussions will be more detached and rational.

• How important is this goal to whoever came up with it? In other words, are they personally invested in solving it? Has leadership tied it to compensation or leveling? Does someone want to avoid upsetting a high-paying customer who really wants it solved? If this colleague is a co-founder, is the goal deeply tied to their personal aspirations for the company? Since these are all sensitive subjects, these discussions will be more emotional and subjective. They may even conflict with what we deem important to the organization!

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 on in the design process.

B. Validate 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 priorities conflict with a goal that has a greater business impact. Since this whole process is about thinking creatively to transcend zero-sum arguments, this shouldn’t happen often, but sometimes it can’t be helped. If Smear’s executives want to freeze next year’s paint spending due to supplier issues, we can’t realistically discuss expanding our color palette.

In these cases, 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 another project that would be more impactful for users, 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.

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.

---

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.