Designers, stop asking for a “seat at the table”

Evan Osherow
UX Collective
Published in
7 min readMar 2, 2020

--

“I’m tired of being told to listen to designers, that they want a seat at the table. Don’t tell me. Don’t ask for it. Show me why I should listen to you. Show me results.”

This is a quote from a director of product management I worked with for two years. The tone was offensive, the was language harsh, and yet I agree with the sentiment.

Design “having a seat at the table” has been a topic of discussion for years. As design practices mature, companies grow, and processes change, we in the design community have fought to increase our influence. And it is happening.

We now have chief product officers. The McKinsey Design Index is commonly known metric showing the business value of design. And the demand for UX designers is expected to continually grow.

From McKinsey & Company: The business value of design

And yet at every company I’ve worked as a UX designer, the design org often feels like a third wheel on a motorcycle, with engineering and product management being the first and second wheels. Sure, design can make the ride more stable, but only relying on two wheels is faster and provides more agility. This seems to be some of the thinking from orgs adjacent to design. Well, maybe not the motorcycle metaphor, but you get what I mean.

Enforcement of process and creation of structure are the most common methods I’ve seen to give designers a seat at the decision table. And these methods are effective in many scenarios, but they often break down in the face of deadlines, absences, or personnel changes.

If we want to change how people engage design we have to change how people think about design. And to change how people think about design we have to demonstrate our value. Demonstrate, not just advocate. Show and tell.

Ways to demonstrate the value of design

Every company is different. Every team is different. And so your opportunities to demonstrate the value of design will certainly vary.

Here are some methods that have worked for me. All of them require a strong voice and the willingness to lead.

UX designers should be leaders. We should have expert opinions and should know how and when to articulate them successfully. Leadership, public speaking, healthy collaboration, communicating vision… these are learnable skills, don’t believe anything else.

1. Demonstrate design thinking

Design thinking ≠ design. Sure, you know that, but do your colleagues? “Design thinking” is a term that by now nearly everyone in the software industry has heard. Yet in my experience it’s not something most people understand. You can show its value (and thus design’s value) by repeatedly sharing your process.

As I wrote in The best design tools aren’t apps, the more your team understands your process the more they’ll respect you, your job, and the solutions you propose. Design thinking is probably a big part of your process. I really like how Christina Wodtke enumerated key aspects that make design thinking powerful.

  • Distributed cognition
  • Expertise thinking
  • Iterative world modeling

Stand-ups, demos, and planning meetings are great places for you to succinctly discuss the what and why of your design thinking work. The why is critical. Assume that everyone is as curious and intelligent as you (is that even possible?!) and feed their curiosity.

Another method I’ve had great success with is lunch and learns. Once or twice a quarter I get lunch catered to my product team, book a room, and play videos of user interviews I’ve conducted. These lunch and learns have had several positive results. First, free food. But also it gives coworkers more exposure to users and users’ problems. Every lunch I’ve hosted led to new discussions and insights about problems and creative ways to solve them. And these lunches also highlight your process. Team members get to see how designers talk to users, how we test usability, divine data, and get to the root of problems. Basically, you get to show off. One tip: speed up the videos 1.25–1.5 times. They’re much easier to watch at faster speeds.

2. Become the expert about your users

Everyone at your company wants to know more about users and very few people have the time (and proper skills) to learn about them. Whether it’s explicitly stated in your job description or not, you can and should be the expert on your users. And you should publicize that expertise.

Make sure your team knows when and how often you’re speaking with users, what you learned, and the patterns you’re seeing. Don’t be shy about being the user’s voice in meetings. Someone has to. Product Management is focussed on how much people will pay (which is their very important job) or the competitive landscape, and less commonly focussed on whether or not your team is solving real problems for real people. How to gain that user expertise is through continuous time with users.

One recent addition to our process at New Relic is something we’re calling the User Lab. The User Lab is a recurring meeting, in this case every other Thursday from 9–11. Three users are recruited to participate in a 30 minute interview each. Thanks to the User Lab I know that I’ll be talking to at least six users each month, regardless of what project or project phase I’m currently in. The final 30 minutes of the User Lab are used for a debrief amongst internal participants.

Not every org can support this kind of process. I’ve been there. This means you’ll need to be scrappy to get in front of users. Tag along on sales calls, cozy up to the support team, and don’t miss a chance to sit in on customer calls with product managers.

3. Advocate the Bigger Picture

A big part of being an expert about your users is understanding how people use your product (or products similar to yours, or products adjacent to yours). You should understand users’ contexts, goals, and hangups. An exercise like creating a user journey map can help you reveal and visualize these contexts and empower you to see the bigger picture.

We should be designing experiences, not pages, not features, not screens. That’s our job. To do that we must understand and advocate our users’s entire experience. We need to be the voice asking, “And how does that affect this larger workflow?” or “Let’s not lose sight that the user has already been through these steps to get to this point.”

In my experience this kind of advocacy is revelatory to many on the engineering and PM teams. People get understandably single-pointed on a page or feature, and lose sight of the broader experience. But users don’t. Showing your teams that you’re keeping an eye on that holistic vision builds trust in you and in our field.

To reinforce the bigger picture you can hang up user journey maps around the office or display user analytics funnels on team dashboards.

4. The Power of the Prototype

Nothing lights up a design review or team demo like a designer’s prototype. Even (and especially?) if the prototype is vision work and unlikely to get built, people love it. A big part of our job as designers is communication of vision. Prototypes are often the best device.

I sometimes forget that my colleagues can’t read my mind and see the user experiences I’m envisioning. I’ve been guilty of being a black box. Prototyping is a great way to shed light into that box of design mysteries and a great way to get people excited.

It doesn’t matter what prototyping tool you use as long as it can closely represent the experience you want to test or propose. I’ve used Sketch, InVision, Flinto, Famer, and especially good old HTML, CSS, and JS.

Using lunch and learns, demos, or design reviews is a perfect time to show your team how users are responding to your prototypes. In my experience if you’re learning new things from how people interact with your prototype, your team members will be shocked by the surprising things they learn. After all, you’re the user expert.

As I wrote above, to be an advocate for design it’s not enough to explain what but also why. To show the why of my prototypes I’ve recently been experimenting with placing job stories in comments in my InVision prototypes. This shows my team and stakeholders that there’s a reason for everything in the experience. And if there isn’t, maybe it’s a good time to rethink some things.

Putting job stories all over prototypes

Hearts and minds and stuff

Good design is a necessary part of any successful software and software company. A good designer brings a lot to the table, but they often have to fight for that place. I wish none of us were in the position of needing to persuade but we still are. And in many ways that makes us better at our jobs.

That director of product management who was tired of being told to listen to design… I should probably tell you the final thing he said. “Don’t tell me. Don’t ask for it. Show me why I should listen to you. Show me results. And that’s what you’ve been doing. Keep it up.

Let’s keep it up, team. It’s working.

--

--