Design Table Podcast

Your stakeholders tell you to skip research and just ship it. We'll test later is what they say, but later never comes. The design misses the mark. And now you're doing twice the work to fix what could have been done right the first time. That's the cycle we're discussing in this episode of the Design Table Podcast.

In this episode, we talk about what designers are really hired to do and why your job is closer to being an insurance policy than a pixel pusher.
We dig into how to handle stakeholders who think UX slows things down, why "ship it and learn" almost never leads to actual learning, and how to reframe your design process in a language executives actually respond to.

In this episode you'll learn:
🔸 Why designers are an insurance policy between ideas and production
🔸 How to handle stakeholders who think UX slows teams down
🔸 Why "ship it and learn" usually means "ship it and forget"
🔸 How to reframe research as risk reduction, not extra work
🔸 Why designers need to stop apologizing for their process
🔸 When you should and shouldn't do research on a feature

⏱ Chapters
00:00 Stakeholders who say "just ship it"
03:14 Designers are salespeople and therapists
06:12 Design as an insurance policy
07:05 The myth of "ship and iterate"
10:15 Getting faster to make room for research
12:31 Why designers need to stop being too nice
17:05 Selling design through company goals and KPIs
22:41 When should you actually do research?
27:06 Quick summary and takeaways

Subscribe to The Design Table Podcast
https://www.designtablepodcast.com/subscribe

More about Tyler and Nick
Tyler: https://www.designtablepodcast.com/hosts/tyler-white
Nick: https://www.designtablepodcast.com/hosts/nick-groeneveld

What is Design Table Podcast?

Get a seat at the table and build the design career you want. This podcast is for designers looking to break in, level up, and take control of their careers—whether you're freelancing, climbing the corporate ladder, or just trying to get noticed. Every two weeks, we dive into career fundamentals, design best practices, and the hottest topics in the design community.

Nick:

What would you say to someone who replies saying like, well, there are always unknown unknowns, and we cannot do it well now anyway. Only only way to figure it out is by just going live, and then we'll see what happens.

Tyler:

Then my follow-up might be, so I'm not opposed to building quickly, launching, and then iterating, and then trying again. Though the pattern I see often is that the iterations iterations

Nick:

we're officially live. We're officially live exactly. I mean, this is just an experiment. Alright. Question for you, Tyler.

Nick:

Imagine you came fresh out of school and you have this whole plan on your first job as a designer and ready to go and your stake your main stakeholder tells you, well, let's just launch. Let's just do all of that later. And later never comes, and you're there with all your good intentions, with no research, no design process. What do you do? How can you solve that or prevent that even from happening?

Tyler:

Interesting. So it's yeah. You're bright eyed, bushing tailed, and you wanna do all the steps that you were taught out of school. I need to do my discovery. I need to do my research.

Tyler:

I need to do my user testing, validation, checkpoint, checkpoint, checkpoint, checkpoint. However, it doesn't always happen in that order or all at once depending on the, I guess, design maturity of the company. So one thing I've done so I've been in that case. Though I started my career where user research wasn't a thing, that became a process that I had to kind of discover was valuable like throughout my journey. But I've hopped on companies where I that was in my the quill of my back pocket.

Tyler:

You have to get I think the solution is you have to get pretty scrappy. So you have to prove essentially the ROI of that research. And in the beginning, you may not get access to funds, the resources to kind of execute on that research. So you'll have to kind of do things, ask for permission. Don't ask for permission later or ask for forgiveness, whatever the line is.

Tyler:

So what I've done is all you can even start internally, run a user's user interview with, like, internal stakeholders as, like, the first go around. I think at the end of the day, the purpose of research is a sanity check. It's it's saving the company money because if you launch something that is wrong, there's a consequence or a monetary consequence to that action. So test it internally.

Nick:

Mhmm.

Tyler:

And then you're building what you're doing is you're essentially building a culture of research. So if you start with internal, you get to you get to expose everyone in the company at that first layer. Here's I'm doing research. This is why. Do and then synthesize the research.

Tyler:

Do a share up internally, and then you'll build a case from there until eventually, like, let's let's actually try to invest in actual research with our actual users versus just internal. And so it's a lot of advocation, I think, at the beginning if you don't have that design maturity at the beginning.

Nick:

Yeah. So it's it's basically lots of selling.

Tyler:

It's that's all that's all we do. I think across department, we're all salesmen at the end the day. We're we're advocating for our vertical or or kind of our niche within the company, and it's whoever has the loudest voice gets gets heard the most. Right?

Nick:

Yeah. Yeah. Stand up. What what what I think is also very important here is you're a designer, you're a salesperson, which you just mentioned, but also you're also a therapist in a way. Because you're listening to your stakeholders talk.

Nick:

You have meetings with them. And after a while, I think you will notice, like, the things they value. And then you can reframe your plan, your research plan, your your UX plan in a way that speaks more to that person. One example I can give, the real world example, is that I spoke to someone for multiple meetings across two days in a design sprint type way, you know, consultancy. I I was asked to go there.

Nick:

It was mostly branding related, so not not UX per se, but I think that the theory behind it still makes sense. Like, he said a lot of pragmatic was his favorite word, pragmatic. You know, it's two things in a real be realistic, basically. So I threw away my entire, you know, deck with with graphs and theory and and, you know, because I already had this feeling. Like, if he's talking about being realistic and pragmatic as much as he does, he's probably not going to like an extensive research deck with all plans and notes and that kind of stuff.

Nick:

So it became much more of a, you know, water cooler type talk. You know, we're just talking about the goals and getting there and doing things quick and having subtle hints like, well, I just like to do things and get things done. And then you can see him nod. He's like, oh, yeah. Yeah.

Nick:

Yeah. Yeah. Yeah. We speak the same language. And then because of that, he's way more open to listen to the things I have to say.

Nick:

So so that's the theory the therapy part of a designer's toolkit, I would say, especially in this case. You know, you have to like always, you have to speak their language.

Tyler:

Yes. Exactly. Yeah. So you're just you're mirroring back what their what their needs are, and that's a way you can kind of shoot or springboard your kind of ideas because it's based on what they they value. So he's the pragmatism is there, but if you if you sell if you're the salesman for your UX environment, you can just sell through the way that that person whatever their values are.

Nick:

Yeah. Yeah. I mean, that's I mean, that's smart anyway. Like, it it works for designer developer talk, but also designer stakeholder talk and designer user talk, of course.

Tyler:

But I think, like, the end of the day, like, what I think what we have to be aware of is, like, as UX or product designers, what we do is we're an insurance policy. We're we're valid we're a validation step in between idea and production. And there we should be real like, what we should be selling is, like, the risk of not doing our kind of job in the chain is because if we launch if you launch a feature that misses the mark or is too bloated of a feature, like, there's a there's a real serious cost to that. Mhmm. Like, ship it yes.

Tyler:

Ship it and learn. But if you're shipping code that misses the mark, there's you have to revert the poll or or push to production. You have to change a thing. Why not take the the time and do it right the first time or at least 80% right?

Nick:

What would you say to someone who replies to your story saying, like, well, there are always unknown unknowns, and we cannot do it well now anyway. Only only way to figure it out is by just going live, and then we'll see what happens.

Tyler:

Interesting. I I hear I hear that. And then my follow-up might be so I'm not opposed to, like, building quickly, launching, and then iterating, and then trying again. Though I see the pattern I see often is that the iteration cycle is quite long where it never happens. So there's promises of, like, we're gonna ship a thing, and then we're gonna learn, and then we're gonna circle back and then improve it the next time.

Tyler:

First question, is that part of our process? And if it's not, then that initial statement from that stakeholder is false. Like, we'll ship and learn. Well, what is what do you mean by shipping and learning? Like, are you actually looking at the analytics?

Tyler:

Are you testing are we are we kind of getting feedback from our sales team? Like, are we actually doing that, or are you just saying it to get it out the door? And if it's the latter, then there's a there's a real conversation to be had because if we're not doing that iteration, then let's invest more so that we're doing things better than shipping. Instead of an MVP, we're we're shipping in a most lovable product instead of just a valuable product. Yeah.

Nick:

Yeah. You know, the reason I'm I'm teasing you with silly replies like this is mostly because I've been going through my mind thinking about, you know, the most challenging stakeholders I've had. And this was one of them. And, sadly, you know, the with the options you gave, it was the latter one. Like, it was just a way of shutting us up so they can just move on.

Nick:

And that did result in having the big conversation, as you just said. We did escalate up the hierarchy, so to say. Our boss was going to talk to their boss, and we all sat down together, and it was very intense and not a fun project at all. So it's not meant to scare our listeners or people fresh out of school. Woah.

Nick:

Is this really going to happen? You know, it's it's it's one time in a ten year career, but still, you know, it could happen. But I really like your answer. It's something I didn't come up with at that moment, I have to admit. I was way more junior back in the day, but I'm really having a, oh, man.

Nick:

I wish I said that thing Tyler just told me moments.

Tyler:

I think we all had that moments.

Nick:

Oh, yeah. For sure.

Tyler:

Well, because we're just dealing with people who had just different backgrounds and different things that motivate them. I think that's important to to to think about. Like, I've I've had a converse just think about, like, what person's job is, like, in the role in the company. And then that's it's not that they're doing bad decisions. They're just their motivation is blurring the main target.

Tyler:

So I think it's like the back to the whole designers are very empathetic. I think it's just being empathetic of, like, what role they're sitting in and what their goals are, and then to your point, mirroring back or kind of moving them in in the right direction.

Nick:

Yeah. Would it help, do you think, if if a designer would review their own plan? Like, if you get this this comment of where you feel like a stakeholder thinks you're slowing the company down, where you're just like, let's let's go back and look at my plan and see if I can make it 20% smaller or more specific, or is it really a stakeholder problem?

Tyler:

I mean, there at a certain point, there's diminishing returns in terms of, like, how like, you can get faster, yes, and you probably should. Like, I've done that before where I worked at a company where there was always a this ecommerce, of course, so it's maybe a bit different, but there was always a last minute promotion we had to kind of spin up. And it was always 03:33 thirty on a Friday. Hey. I had an idea.

Tyler:

Let's do a promotion, and we gotta get it out the door. And it doesn't and what that doesn't mean is 5PM and you get to leave. It's you gotta stay here till you finish it. So over time, you learn how to get faster and faster so that at a certain point, we're able to kind of crank out that campaign, email, website, ads, the whole slew of kind of collateral pieces. Mhmm.

Tyler:

But at a certain point, you're gonna be you can't sustain that level. Like, you can create the processes and then the tools to kind of get you to that certain speed, but it's like, you're the goal with, like, getting faster is to leave room for some more important tasks, one of them being the research part.

Nick:

Mhmm.

Tyler:

So a strategy might be get faster and then have time to I think you brought up, like, in the case, like, looking over the research plan and then seeing or, like, the the the strategy plan and then seeing, like, what the actual goal might be.

Nick:

Yeah. Because I think we can, stereotypically, a designer can overdo things. You know? Hey. Can you review this section?

Nick:

And then, yeah. Sure. Next day, the whole website has a redesign. You know? Stereotypically, of course.

Nick:

Because it it does make me wonder if we as designers we're all about emotion and connecting to users and people like, maybe we are too nice. Maybe we want to please our stakeholders too much.

Tyler:

I I would double down. I think I'm having over the holidays and and the New Year, I think I was reflecting over what like, how design is kind of morphed over the years. I think we we are too nice. I think I've I may have said this in a previous episode, but I think we do a specific thing, and I I think we should stop apologizing for the work that we need to get done. Like, if you look at our other stakeholders, the engineering department, do they ever have to explain, like, any of their process?

Tyler:

Like, do they have to explain that their relenting has to be a certain thing? Their repository has to be a certain structure? That's the things that are have to be done, and they don't have to explain yourself. They are they are tasked with including thing and what they have to do their process is to process. If if QA if, like, part of, like, their text, I guess, not built in a certain way, then they can't get their job done.

Tyler:

I think we can do the same thing. I think we should stop apologizing for and then being playing nice in terms of, like, what we do as part of the business. Our ROI is quite clear, and I think we should maybe even lead with that versus what we've done historically is is led with empathy and collaboration. Everyone is a designer. Let's all jump onto this whiteboard thing so that you can see how cool it is to be a designer.

Tyler:

The consequence is that everyone believed us. Everyone thought that they could be a designer, so we've lost we've lost our footing. I think the strategy is we do a thing. Here's the ROI of our business, and here's the consequences of not doing a, b, and c. That's part of our process.

Nick:

Right. Yeah. That's funny enough. That's something I've been thinking about recently as well, extending a little bit of what you're saying is if you look at typical roles in a company, you know, designer, developer, marketer. I don't think a designer really has something to say, you know, review wise on the the code or copy for an ads campaign.

Nick:

And at the same time, a designer is going to change something that's already there, something people are attached to. So imagine you're the wall behind you is very nice, bright green, and I'm coming over. I'm like, let's make it blue. It might be better in theory, but then you're like, well, but I like blue. You know, my wife and I did it together, you know, or our our children helps paint that wall.

Nick:

You you're attached to it, and then some stranger designer guy is is like, well, let's change it. You know? So you have to take that into account as well. There's there's lots of emotion involved, and we want to believe it's not the case, but it's real it really is the case that we are irrational, emotional creatures. You know?

Nick:

We will say no to things without it making sense just because it's gut feeling, and that perhaps makes the design role the most challenging role in a company. Like, we have to deal with all the emotion.

Tyler:

Yeah. But if we double down and, like for example, I had a plumber come over a couple weeks ago. I had a leaky I had a leaky faucet in my shower. And then he comes over. He goes, well, looks like there's a a p I need to get access to like, there may be in the other room.

Tyler:

There's, a little opening I need to get access to behind the actual faucet itself. And I'm like, there is no magical door. He's like, how are we gonna do this? I'm gonna have to cut into your wall. I'm like, well, I don't really want you to cut into my wall, but, like, the only the only way to fix my leaky faucet is for you to to to who cares what I think?

Tyler:

You what needs to be done needs to be done. He cut into the wall, fixed the the leaky faucet, and then I'll have to patch it up. That's part of it. I think it's the same strategy that we have that we have to deploy.

Nick:

I think what Almost. Almost, I would say, because, you know, your your the faucet is leaking. That that's objectively true. But I've also had stakeholders tell me, like, well, I I don't think this is a problem that needs fixing. You know, I don't really think that applies to to something broken in the home.

Nick:

Like, we all know that's a problem. And that's what I mean with the emotion part. Like, some people are just attached to how things are going. In founder stakeholder land, it's sometimes they say, like, well, I've I've I've built this myself. I'm proud of it.

Nick:

It reminds me of early days of our startup. You know? And then it doesn't really matter if it's good or not. They just have that emotion, and it's it's challenging to navigate it.

Tyler:

Yeah. It is. I think it's easier if you have if the company has, like, a North Star or objectives for the year. You can, like, similar to the conversation with that stakeholder that was a bit harder to navigate, speak their language again. Like, what are our goals for the year?

Tyler:

Is it I don't know. Is it is it growth? Is it retention? Is it one of these one of these things? Leverage that as, like, that's the reason why we need to fix this thing.

Tyler:

Because it's from my understanding, if you're speaking to them, you go, from my understanding, we wanna hit this growth KPI or this growth metric. This is how this is gonna affect it. So you gotta you gotta speak that language of of the table again.

Nick:

Yeah. Oh, I may that makes a lot of sense, and I I fully agree. Makes me think of someone I worked with, another designer. He asked for some help just to we want some some fresh perspective, like, are we designing correctly? Is our how can we improve our design process?

Nick:

That type of question is what he had for me, and he actually was doing quite well already. And the thing I was most impressed by was how he sold a design project to a nondesigner company. Like, he was the only designer at the company. He said, like, we are doing for every project we're doing, we are starting from scratch every time. Like, we're redesigning everything.

Nick:

We have nothing. Let me do this design research, you know, foundation building project of nine weeks once, and it will save you I don't know the exact numbers, but it will save you weeks for every project. So the ROI is nine weeks now, and let's say, you know, three weeks, and we do not have to do for every project. And then if you do five projects a year, you're already in the clear, and that's sold. It's just, you know, putting a finger on something that hurts, like, that's a lot of work.

Nick:

All it takes is this to fix that. You'll never have to deal with that again, and that really works. I I was really impressed by by how he did that.

Tyler:

What's yeah. He's he how long he was was he in the business, or how long has he been doing design?

Nick:

He's been in the business, I think, eight years, but he didn't start as a designer. Like, he started front end and found his way into design later on, and the company was very helpful in in allowing him to figure his his career out. So it's not eight years of pure design, but that's that's what he ended up at doing.

Tyler:

Well, he has that solid background of pragmatism from the from the developer world.

Nick:

Yeah. We do x zeros.

Tyler:

Exactly. If we do this now, we're there's never gonna be a clear return. Good on

Nick:

him. Mhmm. Yeah. Yeah. I mean, I mean, that's that's perhaps key.

Nick:

Like, if you if you have that stakeholder who's like, well, yeah, no. You're not literally, but if you if they're saying you're slowing us down, I don't want to do this. We have to make that line. You have to see if you can find the fear that he's having or the goals that he wants to achieve, and then see if you can reframe it. I I think that's the the the executive summary of that question and what to do in that scenario.

Tyler:

Yeah. Because I also question, like, what is we have a deadline, but why is this important? Like, another question you could ask is, yes, we do ship stuff, but, like, some of the important work is, like, pushing back and saying no. Like Mhmm. Like, finding reasons why you shouldn't ship.

Nick:

Yeah. Well, I I mean I mean, that's I'm not not sure how much of a gamer you are, but if you look in in game land, game industry, it's full of games that get released where it's you know, in hindsight, it's it's it wasn't a smart timing. You know, deadline was way too soon, and you get a broken game full of bugs and glitches and corrupt save files and and just this overall feeling of I'm paying $80 for this, and it's not finished. But they're already talking about DLC and game passes and that kind of stuff. So, yeah, people will notice if you have a deadline and you release something that's just not good.

Nick:

So that's perhaps a reason to really reconsider your deadlines. Yeah. Well Why why is this a deadline? Like, should we shouldn't we take a bit longer and just get it right the first time?

Tyler:

I mean, the natural consequence of, like, what are you saying, or the benefit of actually doing it right the first time is that you're the users will advocate for your product.

Nick:

Yeah.

Tyler:

So if you if you ship it incorrectly or do a subpar job on that first release, you're gonna have to do all the most of the selling instead of the other way around. The users will do the selling for you.

Nick:

Well, having a user champion is what someone called it is, you know, is always a good thing, but it also depends on who's paying. You know? Because sometimes you have projects where the company's client doesn't pay, but the the client's client does pay, if that makes sense. Mhmm. Not sure if that's relevant today, but I I guess you're right.

Tyler:

I wonder what other kind of pushbacks or any other pushbacks, I guess, statements from stakeholders that you're hearing from from other designers.

Nick:

I think in general, it's it's mostly misalignment or the or that's how that's what it feels like. While in practice, usually, you want the same thing, but we're all stuck in our own phrasing and our own bubble. Is that we are we do we're not aware that we want the same thing.

Tyler:

Fair. Yeah. I guess, like, high level question, should you be doing research for every every feature or project that you're doing?

Nick:

No. Not not at all. No. I don't think so. I used to think so in my junior days because you just learn five steps, you know, ideation and and like, I don't even know the the exact names anymore, but, you know, your traditional design thinking steps, you learn that it's one, two, three, four, five, and we're going to do those five in order every time exactly the way you've learned it.

Nick:

But in many cases, it's two two four, and then it's like, oh, doesn't work well. Let's do a bit of one and then jump all the way to five. Like, it's it's messy in real life, and that brings us back to something we spoke about long ago, maybe even 10 episodes ago or something, where we were talking about how education is is lying to you. Like, it's teaching you things we aren't doing anymore in in the real world. But that raises the question, like, when should you research?

Nick:

You know? And perhaps that's something to wrap up the episode, something we can brainstorm on. My opening bid, I would say, is, like, a requirement for something to be tested is that it's easy to test. Like, it shouldn't take too much time.

Tyler:

Yeah. That's a good one. I'd also say that if there is uncertainty on a direction, so there's there's two options. There's constraint, and there's two options, and the team isn't sure. Yeah.

Tyler:

But it has a giant consequence on the users. At the user experience, run a test.

Nick:

Yeah. I'll still Like,

Tyler:

it's really, really core to the to the UX, I would definitely test.

Nick:

Yep. Yeah. Yeah. So that's a good thing. Like, the impact that it's going to may make.

Nick:

Like, are you go are you changing the, you know, the super important onboarding flow, or are you changing, you know, a little settings subpage somewhere buried deep within your SaaS? You know, that makes a difference. Last week, someone told me I I presented my work, and he told me or he asked me, how do we know if this will be an improvement? And I didn't really have an answer there because what what he was basically asking is, like, how can we test this, or how can we validate it? And we ended up well, it it looks better.

Nick:

It's got feeling like, you know, as a designer looking at it, you know it's a clear improvement, but we couldn't really attach data to it in an easy way, only in, you know, workarounds. Like, was onboarding related. Like, how do you know the onboarding is better when someone logs in, creates an account? Okay. You know, more accounts created.

Nick:

Fine. Could also be because more people signed up. You know, you could have a percentage based, like, the percentages are higher. Okay. Nice.

Nick:

Well, that that's a good way to know, but then they have an account. But the only way to know if they are successful is if they achieve certain amount of things. And these things happen outside of

Tyler:

the

Nick:

platform, and maybe their business is a bit slow because it's the holiday season or summer break or whatever. So there are so many variables, like, yes, we can test it, but it's very hard to figure it out. So should you test it in that case? Yes or no? So that's also a factor that plays a a big role here.

Tyler:

Yeah. It's a hard one. Because in that example, the the metric you want to track is is an adoption one, but it's outside of the platform. So how do you do that outside of a a qualitative, like, maybe questionnaire? Like, did it did it work?

Tyler:

But then that's only one data point to look at. Yeah. Also, like

Nick:

very easy to steer. Like, did it work? Yes. Is it improvement? Yeah.

Nick:

Sure. You know, it's easy to just find what you're looking for.

Tyler:

Yeah. And I don't wanna us underestimate sometimes pattern recognition. We've done it for a long time. Sometimes we know the same way that you don't remember all the the design steps. It's like pattern recognition.

Tyler:

Sometimes you just have a gut feeling. You've experienced it before. Yeah. Sometimes you just, like, just trust your gut in that instance.

Nick:

True. Right? Quick summary. There's a lot we can do if your stakeholders holders do not like UX or research. You know?

Nick:

Speak their language. You know? Listen to what they value and reframe your story to to help them achieve it, but also be critical about your own research and UX plans. Do you need to do all of these things right now, or can you divide it over time in in different project phases? Right?

Nick:

I think. Yeah. Right. That should

Tyler:

that should

Nick:

be it.

Tyler:

Yeah. That's the mindset. Alright. Till next time. That was a great episode.

Tyler:

So if you like this content and wanna hear more, please like and subscribe.

Nick:

Yeah. And if you want to see more, please go to designtablepodcast.com, Spotify, Apple Music, all the big players, and more.