Webinar
Transcript
Jeff Gothelf:
Good morning, good afternoon, good evening folks. Welcome once again to Sense & Respond's webinar series. Super, super excited to be doing this. We took a couple of months off since our last one. We had the holidays and we had the ramp up in January, but we're super excited to be back this month with another fantastic webinar. We're glad that you can join us here. Joining me today is Audrey Crane, who I'm hoping can start her video.
Audrey Crane:
Yes.
Jeff Gothelf:
Excellent, fantastic. We had some technical problems in the rehearsal, but there's Audrey. Audrey's joining us. Hey Audrey, how are you?
Audrey Crane:
Good thanks. How are you Jeff?
Jeff Gothelf:
I am well, I am well. I know it is the beginning of your day in California. It is the end of my day here in Barcelona, Spain, so I can tell you from the future that it's been a really good day.
Audrey Crane:
Fantastic, thanks so much.
Jeff Gothelf:
A great way to start the day by me just letting you know that it's going to be a fantastic day all ready. We're super excited to have Audrey here. Audrey is a veteran design leader and a designer, and the material that she's been putting together for her new book, What CEOs Need To Know About Design is what we're going to share with you today, which is really about really how ... Everybody seems to get the sense that they need design, that they want design, but actually finding an organization where design is a strategic player in the organization, where designers have a seat at the table, where they're having meaningful impact is still sadly, not, it's not the default. It's still the goal for many organizations, so we're going to talk about that today.
A couple quick words before we start on this. I'm Jeff Gothelf. I'm one of the founders of Sense & Respond Press. You can see all of our books at senseandrespondpress.com. The slide that's up on the screen right now is a really good indication of the kinds of books that we are publishing. Most of these books are out. In fact, The Government Fix just soft launched in the last week or so and Audrey's book, What CEOs Need To Know About Design is coming out soon. Our last webinar was with Elena Astilleros. She's finishing up The Invisible Leader, the Agile facilitation book, and so we're getting all these out there. If you're interested, hop on over to senseandrespondpress.com to get a sense. These are short books, focused on very practical, tactical information for leaders and aspiring leaders. So, that's us.
On the next, you'll get a sense really more specifically about the book that Audrey's writing for us, What CEOs Need To Know About Design. If you're looking to get more details about the book to find out when it's going to come out, we've got a Bitly link designed for CEO, so bitly/designforceos. If you go there, you'll get to our landing page, you can sign up to find out when Audrey's book is going to be coming out. And with that, I've neglected to properly introduce Audrey so I'm going to do that now.
Audrey Crane is joining us in California. I'm going to tell you all about her, and then I'm going to shut up and let her do all the talking. Audrey is a partner at DesignMap where they design complex digital products for B2B clients Docker, Salesforce, Schwab and eBay. She started in tech nearly 20 years ago at Netscape as an executive producer at Netscape. That's funny, I started roughly about that time at AOL.
Audrey Crane:
Oh, we worked together then.
Jeff Gothelf:
Yeah, in some capacity I'm sure paths crossed even 20 years ago. For six years she worked at Dubberly Design Office with clients Sun, and Palm, Stanford, Revolution Health, which is an AOL founder spinoff I think as well, right? So, interesting small, small tech world even in the US, and Opsware. She's also served as vice president of design at The Magellan Network, where the team won the Nielsen Norman Group's Top Ten Application UI Awards. Audrey studied Math, English and Theater, an interesting combination during her undergraduate work. She studied design at UC Berkeley and the California College of Arts. You can always find Audrey on twitter @audcrane, A-U-D-C-R-A-N-E.
Before I hand over fully to Audrey, two things, three things actually I want to point out before we get started. Thing number one, if you have questions for Audrey, please put them in the Q&A module. At the bottom of the Zoom interface, there is a Q&A module, or at least that's where I see it on my screen. If you have any questions that you'd Audrey to answer after her presentation, please put them in there. If you put them in the chat, I will find them there too as well, but I try to keep track of them in the Q&A module. So, please do ask questions, we've got lots and lots of time for that.
Second, we have a hashtag for this so if you are tweeting about this, I'll put it into the chat right now, it's #designforleaders. If you're tweeting about this, please use that hashtag. That'll help us track the conversation. Then lastly, if you signed up but you have to leave early or for some reason something happens, we are recording this and we will post it to the Sense & Respond Press YouTube Channel, as well. If you go to YouTube and search Sense & Respond Press, you'll find our YouTube channel and we'll post it there.
With that, I am going to give it over to Audrey to run the presentation for the next 15 minutes or so. I'm going to mute and hide myself and I said, please don't hesitate to drop some questions into the Q&A module. Audrey, it's all yours and I'll see you on the other side of this.
Audrey Crane:
Thanks Jeff. Clearly we have not had enough beers because there are more paths crossing than we knew about in the last [hahaha 00:06:17] years. We'll have to remedy that soon.
Jeff Gothelf:
That's my favorite number, hahaha.
Audrey Crane:
Thanks so much. I told Jeff a week ago, I think, that I had the nightmare where you go to school without your pants on but in my nightmare, Jeff was introducing me while I was madly creating my first slide to share with you guys so I'm really glad that that nightmare didn't come true here today. We're going to talk about what CEOs need to know about design just for 15 or 20 minutes, and then we'll turn it into conversation and question, but wanted to explain the genesis of this book.
This guy with the big smile calls us at DesignMap a couple years ago and he said, "So, I'm the CEO of this company, it's about 200 people. I came up through engineering, so I understand technology over my time here and through various studies. I've learned what I need to know about running this business. I understand operations and finance and HR, I get marketing, I definitely understand sales." It was a sales tool, I think you could tell by his smile, "But I don't understand design and I don't ... I know that it's really important. That's what I keep hearing, is design is the thing to make businesses successful, but I don't know what I should know or how I should learn it. So, I'm wondering if you guys can help me."
I thought, holy smokes, I wish more people called and asked this question but also, what do I tell this guy? He doesn't want to learn Sketch or Photoshop, right? We're not going to send him to General Assembly. We wish all business leaders were asking us this question and if they did, what might we say? This book is put together to answer that question. I started the work by reaching out and contacting a bunch of business leaders who were great design advocates and asking them, "What do you ... How did you learn about design? What do you think design is and what is it for?"
It was really interesting to talk to them. This isn't exactly the folks. There's a designer in there that'll be offended if he's on the call. But, what was really interesting is that they might be really true believers in the way that they would say, "Look, my last company got acquired, I attribute ... I don't think that would've been possible without the great design team that we had." They could talk really knowledgeably about what their design team brought to the table and then in the next breath they'd say, "Well, of course all of our product managers have Balsamiq and make a lot of wireframes," because the designers only work for the first month on the product, and then they go away or something that, and feeling that was actually ideal.
It was interesting to watch, to see this pattern of gaps in people's understanding of design, or at least what I wish they understood about design, so that's the genesis of this book. I think there's probably a lot of designers on the call because the people that follow Jeff and I are probably mostly designers and there's going to be some 101 level stuff in this book and in this talk, but hopefully it creates a level of understanding of design that is something you might want the business leaders that you work with or the CEO that you work with to have. So, today my I talk about what I'm talking about when I talk about design, and then three common mistakes that I see and one, not exactly one tip, but a set of tips and then we'll switch to questions.
I must put the, "What you talking about Willis," slide up here but that I thought, I don't know if every culture understands that. But basically when I'm talking about design, whether your business sells to consumers so it's B2C or it sells to businesses, B2B, there's a customer, a person, a user at the end who engages with your digital products. In fact, they engage with your company writ large. So, somebody in the company is making decisions about what people want to do, what those customers want to do, how to prioritize the things that they want to do, what data and functionality should be available to help them, and then a series screens that best make that possible. That's what I think of when I think of design, the intentional crafting of another person's experience.
Often when people think of design, they're really thinking just about what you can see, especially in digital products. They're thinking about just fonts and colors, but there's this whole other world, right? There's the work up front to map out what the big ideas are and which ones you want to tackle. But if you really want to make an impact, I think it makes sense to be intentional about the entire experience rather than just on the surface side like just a button or on the strategy side, just a big idea. So, a designer's job is to elicit intent from both the businesses and the customers or users or people depending on where you are in that Twitter fight right now, to elicit intent and then design within constraints to optimize for both of them.
This model is from Jesse James Garrett, it's usually vertical. There are new models, perhaps even more refined models but what I about this model is that it's really foundational. Every designer knows this and if we're trying to create a shared vocabulary and understanding with business leaders, I think it's nice if we can all know this basic model, and it does a good job of explaining that design isn't just surface, and it isn't just strategy. So, most often design for a software is split into two main areas. First, designers work in their product team to come up with big ideas, hopefully about how your company's technical capabilities can be leveraged to help users, so that's scope.
Then they create structure through things workflows to describe how the product actually helps them, and then organize that information and functionality into the series of screens, and that works is called interaction design or user experience design. It's very funny imagining at least 50 designers on the other side saying, "No, it should be called something else," or, "It should encompass other things," but if we're just again, trying to create a shared baseline of basic information, then I think most people agree that this is okay. Then ultimately, those screens have to be presented in a way that enhances the user's understanding of information and the functionality available, and upholds brand standards. This work is called visual design, or interface design. So, where one was interaction, how it acts, then we have interface, how it looks or more often, visual design. This is most akin to graphic design, but not exactly the same. That's what we're talking about, and now I want to switch to the three mistakes.
When I work with clients who are going digital, which is everybody, because of digital transformation, or building software products and maybe that's their bread and butter, I see three pretty common mistakes and misperceptions. First there's a disconnect between what they think design is for and the real opportunity to move the needle for the business. Second misperception, that it's just colors and fonts and third, drastically understaffing their design team. I'm going to dive into those a little bit more.
With regard to the first, a disconnect between what they think design is for and the opportunity to make their business more successful, there's just tons of data to show that design makes companies more money at the end of the day in both top line and bottom line. I'm sure that most people have seen these, but I just wanted to collect them all in one place. There's this kind of, it's almost an old chestnut at this point from the Design Management Institute, this design value index study that shows that design-centric companies outperform the S&P 500 by more than 200%. There's a couple more good ones.
More recently, there's this McKinsey report on the business value of design. For all of these things, they usually create an index so they say, "Here are the criteria by which we're going to call a company a design-centric company, or a certain level of design-centricity," and then they look at that those companies' performance over time and they see how they do. Obviously we see an increase in revenue, total return to shareholders. There's lots more stuff in this McKinsey report.
Then there's Forrester, The Total Economic Impact of IBM's Design Thinking Practice. Here they actually did a deep dive into IBM, which has been investing significantly in design. They looked at the ROI in design over the last three years, they saw 300% return on investment. The thing I love about this report is the index is really rich. There's lots of great data in there if you want to flip to the back and dive into the numbers, and this one stands out for me, it just makes me cringe. So, 10% is the number of projects that returned no profits, or never reached the market before this investment in design. I'm not sure why they call it design-thinking at IBM, but it encompasses design writ large. So, the number went from 10% to 2%.
That means that before, 8% of all the stuff that IBM was building was not reaching the market or was not profitable at all. If ever there was an argument to get engineers on board, with getting designers on board, I think that this would be it, the fact that 80% of their blood, sweat and tears is completely wasted because either it wasn't well designed, it wasn't tested with the market, it wasn't agile enough. That's a good one, but there's a lot more good detailed numbers in the back of this study.
Then most recently, there's this InVision report. InVision actually surveyed 2,200 companies, and then they ranked their maturity level based on how design was used in organization. At the highest level, companies who had design most integrated said that design had a positive impact on revenue, cost savings, valuation and there's a bunch more stuff in here. I don't know, it seems this black background with the pink and purple illustration is the way to make these reports, I don't know.
That's kind of it, and once I start to share with business leaders some of these numbers, and it seems like a new report coming out every couple of months, they start to understand, "Oh okay, it's not just design because design is the new black, it's designed because it's going to really substantially move the needle for our top and bottom line." It changes the quality of the conversation and designers don't have to demand that they're important so much anymore when the numbers are proving it.
The second one is the misperception that design is just colors and fonts. I was actually just having lunch with Peter Merholz and he was telling me that he feels the most common mistake is that people either think it's colors and fonts, or it's design thinking, but it's not this whole thing. It's pretty amazing how pervasive, especially the colors and fonts thing is given that interaction design has been around for about as long as definitely I think I've been working in tech, for about 20 years. So, you can imagine how just addressing one or the other, or bookending these short changes the value of the work that's happening.
I think it's important to pause here and note that it's very rare to find a designer who can do all this stuff. That's another thing that I talk to business leaders about, is if you post an ad and you say, "I want a designer who can do interface design, interaction design, I want them to be able to do marketing design and logo, and they should make our business cards," you're showing the world that you don't totally get it. It's pretty rare that you're going to get somebody who can do all this stuff.
Anyway, my point is that addressing just one or the other of these short changes the other. The thing is not that shit happens, but design happens, right? Nearly all the time in software, even if, I mean really nearly all the time in software, even if there's no design team per se, there's still plenty of design going on. It might take the form of product managers making wireframes or screens in PowerPoint or Balsamiq or business analysts writing long requirements documents. Sorry mom, I know you're ... Or engineers working and doing the design themselves as they go, sorry, dad. I have my business analyst mom and my engineering dad on the call I think. So, these people doing design, right?
It goes without saying though, that just because someone knows how to use PowerPoint, or Word, or knows JavaScript doesn't mean that they're trained or skilled in the best ways to design software, any more than my driving to the supermarket qualifies me to drive for NASCAR. That's a nice illustration that probably, or a nice animation that probably looks terrible on the webinar, but you get my point. So given that design is happening, the critical question is whether the design work is being done intentionally by skilled designers who add value to your product or your business, or not.
I don't know why my slide is not moving forward all of a sudden. That animation killed everything. That was the end of that point, so I'm going to just escape out of presentation mode and see if we can do this again. There we go. So, design is happening, and it's just a question whether you're really intentional about the design work that's happening and using skilled designers so that you ensure your greatest opportunity for revenue and cost savings or not.
Finally, I see companies all the time who hire one designer and declare that they have design, no matter what they're building, no matter how many engineers they have, and this isn't true anymore than hiring one engineer would mean that you have engineering right? Different designers have different skills and a design team should have the capacity at least to touch nearly everything a user interacts with. So, a ratio is somewhere between one in five, or I think probably more commonly one in eight designers to engineers is about right. That varies of course, depending on the type and the complexity of the product.
That's it for the three mistakes, and then I have this set of tips on giving feedback. I'm surprised ... Sometimes when we work with our clients with the business teams we say, "Okay, we've got a list of topics that we could address or help with, and you guys vote and let us know what you most are interested in talking with us about outside of our alongside our projects to make the projects more successful," and I'm surprised how feedback always comes to the top of the list. I don't know why. I'm curious if other people have thoughts about that.
I guess one thing is that it happens in a group, and another thing is, I think that people feel like they need to have a really solid knowledge of design. So, you're in a group setting and you're the business leader, the CEO, or a VP or a very senior person, and you don't know about design and all these people are watching you talk about it. We wouldn't have an engineer come in and show a bunch of code and expect the CEO to know about that. Maybe this is why, but certainly we want people's feedback. Sorry, I notice this button keeps coming unbuttoned. I should've put a safety pin or something.
Okay, I wanted to emphasize one thing before we talk about feedback, which is that initial direction I think is what's most important for designers to get from business leaders. My mentor Hugh Dubberly talks about feed-forward as opposed to feedback. So, these ideas, vision, goals, conversation about desired impact and outcome, feed-forward before the design work even happens. Initial direction can take many forms but ultimately, if a business leader's job is to bring the very best that the designers have to offer to the table, then those designers needs to be engaged and the better that business leader can describe a picture of their vision and the outcome they're seeking, the more successful they're going to be.
But at some point, the designer is going to make something and you're going to be called on to assess the work and give feedback, right? If you're worried that you need to know something about composition or color, I don't think you should be, there's a couple of tricks to doing this effectively. It's almost cheating once you figure it out. First and foremost at the beginning of feedback sessions, designers should help everyone by recapping how they got to this point, and then explaining what you're doing today and specifically, why. What feedback you're looking for, and what feedback you're not looking for.
So you might say, "I am interested in feedback on whether this successfully helps people accomplish this task. I'm not really worried about colors or typos at this point." If you don't provide this, if the designer doesn't provide this, then the business leaders should ask for it. The risk of not doing that is that the designer shows something, and then the business leader might say, "Oh, I love that color blue," and then designer's like, "What the ... I don't care about the blue. That wasn't what I was asking for it." But if you wait until you show the work before you explain what kind of feedback you're looking for and not looking for, then you seem kind of defensive when you say like, "Oh the blue, forget about the blue, that's not ..." and the business leader looks not great for giving feedback on something that they didn't need feedback on.
So, you might sound defensive, they might sound clueless, so teeing it up is really important and I think business leaders should ask for things to be teed up this way. I have never seen this happen in the wild without prompting where a business leader says, "What are you looking for? What are you not looking for?" After that, then we'll look at ... Then the designer at the end of the meeting should say, "Here's what we'll do next," so here's the next thing that's going to happen.
Secondly, help designers manage the feedback process. This whole feedback wrangling thing is actually really complicated and it's generally not something that designers are taught in school. Dealing with lots of people who are all weighing in with strong opinions can be really difficult. If your designer isn't good at this, then what you end up with is design by committee, the old design by committee, which takes something that might be really interesting and run off all the interesting bits until you just have this ball of mush that nobody could think of anything critical to say about. That's not necessarily the best outcome.
So, please help the designer by making sure that they have a chance to talk about, by asking them, what did you think? Why did you do it this way? What other things did you try? Especially if they're quiet, which sometimes they are because you know, they are spending all day in front of a computer. Then secondly, help them limit the team to the people that will provide uniquely important feedback. It's really easy for someone to say, "Oh, I'd to come to that meeting," and then pipe in with their opinions and pretty soon you end up with 10 or 12 people in the room, and sometimes that's necessary.
Sometimes there really are 10 or 12 people with a unique perspective that really will bring something valuable to the feedback session. The flip side of that coin is very difficult for a designer to say, "I don't think we need you in the feedback session." So, one way that we can ask business leaders to help make sure that the design is moving quickly and is as good as possible is by asking business leaders actually to help manage the number of people that are in those sessions and making sure that they're the right people.
Finally, remember that this isn't about you. It's not about your knowledge of design, it's not even exactly about your opinion, right? It's about being a partner that gets the best work from your designers. When you stop worrying about forming and conveying your own opinion and instead you focus on the intent, you open up the designer's training, skills and abilities. So, you asking, who's using this? Why are they using this? In what context are they using this? How did the designer arrive where they did? What else did they try? Why did they pick this one to show? Almost like a Socratic method of feedback can have a bigger impact than feedback where you're just saying your opinion.
Now, of course a business leader's opinion is going to be formed by the needs of the business, their understand of the users, so I'm not saying you're not allowed to have an opinion. But I am saying, if you're concerned about giving feedback and your goal is to get the best from your designers, a series of questions can be really, really productive. And finally, it's okay for something to seem good, at some point letting it go and saying, "I feel we understand each other. We have the same understanding and intent, we're moving on the right path. I don't know, it looks great to me," rather than feeling forces me about design just because the team feel obligated to ask you, especially later in the process.
I'm going to skip that slide, sorry. I'm going to skip this whole section, because that's it. I just Want to thank Chuck Moore, one of my partners who have provided a lot of help with this and also [Eddie Shea 00:30:07], who is an amazing design coach that used to be a designer for us who helped with the illustrations. I think that's all, and we can switch to questions.
Jeff Gothelf:
Awesome. Audrey, thanks so much, that was great. Good insight, and hopefully some food for thought for the folks. The nice thing is that people have started populating the Q&A module with lots of questions for you so without any further ado, I'm going to start to work through those questions and hopefully, well, let's see how it goes. And again folks, if you've got questions and you're putting them in the chat, I can see them. I'll certainly get them answered, but if you put them in the Q&A module, that's actually where I'm tracking. That's like my backlog if you want to use the Agile term here, but I do see them in the chat as well.
So, we'll start over here in the Q&A modules. The first question's up. You talked a lot about the ROI of design for companies. There were a few different charts, the pink and black charts of design ROI. Sean wants to know, how do you associate the design work with the company's ROI? In other words, how do you know that it's the design work that moved the needle?
Audrey Crane:
Each of those reports do that in a different way, so it depends on which methodology which companies using, I think if you're ... If I were you and I was planning to share one of those reports with one of my business leaders, I think the first thing that I would do is try to understand my own company metrics, where we're doing well, where the company has set goals that are higher and they're working hard to achieve them, and then I would look for a parallel in the report. Then I would focus my effort on that thing. It's about connecting the dots, right? Your business has business goals and there's these reports that describe how people achieve business goals. So the question is, what's your company's business goal? Which report best matches that? And then, what work can you do to connect those things, or to make an argument that can connect those things? What do you think Jeff?
Jeff Gothelf:
I mean look, the example that I think most designers have heard by now and the one that comes to mind is, I think it's Jared Spool's $300 Million Button story where they talked about simply rearranging the position of certain buttons increased the task completion rates, which ultimately led to revenue and sales going up. I think ultimately that's how you tie this in, right? You say, look, we took a workflow that currently delivers this much ROI, whatever that is, and that ROI could be sales, it could be productivity or efficiency.
I was talking to a team today, I was working with a team earlier today and one of the things that they were struggling to quantify was this, it's the exact thing, it's the ROI of their design efforts. They were working on a tool for internal teams and I said, "Look ..." Specifically with customer service. So organizations, particularly this is a large organization. They know exactly how much every customer service called costs. What's the average duration? What it costs us to answer it? And so, if you can prove that you improve ...
If you can show through analytics that you reduced, that you solved the problem in the application in the software that then reduced the number of calls to the call center, you can directly quantify that in dollars, euros, whatever currency you're using to say, "Look, we've reduced the call center call volume by 12%, and that adds up to $50,000 a month," or whatever it is. I believe there's always a way to quantify the benefits. I think it's isolating, compartmentalizing the impact of design that becomes a challenge. But if work is simply to ... If you can find those compartmentalized areas where there's a workflow that's delivering X amount of return on investment today, and then we change the design of that workflow and now it delivers X plus Y, that's a good way to do it.
Audrey Crane:
Yeah, and I think that the key is for designers to be business minded about their approach. I think the $300 Million Button is e-commerce, right? So, if you have a B2B tool, don't show up with that story and say, "Look how important I am," because you're missing the boat. And similarly with the call center thing, look at the top three calls, the reason for the top three calls, those call centers totally have that, right? Then take small steps towards real measurable impact that people will Understand well. Similarly with those reports, bring ones or data that feel relevant to your company. Don't just email over that IBM Forrester thing and say like, "Oh, you should read ..." it's like 30 pages of [inaudible 00:35:14].
Jeff Gothelf:
Cool, next question. Why do you think design in general is being neglected normally in the Agile world, and what do you suggest to show the value it brings to make those outcomes a reality. What's your on the challenge of integrating design and Agile, and maybe ways to improve [inaudible 00:35:38]?
Audrey Crane:
This is kind of a old and interesting conversation. Cooper has weighed in strongly as Alan Cooper is one to do. I personally have come to a place where I believe that it's really just a question of teams working, engineer and design teams, along with product working really well to together. There's a couple of ways to do Agile, right? I think Jeff Patton says the only way to do it wrong is to get dogmatic about it. He has a better way of saying that, a very pithy way of saying that.
And so, I think if design is getting short changed in an Agile process, I don't think we should be blaming the Agile process at that point, I think we're past that. There's something about the way that design is being valued or the way that the design and the engineering team in particular are working together or not working together. So, I think we have to stop blaming Agile and the idea that either Agile is bad for design or we're not doing Agile right, and we need to start thinking ... It's hard to write and talk about because what I'm saying is that what's going to be right is going to be different for different companies.
In fact, I think what's going to be right it's going to be different, even within different teams. This is maybe why [Marty Cagan 00:37:03] really advocates for teams to stick together for the long term, because they figure out these little fine details of how they work together, how they bring the best that everybody has to offer to the table. I don't know if that was cheating or a non-answer, but I think we have to look beyond that Agile problem with designing value personally.
Jeff Gothelf:
Yeah, I agree as well. I think at this point nearly 20 years into the Agile Manifesto and certainly the wide adoption, we have to figure out how to work together. I used to blame it on Agile being birthed by tech, software engineers invented it on a mountain somewhere.
Audrey Crane:
[inaudible 00:37:50] actually.
Jeff Gothelf:
But you know, designers were there. We could blame on that forever, but the reality is that it's here. It's here to stay for a while, at least until the next big management flavor comes along, and what Marty says I've seen firsthand as well. The teams that I've worked on and worked with that have stuck together for a while have learned to build a shared vocabulary, a shared understanding of how they work, who does what, their limitations, their strengths. They make it work ultimately because they trust each other and I think the more the teams trust each other, the easier it is to collaborate, and the easier it is to let the recipes go, and I've seen that firsthand as well.
Audrey Crane:
Totally, and you can't ... The way then to make it not work is to try to create a recipe out of that team, codify it in some way and then put it on a different team and say, "This is how you guys," which is why Agile is a framework of guidelines and not this strict rules and processes.
Jeff Gothelf:
Yeah, and that's always interesting to. There's this secret sauce that this team has, and then how do we replicate then? The whole scaling conversation then gets involved and it just gets uglier from there.
Audrey Crane:
Yeah. Well, you're making me think of the, what's the Google ... There was a interesting Google report or white paper or something about great, high performing teams. You remember that?
Jeff Gothelf:
Yeah, yeah, yeah. I do, I do remember that, yeah.
Audrey Crane:
I think trust was one of the integral things and that they were sticking together for the longer term, and so maybe that's the place to look.
Jeff Gothelf:
Yeah, it works, it works. Let me ask you this question because I've seen this in my career. I hear this question a lot and I'd love to get your take on this. The question is, do you see an overlap between the roles of product manager and product designer?
Audrey Crane:
Totally, yup, yes. When the business leader, I think he was a CEO said, "Oh, we have product managers making wireframes all the time," and I was like, "What? We just have 45 minutes worth of conversation about how important design was and you have what?" The example he, I said, "Why?" The example he gave me was, "Well, we had a screen that was going to take a long time to load and like I said, the designer team was gone, had moved on and didn't know that that screen is going to need, that there was going to need to be a loading screen that existed. And so, we just had the product managers do wireframes."
I don't love that. To my point earlier, design happens and I can't remember who said the alternative to good design isn't no design, it's bad design. So, do you want somebody who's skilled at doing that, who's trained at doing that, who's experienced or do you want somebody who's not? But interestingly, I gave a talk a couple years back to a product management group and I was trying to answer the question, what is the right input from product managers to designers? I had worked to a product manager that I loved in San Diego. She's fantastic, and what I saw from her was that she was really bending over backwards to try to not be prescriptive to the designers. So, something really simple. Then they click and the data gets returned and they see the next screen.
She could've just said that in her story or requirement document or whatever, but instead she was like, "Well, there's some way by which the information might change on the screen." She was really such a great advocate for design, and she was killing herself to do that and it felt silly to me. So anyway, I contacted 40 designers and I said, "What's the best requirements in any form, don't care like story requirement, purity, whatever that you've ever received?" I looked at what I got back for patterns and I wish I could tell you there was this very clear pattern, but there wasn't actually. The clearest pattern was that there was no pattern and I think it gets back to the question of Agile and teams working well together.
The right input from a product manager depends on the product manager, how well they understand the domain, what their experience and training is, and the right ... It also depends on the designer and what their capabilities are, and what they really want. So, there is overlap and I would like some neat like, well, this is where it should stop and I want to say, don't draw stuff if you're a product manager. But, at some point it gets silly. If that's the best way to describe intent or if your designer works really well with that, then you should trust us. So, I do think there's overlap and I think that figuring out and untangling that overlap is a really interesting question that we are nowhere close to solving unless it's an individual solution.
Jeff Gothelf:
Yeah, and again, I think this comes back to our previous answer as well. I think that designers and product managers that don't trust each other spend more time defining the boundaries between their, and their Venn diagrams than designers and product managers who do trust each other, they care less about that. I've had fantastic whiteboard brainstorming sessions with product managers and engineers where everyone's picking up the marker and erasing and doing things together, because we trusted each other. We'd been working together for six months on the same problem really trying to figure it out. But that takes time, and it takes commitment, and it takes patience. But until that point, I think you're right, I think we need some kind of an initial boundary that eventually we will blur.
Audrey Crane:
Yeah, and I think well, two things. One is, I think if you feel confident that you're valued, then, let's imagine a designer feeling like their contribution isn't valued. Now I'm getting this drawing and I'm like, "What the hell? You don't value what I'm able to contribute, and I've just lost my chance to make a meaningful contribution." And similarly, the product manager can feel the same way. The designer's like, "No, no, no I got this. I don't want anything from you." I think that that's a really important thing, and I just lost my second thought so nevermind.
Jeff Gothelf:
All right, let's shift gears just a little bit here. On the topic of collaboration, do you encourage collaboration and in particular, the question here is around brainstorming with stakeholders.
Audrey Crane:
Yes.
Jeff Gothelf:
Yes, and?
Audrey Crane:
I feel all my answers are, it depends. I really the Google Ventures Sprint book with the very structured brainstorming. If you read that book, I think he even talks about we do all this brainstorming, but nothing ever came out of it and I think it's useful ... Brainstorming by itself, especially with stakeholders is useful just to help them two things. One is to help them understand, oh, this is kind of hard figuring out what goes on that screen. It's actually not something anybody could do. And two, it helps the designers see what baked in expectations are in their head that maybe they haven't explained already.
I think that that can be really useful, the risk is that it feels fruitless in the end unless you're really explicit about, "Here's what we learned from this and we're not going to use your drawings, but we understand that you have this assumption or expectation." So, using the Google Ventures Sprint, and we've really DesignMap have started to slice that up and say, we're just going to take like Tuesday and do that, or we're just going to take this thing, and that thing, and that thing and put it together, which forces you to be pretty rigorous about what you're accomplishing and why. I like that better. It's really just a question of clarity of goal, and then making sure that you accomplish it.
Jeff Gothelf:
Right on, and Look, I think that again, just to share a little bit. In my experience, when you do involve stakeholders in those conversations and the end result, whether it's a design, or an interface, or a workflow or some kind of a decision reflects their input, even if it's a fraction of their input, they see a fingerprint in the work, they advocate for it, they defend it, they're bought into it. There's a much greater ownership of the work by that stakeholder and that can be very valuable, particularly large organizations where there's a lot of politics and somebody else might have a different agenda. So, I've seen that work well.
There's a follow up here that I think is really relevant to this conversation as well, so let me ask it and see what you think. When you do get these folks into these types of, these stakeholders, these leaders into these types of meetings, brainstorming sessions, et cetera, collaborative sessions, what are some interview techniques or what are some techniques that can be used with these leaders to get them to participate, to get them to be a good part in this?
Audrey Crane:
I imagine this is being asked a designer who has a leader that doesn't participate. They do these things, and they just show up but they don't participate.
Jeff Gothelf:
Right.
Audrey Crane:
I think again, being really specific about what you're trying to accomplish, so now we need everybody to do X and Y. A very open ended brainstorming session I would only have with a team like what you described before Jeff where you say like, "Oh, we all knew each other, we've been working together for months, we all ..." But in an area where there's a bunch of stakeholders, I don't work with them that much, this is a one off thing, I would be very structured with my brainstorming session, what I'm trying to accomplish, what we're going to do.
Maybe we change, maybe we get in the middle of it and really like, "That didn't work. Let's do this other thing," but that being really, really structured about it. Part of that structure is okay, everybody do crazy eights. Fold your piece of paper in eighths and draw the same idea eight different ways. I have been in session where the CEO was there and he just wasn't doing it, the nice thing about being a consultant is I can be the asshole in the room and say like, "Joe," we'll call him Joe, "I noticed that you're not doing it." And he says, "Well, I've already worked on this forever, I don't need to ..."
The best you can do is call him on it, so create structure so there's not an easy way out. Then if there's only a hard way out and they're just not participating, then I think you should go ahead and call them on it. Not call them on it in a mean way but just say, "We would love your input here. Then I would follow up and say, "I think it's really counterproductive for those folks to show up in a meeting and then not participate. It can show lots of things, none of which are particularly good. I know you're super busy, I really appreciate you coming. I think in the future, it's kind of a struggle if you're not participating. You can imagine how others might see that. Next time, I would love for you to come if you can be all in and if not, then maybe your time is better spent answering the emails that you were answering in the meeting anyway, because it detracts from the energy in the room," or something that.
Jeff Gothelf:
Look, I've been there. I've walked into rooms where there certainly have been a couple of people that were this.
Audrey Crane:
Yeah, totally.
Jeff Gothelf:
Like, "I'm not participating no matter what you do." And look, you try. You try to get them to buy in at a certain point, but afterwards there should be a conversation. Maybe don't embarrass them in front of everybody else. Okay, we have a few more minutes and there's a few more questions I really want to-
Audrey Crane:
Jeff, I had one more thing. I did remember [inaudible 00:50:37], that the overlap between product managers and designers. One thing that we like to do as a pre-mortem and that I think this is standard pre-mortem is, let's imagine this worked really, what happened? Let's imagine it was a complete disaster, what happened, and you talk through those things. But, another way that I learned to do this was to list everybody, basically make a matrix. List the team members, their title and their role and responsibilities, and then hopes and fears.
The role and responsibilities thing is really helpful because then if the product manager, if you haven't worked with them before and they say, "Part of what I'll be doing is making wireframes," or the designers says, "Part of what I'll be doing is writing requirements," then you can get it out on the table in the pre-mortem, which is way easier, just saying, don't give me feedback on typos. It's way easier to have that conversation before somebody's done something. That's another way to address the overlap between product managers and designers in projects just, hit it on the table in the beginning.
Jeff Gothelf:
Got it, awesome.
Audrey Crane:
Next question.
Jeff Gothelf:
Cool. I want to get ... There's a couple good ones in here I'm hoping to get before the top of the hour. I suspect I know the the background behind this one but the question here is, in your experience, has it helped to have user testing and/or user research data to back up design decisions? My suspicion is that the question here is a little bit based on people dismissing qualitative research as anecdotal, you didn't do it right, et cetera, et cetera, et cetera. So, user testing, qualitative data to back up design decisions.
Audrey Crane:
Yeah, sure. Even the word data if that is truly the background, even the word data might cause somebody who's really quantitatively oriented to be like ... Don't even call it data. Get the person there if at all possible, which I'm guessing it isn't. Certainly I use quantitative information to back up, sorry, qualitative findings to back up decisions, and there's a certain point in the process where that's all you have. You can't do it quantitatively and so if I can, I get the person there. If I can't get the person there, I send them video clips, which is pretty easy to do.
That is way more poignant and impactful than any report with data or sticky notes or whatever, because it's a human thing. And I certainly have seen that. I've been in labs in the olden days with engineers where they are like, "Where did you get this guy?" The first guy comes in and then by the third guy they're like, "Okay, these are people, they're not stupid, they're getting frustrated. Okay, we'll change it."
Jeff Gothelf:
Yup, cool. Hey, I want to get one more in before we finish. I think this one's really interesting. How do you help convey the importance of continuing good design throughout a product's life? The person here is asking, specifically we've seen a large investment during a large build or a rebuild, but then we see the perceived importance and the funding all but disappear when those same products hit a run state, sort of a maintenance state. So, how do you advocate for design over the entire product lifecycle?
Audrey Crane:
It sounds that's big enough that I think I would look back at the revenue from the products. There's also often costs associated, like there's call center costs, there's maybe the sales team. So, maybe you release this thing and by the end of the year, a competitor has released something else and the sales team is struggling in their demos. I think I would look for business data from elsewhere, so revenue, sales, engineering, spending. If the engineers are doing design, if you're paying engineers to do a design, that is not cheaper than paying designers to do design, and the end product is not as good. So, I would look around the edges for revenue or cost centers, and then use that to argue to keep the support and hopefully have that be part of the conversation when you're designing it in the beginning. We don't burn this on a CD-ROM and then we're done with it, those days are over. So, what are we going to do with this thing? What kind of revenue do we hope to have from it going forward?
Jeff Gothelf:
Yeah, this is actually one of those times where one of the pithy Jeff Patton sayings come in really handy. He always says, "If you don't have engineers, you're not going to get code, but if you don't have designers, you're still going to get design," and sadly it's not going to be good design. Audrey, thank you. Look, we're pretty much at the top of the hour now. I know that as soon as we hit the top of the hour, people are just going to go to their next meeting.
Thank you so much for spending the time and sharing your knowledge with us. This was fantastic. We've recorded this, so it'll be up on the Sense & Respond Press YouTube channel in about a week or so. Audrey's book, What CEOs Need To Know About Design will be out later this year. If you go to senseandrespondpress.com, you can find out all about it and others. Thanks so much for joining us Audrey. A pleasure as always, and we'll see everybody next time.
Audrey Crane:
Okay, have a goodnight.
Jeff Gothelf:
Thanks folks, have a great day.
Audrey Crane:
[inaudible 00:56:15] have a good night later.
Jeff Gothelf:
Yeah, take care. Bye.
Audrey Crane:
Bye.