Making design matter in technology organizations — Thoughtworks Technology Podcast
[MUSIC PLAYING] Hello, everyone. My name is Rebecca Parsons. And I'm one of the co-hosts for the Thoughtworks Technology Podcast. And I'm here with Scott. Hi, I'm Scott Shaw. I'm also one of the hosts of the
podcast. And I'll be doing color commentary today. And we're here to talk to Emma Carter, who has just published a book called DesignedUp. Emma, would you please tell us a little bit about yourself? Hi, yes, so I'm Emma Carter. So I'm based in Brisbane, Australia. So I've moved to the Sunnyside from the UK.
And I'm a principal experience designer with over 20 years of experience, ran my own award-winning design agency in the UK before I moved to Australia, joined Thoughtworks. I was there for eight year. This would be my second book that I've authored now. So that's me. OK, so let's start with the basics.
What was it that prompted you to write this particular book? So there's a few different things that came about from it. So I noticed that lots and lots of designers were are really struggling to get their voice heard. So some of the designers that I've mentored over the years found it hard being the minority [? with inside ?] a tech team. They would have product owners saying, well, we want to do it this way. And the designer was saying, well, actually, the customer doesn't want that.
It doesn't work for them. But no one's listening to me. So I was having to mentor a lot of people through that process of how to get their voice heard and how to bring that data into their conversations. So it wasn't them being-- the designer being picky about the thing that they were trying to communicate, but it was actually driven from customer research and from the data. And then also people that I've interviewed over the years as well who want to become designers who work more in the tech side of things and UX designers, they come from more of a pure design background. And then they struggled with understanding, well, how do their skills fit inside a digital delivery team.
And so from that, I drove the idea of the book. And then the more people I spoke to, the more ideas I got from that. And then came the book. It took a few years.
It took a few years and a lot of interviews. But that was kind of the start of the book. Yeah, I've heard several authors say that no book takes any less than two years.
And it just goes up from there. I'm not sure I completely believe that because I'm very skeptical of all or nothing statements. But it's probably a good rule of thumb. Yeah, and it also depends on your workload because you're trying to do it alongside other things, so managing kids, family, work commitments, and then trying to get a book done, as well. So yeah, it all depends. And then you'll be doing like big stretches of the book, and then nothing for a while, and then back again. So yeah,
it's very up and down process. So then let's get to the next level of detail. How do you explain the value of design in a tech organization? We all know, of course, why tech is valuable, those of us who work in a tech organization. But how do you actually get across that notion.
And what really is the value, particularly in the context of a tech organization, of design, and design thinking? So we all know that design is good for business. There's been loads of articles written about loads of insights gathered. But those organizations are actually driven by design, outperform those who aren't by 290%.
And they've done lots of research into this. But unfortunately, I think many businesses still see-- some of the organizations still struggle with understanding the value of tech. Some organizations still think it's the amount of lines of code that you Write We know that that's not actually the value that tech is bringing. And design has problems as well. So a lot of businesses still see design as being the UI. I've been asked can you come and make my design look pretty? But that's not what design is.
And then some think it's just doing this five simple step process, design thinking process. But that's not design. That won't actually add value to the organization. So design can actually positively impact so many areas of the organization. And not everybody really understands what areas design can actually impact inside an organization and what value that gives an organization. So for design, it could be improving the flow, for example, inside an organization. So taking an internal really clunky tool.
I've worked on a lot of these. And these are clunky tools that people have to endure every day just to get their job done. And it causes a huge amount of waste that's not very nice to use. And then once you redesign that, and you make that flow of work much faster and easier for them, you can actually make their work more accurate. And it then frees up the people's time to then do more valuable work. And that then improves the bottom line for businesses.
And it also improves that flow of work going through. But design can then also be removing waste. So it could be understanding that bigger picture, the bigger process that involves multiple departments across an organization. And that's where you're working with clients to help solve different problem. But it actually expands across whole organization, which is then that kind of comes more into service design. So, for example, a project I was working on quite a few years ago was around solving a problem for members. So it was their members renewal process.
So they thought the problem was actually with the finance department. And that's where the most amount of waste was. But once we've mapped out the entire nine-month renewal cycle, and which included mapping, user journeys' across all of those different departments, understanding the problems, the workarounds that people were having to do to be able to complete their tasks, and then bringing that tech lens in there, as well, to understand, well, OK, these are the processes that people are going through. But then how does the tech underlying that is it the technology that's causing some of these problems? So we gathered all of that data across multiple departments. And it turned out that it was actually the marketing team who suffered the most. And that's because what their amount of work, their time over nine months was actually-- they were doing short tasks each week.
But those short tasks were the same tasks. And they had a workaround to actually be able to complete those tasks. So when you actually calculated how much time was wasted by doing the same task on a regular basis, it was a huge amount of hours that were wasted.
And one of the problems the department had is they said we really want to help our customers and give them a much better experience. But we don't have time because we're doing all of these manual workarounds. So by fixing that, which was actually just a data problem, getting data to flow from one system into another, which actually was something really easy to do, it was going to free up their time and allow them to create more valuable work for their customers.
And it meant they didn't have to employ lots-- more people to solve this problem. They could just make themselves more efficient. So it's reducing that waste. And that's when bringing the data into those things is really important because we actually got them to calculate how much time they were spending on doing these particular tasks.
We were then bringing that data in there, as well. So those things that you could do inside an organization, and a lot of people don't always think that design can solve those problems. But it can then also be about the normal things, so improving a product or service for an end customer. So making a complex process a pleasure for people to use. And making an experience so nice that people actually trust that brand, and then come back, and use that product over again. It could be making the product more accessible, as well.
So if you make a product more accessible, it then grows your market, but also prevents you from launching something unintentionally that kind of unintentionally alienates half the audience. So I've seen that happen before, where people haven't tested on a broad enough set of users. And then when they've launched it, it's actually failed because they haven't considered a huge portion of their audience. So there's things like that that I think a lot of organizations don't really understand. They just think it's coming to make the UI pretty.
And I'm not devaluing visual design because my background is in visual design. Visual design has a huge role to play, as well, because it reduces that cognitive load. And especially with SaaS products, you need to make sure that they're really engaging when they go out to users. So you've got to bring those visual elements into those to make sure they're a success. So going back to your point with design and the value, so a design can add value to business processes, the structure, so having cross-functional teams and making sure you've got the right designers in those teams, help drive the strategy from a customer lens and not just from a business lens. Improve how internal tools work, making the people within the organization have a better experience. And focus on more valuable work. And lastly,
the one that most commonly people associate with design is the customer experience, as well. So design is much more than making a pretty UI. And it's much more than a five-step design thinking process because that is not going to solve the problem at the value. That kind of process improvement, that's a very different activity than we would-- than most people would probably associate with what a designer does because their experience is probably much more on the visual side. And
the consumers of that, the customers in that case, are probably very different, as well. Because you're talking about internal processes. Yeah, but what's interesting is when you're speaking to people inside an organization, so some of the projects I've worked on recently, some people inside the organization are like, well, I expect the technology to be bad because it's an internal tool. But really, the expectation is that they would love it to work like the tools they use in their everyday life when they're not at work. So they want those kind of experiences. But they kind of just accepted that tools inside an organization are just bad. But
they shouldn't have to be like that. So there was a project I was working on a few years ago, where we were actually helping a group of-- there was three different teams. There was three legacy systems. We were bringing them together to create one new platform. And just looking at how they use their existing product,
we were able to just create a much better experience for them. It reduced all of the data issues that they had. There were so many problems with inaccuracies with their data. And that data was going to actually drive policies inside government. So it was really important that data was correct. But because humans we make errors, their old systems weren't allowing for that.
So you're working with those people. And then showing them that this is actually what the experience can be like. Once they experience that, they wanted more, oh, so I can have a really nice experience with my internal tools. And I can have a much more pleasurable experience doing my job and getting the right data in there. But yeah, a lot of organizations don't even think about that. Our industry, the tech industry has a lot to answer for in terms of what I've often referred to as user-friendly designs.
When I look back at some of the UIs, it's like how could we do that to our fellow humans? It's just not right. But it's also-- some of the developers I've worked with over the years, one of the projects I was on, one the dev said, Emma, you need to come and have a look at this. Look at what us developers have to deal with when we're trying to get these components in off of this arbitrary place that we have to go and get them.
Look at the experience. Yeah, there's things like that that the developer experience, just being able to get the tools that you need to be able to do your job. People don't always think about making that experience easy. Ultimately, it does affect the end customer, though, doesn't it? I don't remember if it was in the book or a conversation we had. But you were talking about,
even when the direct to consumer of an internal product might be a developer, that changes the experience that partners and customers have. Do you have trouble getting people to see that big picture? That's where you have to take people along on the journey. Yeah, that story we were talking about was a new platform we were building a few years ago. So they said to me, Emma, we want you to come in and look at the developer experience.
And I was questioning. I was like developer experience, are you sure this is a developer experience? I was, OK, fine. That's the brief. So I went in with the team. And I started mapping out who was going to be impacted by this. So yes,
we were building a platform. We were looking at the APIs that were going to go on that platform. And then rebuilding, making sure the APIs were built in the correct way. But people inside the organization needed to find those APIs to use them. But the people who were finding those APIs wouldn't just be developers.
There would be business people, designers, different developers. Different product teams were going to need to find those APIs and find the right one to solve their problem. And so I started mapping out all of the people who were going to need to come in and actually find this information. And from that, we were able to put a hierarchy together to say, OK, well a business person doesn't need to know all the intricate details of the API. They just need to know what it's going to solve for them.
So let's have different information, depending on who you are when you're coming in to this platform. And then from that, there would then also be customers who would then be consuming those APIs. Well, OK, what does that look like for those people? How can they come in to our platform and find the right API for them. But then those customers also--
that API would then impact their customers. So you have to put together the whole chain of who's going to be impacted by this thing that you're building that you're told is just going to be a developer experience. It's so much more than that. And so it was just mapping it out. And then showing people that these are the people I've interviewed across the organization. And these are the people who are going to be impacted by that.
And then what we did is when we started putting together the platform and putting together our minimum viable product of what this platform was going to be, we tested it on different people across the organization to say, OK, you're a business person. You're coming in here. Can you find the right thing? Does this make sense to you? What's missing? As a developer, you're coming in here to find the API.
Does this make sense? Are you able to use it. So yeah, there's so many different areas that people don't always think about. So when I look at the technology industry designers, as opposed to developers who might know something about front end or developers who might understand something about design thinking, but actual designers, you're still a relative minority within the technology community and within a tech organization. How do you go about this process of education? And how do you steer these organizations to, first, understand the value, and then understand how to introduce design properly into the different products and services that are being developed? I do it different ways, depending on who it is, and what the problem is, and also who the client is, as well. Some people are more receptive than others. But I just trying to find advocates across the organization. So I start off with the team. So
as the minority on site delivery teams, I'll go out and say, OK, we need to go and speak to customers. And we need to gather research. Who's going to come and help me? So it's getting those people on board and get them actually actively involved in speaking to customers and understanding the customers. Some people aren't very comfortable with speaking to customers. And they don't always understand how to speak to a customer.
So they can just come along with you and not say anything. And they can just take notes. They can just observe. They don't actually have to speak. And what I found is that's really changed people's mindsets. Because then when they're developing the experience, they're thinking about it from a customer point of view.
So I had this with a client, where some of their internal developers had been there for years, lovely developers to work with. But one of the developers was-- I guess, what you'd call a stereotypical developer who doesn't like to speak to customers. Never worked with a designer before, completely scared by the whole thing. And he said I'm not very comfortable with doing that. I said, OK, that's fine. But you really need to. It'd be really valuable for you to understand the customers, what our customers are thinking.
Why don't you just come along to a session. Just sit-in the corner. Don't have to say anything. He said, OK, yeah, I'm comfortable with that. So he came along and listened to what the customer was saying as we were talking to them. And then a few weeks later, I was doing some more work.
And he actually volunteered. He said I'll actually come and take notes for you for the next session. I was like brilliant. And then
he called me over to his desk one day. He said, I want to show you this. I've been working on this [? spike. ?] But I found that this hasn't worked very well. But listening to what the customer was saying the other day, I think this would be a much better solution because it solved the problem for the customer.
And I was like, I've got this developer who never wanted to speak to a customer, [? and ?] I think from a customer point of view. And then from that, so it's about getting people involved, so getting the execs to go out and actually meet their customers' or get the customers to go to the board meetings. And actually bring the customers to the exec, so they really understand who they're designing for, what the problem is. But then the other thing I also use is showcases a lot. Because, normally,
the showcase is you'll get people across the whole organization who are interested in the project you're working on. And they want to see the developments of that. So that's a really good platform for designers to explain the process that they're going through that this is what our customers are saying. These are some of the problems we found. This is some of the ideas that we've come up with to solve that. This is how we've tested it. This is how we're thinking about implementing it. And then at the next showcase, you can say, well, we tried to implement that.
We had some technical difficulties because not everything works perfectly. So we've created these workarounds. So you can use showcases as a way to really explain the design process and take more people along on the journey. And I found that by doing that, I've had people coming up to me afterwards from different departments, saying, oh, I really want to get involved. Or, oh, we're actually speaking to customers about this. It'd be really good for you to speak to them as well or for us to learn from what you're doing.
So that's a really good way for you to then get the whole organization to start thinking a bit differently. So that's what I've done. A lot at different organizations, and a lot of the people I interviewed through from [? my ?] [? book, ?] as well, also said about it's about getting those people to go out and actually speak to customers, empathize with them. And then it's also about bringing that feedback in on a regular basis through development, as well. So making sure you've got that continuous loop of customers.
So have those customers that you're-- the cohorts that you want to test on. And then continuously, bring them in every few weeks to actually test out ideas. And just get that flow going through, as well, as you're developing, rather than doing kind of stop and starting as you're going through it. And a lot of organizations still think you just do all the design and testing at the front, and then hand off to the developers.
And designers aren't needed anymore. Don't need to test anymore. But as you do both know, there's always things that come up. There's always things where the tech just doesn't always work quite as you expect it to. And then you need to rethink how it's going to work.
So that's when you need to have the designers there. And together, you can solve the problem or quickly test it out with a customer to find out, well, we've come up with this problem. We've experienced this. How can we overcome that? And it's taking people along on that journey. I remember having a conversation with a designer that joined Thoughtworks from a design agency.
And they had just watched their first Thoughtworks project go live. And they were so excited because it was actually something that they were familiar with because they said when I worked at an agency, we gave off the design, and then something would go live. And it wouldn't look anything like what I expected because, of course, they ran into things. And here, I was able to be involved. And so I could bring my vision and modify it based on what was-- And they were just so excited about the fact that they could recognize something that they had designed that had made it into production. Yeah, and so many organizations still don't quite understand why design and tech need to work together as a cross-functional team.
Some people still bring the designers in from the marketing side. And then you design everything. And you 're like, oh, we're just going to hand off to our developers. And then you'll go and speak to the developers. You'll say, well, actually it's not going to work that way.
And then the marketing team will, say, oh, well, we don't want you to speak to the developers because that gets handed to them later. Well, actually that thing that you've asked to solve the problem for it, it's not going to work. We need to bring the tech in.
And there's a lot that still don't quite get that. I think it makes the developers job a lot more rewarding. When they can participate in conceiving what the product is going to be and in influencing the direction of the product, I think that makes the job a lot more fun. When people get a chance to do that, they respond. Yeah. And the other thing as well is I love working with developers because they bring new ideas in. Because as a designer,
I'm not always close to the latest bit of tech that you can bring into that. And that's what the developers bring. In So we were doing a project. It was a legacy system, again. And we'd come up with a problem. And we'd test it with users. And it just wasn't going to work with how the users wanted it to work. But also the algorithm was built in a particular way.
So what we did is we just got together as a team. And myself, and the developers, and the BAs we just sat down. We said, OK, well this is how the algorithm works.
This is the problem that the customers have. How can we solve this? And together, we came up with a solution because the developers, who built the algorithm, knew the ins and outs. [INAUDIBLE]. We can actually do it this way, and we can show it this way.
So we came up with a solution and then tested it with customers. And it worked really well. And it's just bringing those ideas in that, yeah, developers have such cool ideas. And they're also really good at sketching. I know a lot of developers say they can't sketch. But they're actually really good at just making their ideas in a simple way that they can explain tech to me in a simple way, which I love. [INAUDIBLE] people.
So we've talked a lot about internal products and customer facing products. And you brought up earlier an API-related project that you had worked on. But is there anything fundamentally different about trying to say the design, the API strategy for a platform or these more technical products as opposed to something that might be more of a consumer product or a business process? The process that I always go through, it's the same thing because it's still about understanding the problem and understanding the customer. So it doesn't matter if the customer is somebody who's internal. If it's multiple people across an organization or if it's the end customer, there's still-- And it's about then solving that problem to their needs.
So it's understanding what their problem is, and then designing a solution around that. So yes, the end solution may be different. So an internal platform would look very different to an app that you've built for an end customer. And I've built lots of apps over the years. But you still have to think about, well, accessibility.
So are there people inside the organization that we need to cater for with different disabilities, the same as you have outside an organization with end customers. So it's still the same process that you're going through with understanding who the customer is and then how you solve that problem for them. And then the impact it has on the business would be different because if it's a customer experience at the end, then that might be generating revenue.
But then, inside an organization, that problem you're solving won't necessarily be generating revenue. But what it would be doing is reducing the cost of something that you're building internally, so reducing that time. So there is still a cost benefit to it. It's just that one would be maybe revenue coming in, and the other one is just shortening the time. So there's still benefits to the organization. It just depends on how you view that. So how do you think about the various aspects of design? I mean back when Scott and I started in tech, things were very simple.
We didn't have design. We had systems analysts. And we had coders. And over the years, now we have product people. And we have designers. And we have analysts. How do you tease apart what is fundamental to being a designer as opposed to say being a product person? You have designers, and then you have product managers.
So if you're a product manager, that's when you're doing more, the strategy, and getting that work done. So a product manager is organizing the work, basically. But designers are actually the ones who are solving the problems. They're doing the research and developing the solutions. Whereas product managers, are kind of more deciding on the priorities.
They're looking at the market, the competitor fit. They're doing more that strategy side of things. And there are some overlaps because product managers also need to understand the customers, same as designers need to understand the customers. So there are overlaps between them. But designers and product managers definitely need to work together. But when I'm talking about designers,
I'm talking about researchers. I'm talking about interactive designers, visual designers. And you will get designers who can work in a few of those different areas. But you're not going to end up with a unicorn, which is a lot of organizations want unicorns. They want one designer who can do everything. Well, that's fine. But you can't do everything perfectly.
So you're not going to get a designer who's amazing at research, amazing interaction design, amazing visual designer, and do all the strategy. It's too many things. It's asking a developer to do everything. So it's having that, I guess, what we call the t-shaped people, where you have your specialism.
And then the other complementary elements to go with that, which is why, in developer teams, you need to make sure you've got the right designers in there. So it could that you have a team of designers in there. Or it could be that you have designers coming in at different points. So maybe you have the researchers working with the interaction of visual designers, but maybe those researchers are working across different areas. But that depends on how the organization is structured and how the product teams are structured.
But yeah, there's product. And we have got a lot of names for ourselves, which does make it very complicated. And there are more and more names coming up because then you've also got service designers, as well.
And then there's some designers who go and kind of work a little bit in service design, but they're not pure service designers. So there's a whole variety. The same as developers, there's so many different types of skills that you need nowadays. But yeah, with product designers, I guess a lot of people are calling that that's kind of their overarching. They're calling themselves a product designer, but they could be having a few of those different areas underneath. But there's definitely a difference between designers, product designers, and product managers. How hands-on technical do you need to be as a designer? Do you see people crossing over ever from a technical role to more of a design role? I just said a lot of tech people are going from tech to design.
I've seen that. Years ago, I have dabbled with code, not that I would ever tell-- not that I would ever say that I would go and code something. But there are designers who can code. There are designers out there who can do that. But I think that when you're designing a product, there's so much to do that you can't be everything. So you can't be the best on the tech side and the best on the design side. But yes, you can have work across both.
And especially with the UI side, you can have people who are very good at front end dev and can also do some of the visual side, as well. But then I've also seen that on the tech side where you have some developers who are great at backend really can't do front ends. They just really struggle with understanding why you need things lined up the way they need to be and why you need spacing around certain things. Yeah, there's some people who just naturally just they just don't like the front end on the dev side.
Same with design, I can do research. But I'm certainly not a deep researcher who-- some of the researchers I've worked with are amazing at their job. But that's just not my core specialism. That back end developer you were talking about, that would be me. You would not ever want me designing a UI,
never ever, ever, ever, ever. Let me stick in the back end. I'm much happier there. Because I've had some developers say to me, Emma, it doesn't look right. I don't know why it doesn't look right. There's something wrong with it. But I don't know what's wrong with it.
But that's when you have to have designers and developers pair. But yeah, there's certain areas that is your specialism. And that's where it's best to stay. So what would you look for in an organization that would lead you to believe they had a robust design culture, even though they were a tech organization? What kinds of things would you look for? So maybe things like having design principles, having your design defaults. So
a while ago, I was contacted by a team of developers. And they said something's not working with the designers the client has. And I said, well, OK, well have you looked at the like design defaults, the kind of standard that we abide by when we're doing delivery, so I went through that with them. And they're like, oh, yeah, there's lots of things that are missing. So designers and developers aren't pairing. Designers are very much siloed.
They were handing designs over the wall. That's very immature in design practices. But in terms of design maturity, then, the designers need to be pairing with developers.
Having a design system, and I don't just mean pretty UIs put somewhere. I mean, actual components that you can-- developers can actually pull and use, so having a design system that's a mature approach. Making sure that there's a research team who are actually pulling customer insights in and those customer insights are actually driving decisions across an organization. So it's driving the direction of the products, but also the research is improving internal tools, as well. So I know Thoughtworks have done a lot of work around improving their internal tools. And that's been driven by testing it with the users to make sure it's solving the problem and it's actually adding value.
But also, that the execs understand design, as well. So when they're putting together their strategy, are they actually thinking about it from a customer point of view, as well? And is that data actually being traveling up through the organization because I've seen in some places when they'll have research teams, and they're putting together great research, but then that research, it doesn't align with the business strategy. There's just this massive disconnect. And then the business is saying, well, the researchers haven't created any value inside the organization. But that's because they just haven't communicated it, properly.
So then they've got rid of their research teams. So it's about making sure that that information is actually traveling through the organization. And they're working together. But yeah, definitely having cross-functional teams, having those regular cycles of customer insights coming in.
And Spotify have got a really great approach when they're building things, as well, when they're actually going out and testing new products. And every organization has different ways that they set up their design teams. So I can't say, oh, you should do it this way of how you set up your team. It depends on the organization.
It depends on the size. It depends on their level of maturity and what's going to work best for them. So I think also organizations, when they're looking at how they're setting up their teams with designers, and developers, and across the organization, you need to be OK with, well, actually that worked when we were this size. But now, with this size company, so we need to change and adapt with that.
It's interesting you mentioned the data and the information flowing through the organization, and talking to you, I get the sense that design is very much a data-driven activity, that the data is-- that everything needs to be grounded there. Is that true? Well, you need to get the insights from the people who are going to be using, it so whether that's the end customer or your internal customer, so the people inside the organization. Because you need to understand what the problem is for them, but then you also then need to be looking at future trends, as well. Because if you are somebody, do they want a car? I can't remember Henry Ford's-- Something, and I don't remember specifically how it goes now.
But something about it's not just a faster horse. Yes, that's the one, yeah. It's not just about looking at the current problems that customers have. You then also need to be looking at the future, as well. So bringing in other ideas because customers don't always know what they want. With the iPod, the customers say that they wanted an iPod? No.
So sometimes, it's just about, also, then finding a gap in the market and creating something for that, as well. And you can't always bring that through necessarily from existing data. Yes, what you can do, when you're speaking to customers, is you can see gaps.
And then from that, you can see opportunities. And from that, you can create solutions to solve those, which can generate new ideas and new products. So you need to bring those different kind of lenses in and bring that through the organization. And the biggest mistake I've seen is when executives have an idea. And they say we want this. And you ask them why? And they say
because our customers are going to love it. OK, fine. Let's test it with customers. And you test it with the customers. And they say, no way. I do not want that. And all the data just proves that they really would hate to have that added.
And I did actually have that a few years ago with a client. And he was the nicest exec. So he was fun. He said, I think, customers are going to love this. I said, OK, fine. We'll test it.
So we were testing lots of other things, tested it. One of the customers said, hell, no. I do not want that, ever. And we had a huge negative-- yeah, the response was very, very negative around that. So I went back, and said your customers really don't want it. He said, OK, that's fine. So he was fine about the whole thing. But some executives [? I've ?] seen [? organizations ?] think that their idea is the idea that's going to make a difference.
And then they push for that. And then they don't listen to the customer. And then it goes out there. And it doesn't work. And it fails. But you also have-- I mean, Andy Pollin talks about this a lot with-- he calls it the management as they're going through climbing up the cliff [? till ?] up the mountain, to the management level, up to the C level.
And they're kind of hanging over this cliff edge, and they're trying to just get to the next ladder, the next step in their career ladder. So yeah, so it's all about making themselves look good. So sometimes, they just ignore what the customers are actually wanting because their goal is to get to the exec level. And sometimes, that level can be the harder ones to work with to get them to really think from a customer point of view and to get them to understand design.
But that's when-- by bringing the data in, what I've found is that rather than me being perceived as the designer who is quite particular on things, it's actually, OK, it's not the designer who wants this. It's actually our customers who want this. So it changes the conversation. Because then you can say, well, it's not me being the difficult designer. It's actually your customers that really don't want that. It's not going to work for
them. That's not how they think. And I think the other thing is that organizations is I'm not the customer when I'm designing a solution. The organization is not the customer when they're designing for the external customers. So you have to go and speak to those people because you're creating it for them. And the same with internal, as well, when I was working on a platform.
And I was speaking. The product owner, he was lovely. And it was going to be his team who were going to be the first sort of Guinea pigs of the new thing we were building to test it out on. And he didn't want to test it with his team. He said no. This is how my team work.
We'll wait until the first slice is built, and then we're testing. And I said, well, actually we need to speak to them before then. And so I convinced him to let me speak to some of his team members, and test some things out.
And we tested it on some of his team members. And I went back to him and said, look, this is how your team actually used the existing tool. And he said, oh, I didn't know they used it differently to me. And then he said I thought they all used it the same way I did. But, of course, because it was a technical tool, he thought that everybody is doing the same way. But everybody found their own kind of little workarounds of how to do things.
That then completely changed his view. He said, OK, now I see the value in actually testing with customers regularly, testing with my team. So from that, we then tested regularly with his team and other teams inside the organization to bring those insights in. Great. So what's next?
What comes next? OK, what comes next? So through this whole process because when I first started writing the book, I thought, well, it can't just be-- the book can't just be my opinions and what's happened to me because, again, I'm not the customer. There's so many people, designers who do the same things that I do. So I then went out and spoke to all sorts of different people across different industries. So Rebecca,
I interviewed you for it to get the tech perspective. And Darren Smith from MYOB, then there's Andy Plain, and Giles, who's the Director of Design at Spotify, Nigel Dalton, as well, Jennifer Martin. So I've spoken to so many people from design side, who've come in purely from a design perspective, who've come from tech to design, or people who are just purely on the tech side to bring those perspectives in.
And then when we started putting the book together, I thought, I've got so much content here. And so, anyway, I was talking to the publisher. And they recommended me writing another book. And so the first book is very much about a designer becoming a leader inside an organization, how do you lead as the minority? And then the next book, which will be out early next year, is actually about scaling that, OK, so now you're leading inside an organization, how do you take that to the next level? How can you impact the whole organization? So increase the design maturity positively across the organization, so improve the internal processes, the employee experience. How can you change the maturity?
So the next one will have quite a heavy focus on design maturity. And when I'm talking about design maturity, it's different to product maturity. So product maturity is very much product inside organizations.
Design maturity is across the whole organization. So that's the next book. Well, we look forward to it. Well, thank you so much, Emma, for taking the time to speak to us. And I'm yet, again, a bit more enlightened about what design thinking is all about, and what designers actually do, and how they can have a positive impact on organizations.
So thank you for your time. Thank you Scott for your color commentary. And-- It's a pleasure. Thank you all for listening to yet another episode of the Thoughtworks Technology Podcast. Thank you. [MUSIC PLAYING] PLAYING]
2023-08-03 16:13
