Aurelius Podcast – Episode 66 highlights with Audrey Crane:

• Defining Shadow Design and its potential impact on your organization
• Audrey and her team’s research study on Shadow Design
• Shadow IT and it’s correlation to Shadow Design
• Risks and implications of Shadow Design in the product development process
• How to uncover if Shadow Design is happening at your company

In this episode, I speak with Audrey Crane, again! She’s the first guest we’ve had back for a second time and for good reason. Audrey has been working on a concept new to me, called shadow design. The premise is based off of the term shadow IT, which was also new to me.

Both shadow design and shadow IT are based on the fact that there’s a ton of design or IT work being done in your organization by folks who aren’t trained in those areas, and often don’t even want to be doing that work.

Audrey has been working on ways to identify if and how much shadow design is happening at your company. In our chat, we discuss the possible risks and challenges of shadow design, how to identify it and very compelling reasons why we should address it.

Links from this episode:

• Gaslighting about the ROI of Design
• The Cost of Shadow Design Teams
• Shadow Design Survey for you to use
• Designmap
• What CEOs Need to Know About Design

Episode Transcript

(this transcript was automatically created using our very own transcription feature in Aurelius and has been minimally edited 😀 )

Hey, Audrey, how’s it going? Hey, Zach. I’m good, thanks. How are you? Excellent, excellent.

Thank you for taking the time to jump on and join us. You know, we were talking about this a little bit right before we started, and I want to say that you are the first repeat guest we’ve had on the podcast. Oh, that’s very exciting. So if, as we were talking about it, I think you said that you were number eight originally. So way back when we started the podcast, you were like episode eight.

And here we are in the time of recording. And so you’re back, and I am really glad to have you back. I’m glad that we didn’t scare you away the first time, but yeah, as we normally do now, like to kind of start with just you introduce yourself, talk about your background and perspective. So folks, if they haven’t already heard of you or know about your work, have an idea of where you’re coming from with the chat we’re going to have. Yeah, totally.

So I studied in undergrad theater and math. You might not know that about me. I didn’t. It was a while ago. And design, as we practice it today, wasn’t really a thing.

But my dad worked in tech since before you could get a degree actually in computer science. So we had like a radio shack TRS 80 in our house, effectually known as a trash ad. And we had Apple two s and we had Lisa’s and all that stuff. So my summer job was always doing QA or whatever for tech companies when I was in high school and college. So I graduated and I wanted to be an actor.

I moved out to California in the mid ninety s and thought like, okay, well, I’ll act. That means I need a day job because waiting tables pays better at night, but hopefully I’m acting. And so I ended up working at a little company that did cdroms and then I ended up at Netscape, like back in the olden days when we used to have like skim 2% and whole milk in all the fridges across the campus. Andreason used to drink it out of the carton when wandered around the campus. And so I got to work there with.

I was kind of around when Ben Horowitz was developing his good product manager, bad product manager thing. I got to work directly for Marty Kagan, which is amazing. And Hugh Dubberly, also like a luminary in the design industry who did the knowledge navigator for Apple back in the day. So that was a pretty extraordinary experience. I got hooked on design, the kind of right brain, left brainness of design.

And since then I’ve worked for Hugh at Deborah Lee design office, but also inside companies as a designer, as a design leader, and then outside companies. Right now I’m head of growth at a company called design Map that does product strategy and design. Nice. There were some stuff in there that I didn’t know about you, and we’ve known each other for years. We have?

Yeah. That’s fascinating for me, conversation for probably non podcast stuff sometime for me to ask about some of that in your background. But you should see my. I still have my Rolodex. I ran the net search page, which you might or might not remember because you were probably too young, Zach.

But it was like the search button that had excite, Lycos, hotbot, all those companies. And I got to meet all those people and still have my Rolodex from that time. So I have a little Elon Musk business card from when he had a little yellow Pages company called Zip two. And there’s some good stories about the olden days. That is madness to even think about.

Seems like, I mean, literally ancient history at this point, but that’s super cool. Usually. That’s exactly how long I’ve been in the industry. Well, it’s still fun stories for sure. Cool.

Okay, so appreciate the background here. And part of the reason that we were going to jump on and chat today is because of some new thoughts and discoveries that you’ve been having. And I don’t want to do it any injustice. So I’m just going to ask you, why don’t you introduce some of the stuff, some of the recent learnings and thoughts about design as a whole, how it’s happening in companies. Yeah.

So I don’t know if you’ve heard of the phrase the value of design or the Roi of design. I say that sarcastically, never comes up. Yeah, I don’t know about you. I’m sick to death of talking about that. And I spent many years kind of like on the bandwagon trying to make the case.

I wrote a book called what ceos need to know about design. The first chapter is like, hey, go look at the IBM Forrester report. Go look at the DMI index. Go look at these things. And design isn’t just for the sake of design.

It adds real value to your business, top line and bottom line, blah, blah, blah, blah, blah. And I still believe that, but I’m a little bit tired of talking about it, to be honest with you. And we actually recently ran like a little salon of vps of design, which are often our clients, to sit and chat about whatever topic came to mind for them. And that was a big topic, was like, we’re still talking about the value of design. We’re still talking about the Roi of design.

How do we measure the value of design? And I don’t know if you’ve seen the recent article, the kind of gaslighting around the ROI of design, that got a lot of interest. So one of the things that we started doing with our clients is measuring what we’re calling shadow design. So changing the conversation a little bit and saying, okay, let’s do a survey of engineers, QA people, product managers, business analysts, executives, marketers, like, everybody that we can get to participate. Let’s run the survey with them, and let’s find out how many hours non designers are spending doing design work.

And we’re careful to kind of qualify and define that in a way that non designers can. Like, we don’t want to get too much in the weeds, but we want to be clear. If you’re in a conversation with somebody else about design, we don’t want to count that. But if you’re, like, solo at your desk doing design or research, and if this is interesting for researchers as well, then we want to know it. And what we’re seeing is jaw dropping numbers come back.

Thousands and thousands of hours come back. We had one client run this. They had a twelve person design team for an organization that had something like 100 engineers. So the ratio is like, maybe, okay, but they found 22 full time employees worth of work, design work being done by people who are not designers. So borrowing the shadow it phrase, right, we’re calling this shadow design.

And then what we’re suggesting with our clients or anybody who wants to run this is to say, like, okay, let’s stop talking about how you need to invest more in design. There’s so much good ROI. So let’s invest. Right? That’s the high of ROI.

Let’s just look at how much we’re spending on design today. We’re already spending it. The money is gone. It’s, like, out the door. But are we spending it intentionally, and are we spending it well?

And if the answer to either of those questions is no, then let’s recalibrate some of that spend. So whether it’s budget or headcount, let’s shift some of that so that we’re paying designers to do design work, which presumably is going to be better. Certainly there are plenty of product managers and engineers out there that do great design. And I don’t want to imply that they don’t, but we would be sort of flabbergasted if we were paying designers to write production code. Right.

So why are we doing the inverse? So this is a different take on the value of design conversation. It’s just like, let’s invest wisely, rather than arguing that we should invest more totally. That’s why I thought this was going to be such a good topic to discuss on the show, because there is a lot still happening, especially with market conditions, global economic conditions, around the discussion of ROI of UX. ROI of Ux research.

It doesn’t matter. And so I thought this was very apropos that conversation as well. And so the first thing I kind of want to ask you is, have you ever experienced. You’ve clearly got a lot of experience in our industry, right? Have you ever experienced engineering teams needing to justify the ROI of engineering, for example?

No, that’s just a blanket question. The answer is no, which I kind of expected you to say. So then the next thing is, when you talk about shadow design, it’s one thing to say, well, they’re just getting designed good enough for certain things. I, again, would fall back to the question, this is genuine curiosity. I’m not trying to plant anything here, but would organization accept shadow development?

So, for example, to find out that not necessarily, like, ideal or non qualified engineers doing engineering work elsewhere in the organization, it’s a genuine question. Yeah, I don’t think so. I mean, nobody looks at shadow it as a positive, right? I don’t think that phrase is used as like, oh, we don’t have enough. Nobody ever said, we don’t have enough shadow it happening in our organization.

We need more of it. And similarly, nor would they say, we don’t have enough shadow engineering happening in our organization, and nothing against it, and engineering that wouldn’t be appropriate. We want it people to do it stuff. It’s important. We want engineers to write production code.

That’s important. Totally. And just, I realize that there’s some people listening to this. They might not know entirely what shadow it is. Can you give a little bit of background what we’re talking about there?

Yeah. So shadow it is a phrase that often IT organizations use to describe individuals doing it type stuff without the knowledge or support of the IT team. So maybe they’re installing software locally, maybe they’re spinning up a website. Maybe they’re even, like, getting an app built, but it doesn’t know about it. And so it’s not generally viewed as a positive thing.

Right. And I suspect there are a number of reasons for that. Security risks, compliance challenges, stuff like that. So I bring that up as a way to sort of bring it back to shadow design and say, well, then why is shadow design bad? Right.

Because there’s going to be an argument for it happening and saying, well, it’s fine. It’s just people good enough, they understand design good enough. And I’m sure that those are similar arguments in shadow it. Right. So it’s like, well, then, if somebody were to ask that, why does it matter?

Why is it a big deal? Yeah. So many points to make here. Let’s see if I can capture, like, half of them. But the first one I want to start with is, let’s not confuse production and design.

When I say design, I don’t mean just drawing screens, although that’s part of it. And it might be a lot of what’s happening in shadow design, but it’s probably not all of it. Right? So we’re talking about bigger things like strategy, insights, alignment, vision, research, all of these things, right. So that’s one bit is we’re talking about more than just good enough screens.

We’re talking about other things. Another point is that sometimes in these, often, I don’t know that many organizations that are like, oh, the velocity of our engineering team is great. It’s faster than we expected. Right. Or our product managers are way ahead of.

They’re doing everything that we asked for and more product design. Marty Kagan talks about, sorry, product management. Marty talks about product management being like a 50 hours a week, 60 hours a week job. They have enough to do, and so do engineers.

What you see is as a symptom is slowing down of some parts of the organization. And then again, if it is just production, one, if you want to intentionally say, like, okay, let’s have engineers do production work, then, okay, I have some ideas about that, about getting engineers to do better and faster production work. But two, you can probably get a production designer cheaper than you can get an engineer. So I do think engineers and designers with a similar level of experience are probably, let’s just say for the sake of argument, the pay is pretty similar. But if you have an engineer doing production design work, you could probably save some money by just bringing in a production designer.

And then, oh, by the way, the quality is going to improve just by the fact that they live in the design. And so there’s going to be more consistency. Maybe it’s easier to leverage component libraries. Maybe they have better oversight. Maybe they get training, and they improve over time, like all that stuff.

So that’s really good. And it makes me think of an analogy, which I’m a big fan of, just in terms of explaining stuff or understanding it myself, which I thought of, like being an auto mechanic. It’s a pretty specialized set of skills. Now, maybe your local plumber knows how to fix cars, and maybe they both make roughly the same, but it’s likely the plumber is going to take longer to diagnose and fix the problem, which ultimately costs you more. Assuming all costs are the same and the quality may not be as high.

Do you want to spend more on lower quality is kind of what I’m hearing. And then on top of that, do it accidentally almost. Right. Like not even know that the guy actually is a plumber that’s fixing your car or whatever. Right.

So organizations that run the survey have no idea. No idea. It’s shocking to discover. And again, if you want to do that and you want to be intentional about it, then probably you can improve the quality and you can improve the costs a little bit. It’s not what I would recommend, but I don’t think it’s impossible.

But you accidentally pay the plumber what you would pay the car mechanic to fix your car, and it’s more expensive than it should be, and it’s not as good a quality. Why would we do that? Why would we do that? Right. Yeah.

If you were to pitch it to somebody that way nobody would actually sign up to do that and pay for that. Yeah, for sure. So I’m sitting here thinking if I’m senior director or something at a company, senior director of design or maybe even product engineering, either one, any one of those. And I suspect this could be happening in our organization, and I want to kind of get my hands around it. How would we do that?

Yeah, so we have a survey that we made available publicly. You can duplicate it and you can run it in your. It’s been through several PhD level research folks, so I’m pretty confident that it’s like, the methodology is good, and we actually even created a template for presenting the output. For example, when we first started, we were just looking at hours and somebody had the insight to convert that to full time employees. And that was really like, that really was very compelling.

So all that stuff is on our website. We’re happy to have people take in and do it. What I’m interested in, and I haven’t shared this with you, Zach, yet, is I would be really interested in seeing if we could get a dozen. No organization really wants to come public like, oh, we did this, and it was crazy. Like crazy pants, as we say.

But if we could get, like, a dozen organizations to do that and then share their findings with design maps so that we could publish some kind of document, that said, I mean, it’s a small sample size, but small, medium, and large organizations found this percentage of shadow design happening in their organization, and then people from there could abstract to what might be happening, what might be happening in their own. I think that would be really interesting and be really useful for design organizations as a whole kind of rising tide raises all ships thing. So if people do do that, I would love to help chat with them, hear the results, at the very least, hear the results, and I’m happy to do whatever I could to help in advance. Yeah, knowledge is power, and the more we know whether or not that’s happening in an organization, the more we can fix it. Shall we say, shining a light on the shadow design, you can have that one for free.

Audrey.

I’m going to put money in the mail for you. Right. I will be here all week. So a couple of things about the survey that I think are really interesting. We are seeing a gamut of reactions within organizations to running it, to wanting to run it.

Some organizations are like, fuck no. Why do we need to do that? Your little survey is not of interest, and you can probably, I don’t know if you do, I guess that there are some political undertones and desire to maintain control. And so there’s kind of that reaction which takes some additional work to kind of work through the concerns and make sure they’re addressed on the other end of the spectrum. What’s interesting to me is mostly when we encounter this with our clients, I see an engineer that’s the front end engineer that loves design, or the product manager who doesn’t know what else to do or really loves it or whatever.

I see a little resistance to design being taken away. But actually, that turns out to be like, there’s a whole other side of it, which is we’re seeing product managers and engineers in response to the survey saying, in some organizations, like, I love working with design. I think that output is better. I think it’s faster. Either I don’t know how to work with them, or they weren’t available to help me.

And we’re actually having product managers reach out to design map to say, like, hey, I’m a product manager. I’m doing shadow design for my organization, and I don’t want to. I don’t have time. And there’s other stuff that only I can do, that I need to do. So could you help me?

So there’s this spectrum from resistant. I don’t want to do it. I don’t want to talk to it, to welcoming it and embracing it. And I think that has to do a lot with. I don’t really like the word politics, but the social stuff happening in the organization and what their relationship is to the design team and the design leader and all that stuff.

But it’s super interesting to me how many people are supportive, non designers are supportive of sussing out shadow design and reducing it, at least. Yeah, I mean, I can imagine that design practice is probably pretty open to knowing about design that’s happening outside of their knowledge or influence. However they would phrase that, I could absolutely see political landmines to step on elsewhere. Teams doing shadow design, assuming it’s just good enough and it’s fine. But the interesting thing is, a lot of what you just described reminded me of the episode we had with Joe Natole, and he talked a lot about how much of these decisions know, fighting what decisions should be right or wrong in terms of product strategy or design strategy, often come out of fear.

They’re fear based decisions. Talk about that. Yeah. It’s interesting to me to think about, as you said it politically, but maybe just exchange the word for fear. I would have to think that getting to the heart of whatever the fear is would help you address it.

And interestingly enough, if this is, I’m not picking on product management. We love those folks, obviously. But if it’s a product management team and they’re doing design and it’s just like, look, I don’t want people to know that that’s happening or for whatever fear, I think getting to the place where you can fully understand why that fear exists totally, as a way to introduce an opportunity for education of that this is actually not a valid fear. And in fact, if we can get to the bottom of this and figure out the actual cost impact of shadow design, your life will probably get better as a result. There’s actually nothing to be afraid of.

Right? Yeah, totally. I completely agree. And probably their fear is valid if it were what we were after. Right.

And just. It’s a good opportunity to say, I’m not saying, like, lay off a bunch of product managers or lay off a bunch of engineers and hire a bunch of designers. I’m not saying that at all. But if there’s some budget that can be reallocated or when there’s attrition ahead gets moved over to the design team, or if there’s a pool of headcount that we’re doing annual planning, right. That maybe design gets a few more than engineer than they would have otherwise.

That’s what we’re talking about. So that’s maybe like, the first fear is like, I’m going to lose my job if we run this survey. And I don’t think we need product managers as designers and engineers. We need product managers to be able to do our jobs and we need them to be able to do product management stuff. And so that’s what we’re trying to do.

And then I do think that there’s another fear, which is control. And we’ve done this with research teams as well. And I think research is a really interesting thing because if you run a really effective research team where everybody is like, holy smokes, what amazing insights. Like forehead slappers, ten of them in that one interview, then you build like a following, and very quickly. And we’ve seen this happen in many organizations, demand outstrips supply.

Like, there are way more product managers that want to go out there and talk to customers than research teams can support. And it’s great, and we love it when product managers talk to customers. Having said that, I do have a whole workshop on how to have effective conversations with customers. But product managers in that setting might feel like, oh, you’re not going to let me talk to customers anymore? I don’t want to lose that control, or you’re not going to let me draw screens anymore.

I don’t want to lose that control. You’re not going to let me hire my own agency anymore? I don’t want to lose that control, a control thing. Right. And so we say, if that’s what works for you and that works for our organization, then great, you can maintain control of that, but I can support it by providing oversight for your design agency so that they’re consistent and you don’t have to deal with the inconsistency issues later.

Or I can provide training for you and the other product managers so that you guys can do more quality research that gets you better answers to the questions that you’re asking so that you can make more informed decisions. So it doesn’t need to be a wrestling for control conversation. It’s just like, as you say, we’re shining light in the shadows and then we’re being intentional about how we do less shadow design and do better shadow design, whatever that means for your organization. Yeah, I really like the way you sort of ended that thought. And the way that you said that, I think that that’s really useful for people to think about.

And the thought that occurred to me as you were describing, that is, if you were to shine a light on shadow design, so to speak, and you have that knowledge, just as you kind of ended, you at least have the ability to make choices. You might choose that the way we’re working is the way that we want. Hey, guess what? That’s good to know. Because if you didn’t know that these people outside of design roles were doing all this design work, now, you know, and that’s at least useful information for you to have.

That’s the first thought that I had. The second one that occurred to me is by getting that understanding and potentially addressing it. Let’s say you look across shadow design happening at your company and you determine that actually there’s enough of this going on where we could easily hire even a junior designer for that and likely the quality would get better. It’s actually a compounding effect, because not only are you then placing in this case, design in the hands of somebody specifically trained for that, that’s likely going to produce higher quality output, but you’re also allowing everybody else who was participating in shadow design, willingly or not, the ability to do better work that they are expertly trained in. So it’s actually a multiplicative effect.

Absolutely. Totally. Yeah.

I think there are maybe five strategies that we can employ in order to address shadow design. Right. One is, okay, we get the designers or the research, like design and research interchangeably. We get some more headcount through attrition or as organizations growing for design. That’s not going to be enough.

My prediction. And we can have another podcast in 60, and I’ll eat my hat on your podcast if I ever see this happen. And then the organization is just like, oh, well, we’re going to do that many ftes. We’re going to add that headcount to design. Boom, done.

That’s not going to happen. And even if it does, it’s going to trickle out. And it’s important to keep running this survey. So you kind of keep an eye on it. Right.

Two is budget. Right? Like, get some budget allocation over to design so design can hire consultancy. And then a third is operation bear hug, I call it. So if that front end engineer loves design more than anything, let’s move them over to the design team or business analysts.

I think bas are designers anyway, just in writing pictures. So put them in the design team. Also, we can get in front of it and call it our parade. So we find a bunch of shadow research or a bunch of shadow design. Let’s provide research training, let’s provide design training to the organization.

But all of this happens kind of so it can get a little better. Are we going to turn a front end or even a back end engineer into a great designer? Probably not. Are we going to turn a product manager into a great researcher? Maybe.

The skills that you need to be successful for good product management are often different than the skills that you need to be good at research anyway. But it all kind of happens under this umbrella of like, we have a clear objective for design in this organization and the quality of work that we do, the KPIs or OKRs. And all of this happens kind of under that umbrella. And it’s probably going to be a combination of these things that you use to reduce, probably never eliminate shadow design. And then if you keep running the survey and keep trying these techniques, it should get better and better.

Yeah, it’s a really interesting thing. Again, I think that just goes back to having that knowledge allows you to make decisions about, that allows you to make choices, but if you don’t know that it’s occurring, you have no decisions to make and you just sit around wondering why maybe our quality isn’t quite where we want it to be, or our velocity isn’t quite where we want it to be. If you’re agile folks, or whatever the case may be, you have the ability to act. Right? The other thing that really came to mind as you were describing this further, because it is something that’s come up a lot as we discuss ROI of UX is risk mitigation, right?

So if you think about what the ROI of Ux is or research or anything that we do that we would call under design or ux, a lot of it’s actually risk mitigation, right? Are we making decisions that are going to double our development effort and cost when they could have been avoided by perhaps a more elegant solution that actually takes less effort, thereby reducing cost? That’s like a really simple example, but the other one is, are we doing something and shoehorning something into the product that actually potentially causes like a security risk or a major usability flaw, which then actually helps hurts our chances to grow or things like this. And these are all things that designers are specifically trained to do. These are all things that researchers are all specifically trained to understand and then be able to translate to a team actively working on that.

It is a combination effort.

Yeah, I just made this up. So we’ll see if it makes sense. But you could call it, like, risk intentionality. Okay. We have design and research teams working on these products, and they are working to mitigate the risk that the user won’t be able to use it, they won’t find value in it.

And then over here, there’s a lot of shadow design happening. I’m not getting a lot of receptivity to my reducing the shadow design. And so we’re going to leave that and it’s risk to play out however it plays out. Somebody, a vp of design that I was talking with recently called that strategic sacrifice. Right?

Sure. But again, it’s intentional. All of this is just about intent. It’s not about perfection. It’s just about intentionality.

And as you say, what are we investing today? Wouldn’t that be better spent getting better, more efficient design and also freeing up engineers, product managers to do what they’re trained and educated and experienced and paid to do better?

And on that note, reminded me of something else I thought of when you were describing this is, I can imagine that there’s potentially product managers, engineers, people in marketing even that are being asked to do some of this stuff that maybe every time they do, they go, man, this sucks. This isn’t part of my job. I don’t want to do that. And the thing you risk, again, it’s risk mitigation. The thing you risk there is you’re burning somebody out that might be a really awesome product manager for your organization, and they’re looking for a job because they don’t want all of that additional responsibility, maybe that they didn’t sign up for.

Yeah, I hadn’t thought of that. But, yeah, for sure, burning folks out, putting demands on them that they didn’t sign up for, aren’t trained for. They feel like it slows them down. And I really have been surprised how many people have said, non designers have said, I don’t want to do all this design work, because mostly what I hear when I talk to people. So I don’t know if it’s just probably just the volume, right.

Of the number of people who are taking this survey now, they don’t want to do it or they want to do it with the designer. They want to have a conversation with the designer. And I do want to say I get in trouble in a couple of ways. I get in trouble in lots of. Ways, but I had a feeling that was going to case.

Here are a few that I know about. One is, I’m not saying that all product managers suck at design. I’m not saying that all engineers or QA people suck at design. That’s not true. Some of them are great at it, and so it’s not about them.

It’s just about the unintentionality. And again, sort of like how we’re investing and how consciously we’re investing our money. So that’s one thing that I get in trouble for. The other thing that I want to be careful to say is, if a product manager, an engineer, anybody is drawing a screen because they want to engage in a conversation with a designer, whatever that conversation is. Like, I had this idea, or I don’t know how to communicate, but if it’s the beginning of a conversation, I would not call that shadow design.

I would just say, like, that person draws pictures to communicate, and that’s totally cool. Please keep doing that. That’s great. If the picture is the end of the process, like, this is going to production, or something very close to this is going to production. That’s what I would call shadow design.

So we still want to talk with them, and we still want to invest time in design in a collaborative way. Like, is this meeting the business needs? Is this addressing the market that you envision? Is this technically feasible? None of that counts as shadow design.

That’s just what we do as a team when we’re collaborating and doing design. But what I want to call out is, like, I’m alone designing a screen that’s going to go into production. Boom. That’s what we don’t want to do unintentionally. Yeah.

A common theme with everybody we talk to. I feel like on this show, too, is like having empathy for people you work with, not just for customers and people you do design for or research with. And I think that that’s really important here. A couple of things that came to mind. Number one, I always tell people, remember most people in your organization, most people in the team you work on, in other teams you work with are not intentionally malicious.

They are not out to get you. They’re not out to steal your job. They’re not out to undermine you. Everybody’s really just trying to do their best work, right? So, like, starting from a place of understanding that the other thing that came to mind is there’s a lot of design adjacent people, is, the way I’ll describe it, product managers, engineers, marketers, they can do design, but maybe they’re not trained to do design at the level we would expect for production.

That doesn’t mean they can’t participate in design. I think that’s what you’re suggesting. That’s what it sounds like to me, is we’re not suggesting anybody stop participating in design. We’re simply saying be in the intentionality about where and how that’s happening. Because the third point where, again, I’m trying to place myself in the shoes of somebody, like, if I’m an engineer and I’m being asked to just design stuff, most people don’t find joy and comfort in doing stuff that they’re not at.

Especially I feel like if I’m an engineer and I sit here and I go, look, I’m not good at design, and I’m being asked to do this, it’s probably a really uncomfortable part of my job, and likely I welcome a partner in that. I probably still want to participate in it because I like having an opinion. Everybody does. And those are actually extremely valuable, by the way. You should work with your development and other team partners for quality design.

But just keep in mind, these folks a lot of times recognize, like, hey, it’s just not what I’m good at. And I would love somebody to kind of pass the baton to, but still participate in the race, so to speak. Yeah, absolutely. We need our product management partners, and our engineering partners in particular, to work with us to make sure that we’re meeting our objectives of the product on all fronts. And a lot of times, great ideas come from engineers who understand what’s technically feasible or product managers who have looked at the competition in detail and see a gap, or we want all that stuff to happen.

And I’m not trying to call any of that stuff out. With this shadow design, a lot of it probably is production design. When we talk about shadow design, it’s just when somebody’s doing it alone, and that’s the end of what’s going to happen. That’s what we want to measure and adjust for. Yeah.

One of the things I’ve found is that as a trained design and research product strategy person myself, one of the biggest valuable interactions that I’ve found in working with those people is that they have an excellent perspective on the big picture, and I’m able to round out the details. So we’re often on the same page already. Right. But they are able to round out the details in terms of effort or cost or market size, and, like you said, like competitive landscape, whereas trained designers are able to get into the details of exactly how we execute the right thing so we can all come to the right thing together. And then designers tend to be extremely focused on the details of executing that.

And that’s where good products can become great products or good services can become great services, and that’s the value you get from having a team and somebody dedicated to do that. Right. And I think that that’s really what you’re driving at. Yeah. I think a lot of what we do also is describing the vision or developing alignment.

That’s a lot of the work that we do. And I don’t know, to be honest with you, that that would get pulled out in shadow design, because I don’t think a lot of people are jumping in and saying, like, we need a vision type now. And I product manager, I’m going to create the vision type by myself. But in any case, that sort of, like, we all want to feel like we’re contributing meaningfully at work. Right.

And I think each of those three disciplines of the triad have areas where we can kind of see the big picture and areas where we can contribute detail, and it’s critical that we’re all able to do that in order to succeed. So that’s great. Let’s all do that for sure. Let’s just not assign somebody, somebody else’s job unintentionally. Right.

Or take a single job and distribute it across multiple people who don’t want to do it and would even raise their hand and say, I don’t think I’m doing this well. Right. Accidentally. Yeah, totally. I’m realizing that we’re kind of coming up to the end of the time we have together, which I need to be respectful of that for you.

And the way that we typically end these things, right. Is, I say, if I forgot everything we talked about and somebody came up to you and said, hey, Audrey, what was that all about? And what would be the way you would answer that question and summarize this chat? Yeah, I think the summary is that we know that a lot of design work is being done within organizations without anybody knowing it by non designers. We will call that shadow design.

We think it’s important to bring that to light so that we know how much shadow design is happening and then employ various strategies to make sure that we can improve the quality of that design work, we can improve the efficiency of that design work, and we can improve the efficiency of the other disciplines that are being leveraged to do design work that maybe don’t want to or don’t like to or aren’t good at design. So I think that’s how I’d boil. It off really well. Said I was here, and I do remember? And I think that’s a great summary.

Thank you. This is awesome. A topic that I haven’t heard anybody else talk about. So super useful. And I think everybody listening to this would at least raise an eyebrow to and likely take action on.

We’re going to have links to the survey, and you wrote an article about this, too, talking a bit more about it. But is there anything else that you want to share with folks, how to get in touch with you, how to keep conversation going, or anything else you want to share with folks listening that we didn’t cover yet today? No. I would love to hear again, if people are going to run the survey or have run the survey, we’d like to collect that and kind of raise the awareness of this as an issue and maybe elevate design teams and improve the success of those ROI of design conversations or change them. So that’d be great.

We’re at designmap.com. If you do find shadow design happening and you get some budget allocated, feel free to call. We’d be happy to help with that. And then the last bit. I doubt that anybody listening to this podcast needs to read this book called what ceos need to know about design.

I say book, it’s like a long pamphlet. It’s a short read, and it’s kind of 101. It’s 10,000 words on the very basics of design. There’s lots that’s oversimplified and left out, but we do find that handing that to heads of product ceos can be helpful in just not having the conversation about why don’t the wireframes have color in them? We can start at least a basic foundation of shared understanding, and the survey is mentioned in the book as well, so maybe that could be helpful.

Awesome. Those are awesome resources. We’ll have links to all that stuff, links to where folks can find you on social media, on the Internet, and continue the conversation, ask questions if they want. Cool. Thank you so much, Zach.

It’s definitely talk to you and I’m excited to get this idea out here, out there and help all design organizations hopefully get a little bit more leverage. Likewise. Love having you on. Appreciate you coming back for round two and yeah, cool. So all right, everybody, we’ll see you next time.