With more than 20 years of experience in UX, UI, product, and service design field Andrea brings skills from cognitive psychology and computer science in conjunction with a passion for UX and Human-Centered Design, brand management and marketing sensibility to his teams and projects.

He refined his education at Stanford and MIT, and he worked with, and for, companies like Apple, Google, Samsung, Noki, Ryanair, and Virgin Media.

Follow Andrea on Twitter

Episode Transcript

J Cornelius: Sony has a long history of innovative products from the Walkman to the PlayStation and beyond. Today we talk with their Lead Experience Designer, Andrea, about how they're creating the next generation of devices with a unique and flexible approach to the design process.

J: Hey, everybody. We're super excited to have Andrea with us today. He is the Lead Experience Designer for Sony Mobile. He has been all over the world. He's been at Apple and MIT. He studied at Stanford, and he's joining us from London today. So, Andrea, how are you?

Andrea Picchi: I'm very good, J. Thank you for having me.

J: I'm glad you could join us. So to get started, can you give everybody an idea of your background and what you're doing at Sony and just a little bit of insight into the projects that you're working on over there?

Andrea: Yeah, sure. My background is cognitive psychology, then I jumped into computer science, then I put everything together studying human computer interaction. With Sony, I'm working in the team that actually developed the artificial intelligence services across the Xperia ecosystem that actually encompass a smartphone, a smart band, and a smart TV, tablets. It’s called Xperia Agent. It's like Google Home; you can put it on a table. The other one is called Xperia Touch. It's a projector that you can put on any surface and then project the Android interface on a wall, on a table; you can manipulate it. And then there is like, ear pod, that you put in your ear and it's called Xperia Agent. Basically, it's just a voice companion to the other devices. So that's the ecosystem, and we are developing the AI services for them, for the ecosystem.

J: So is that a lot of headless interfaces? Just voice and maybe gesture interfaces? Or is it actually UIs in the traditional sense?

Andrea: Actually, it's a mixing. It's a mixing scenario, because when you work on a smartphone, as you can imagine, if we can think about it again in the Google use case, there is already on the market. You can have a child bot on your smartphone. You can have a voice and some form of typing on a smart TV. But it's completely voice-based on your home appliance, or in the small guy you put in your ear. So it's a combination, but that doesn't really affect how you think about it, how you try to solve the problems. The challenge is to, instead of solve in isolation every problem, just get the idealistic picture and throw it on the role. For example, the ear pod you put in your ear, it's accountable for a various subset of use cases, compared to the phone or even the smart TV or a tablet. So once you just figure out all the roles, it comes quite naturally, honest.

J: Interesting. So how are you deciding what interface to use or how are you deciding the development roadmap for those products? It sounds like it's breaking new ground, so what's the process of figuring out what you're gonna build?

Andrea: We use a very design-driven approach at Sony, and that's why I'm excited to be here with you, because we can discuss more about design thinking. The goal again is to create a layer on top of the Xperia ecosystem that is able to unify the portfolio, because Sony is Android, like other companies, competitors. So we want to differentiate. The goal is to create some unified layer that we can use to give it some personality and distinguish at Sony among all the competitors. So how we decide depends from product to product. But the goal is always the same for every single product, that eventually you translate in different goals, according to the use case. But it's always to support the user with some proactive type of behavior. That's the direction that we are going towards. So that's the mid- to long-term vision of the team.

J: Interesting. So it sounds like you're building a Sony layer, if you will, on top of Android technologies to enable all of these other products that you're bringing to market.

Andrea: Yeah, exactly. This is exactly the angle. It's challenging, because it happened in a moment, and to Sony, it went through some struggles, so we can't really do whatever we want in terms of the part that we are using. For example, we decided to use a lot of Google services inside the ecosystem, and this has pros and cons, compared to develop all our own applications inside the ecosystem. So we had to reframe a little bit the strategy to deliver the best business value for the current eye-level business strategies. So that was another part of the conversation that we had. That's when you start to see how design can really affect business in a good way.

J: Yeah. So it sounds like, most people would probably think of Sony as having vast resources and you could do whatever you want, but it sounds like you have some of the same constraints that the startup company might have, where you need to make the most out of the assets that are currently available to you.

Andrea: Yeah. Well, once you define your assets, you will always navigate in a context of some form of optimization is required. If I give you a five, you always try to be around the five, right? Because you want to get the best and use everything you have. If I give you a ten, you will replicate the same conditions, because you try to get even more with the resources that you have. So it doesn't really matter if you are a big company or a small company, you always strive to push the boundaries of what you have and what you can get from your resources. But Sony now is divided into Sony PlayStation, Sony Mobile, Sony Entertainment. So it went through restructures and the part where we are is Sony Mobile. So you never get everything you want, right? So that's probably the bottom line of what I'm trying to say. It doesn't matter if you have billions or millions or Androids. You always heed the upper limit of what you get. So we love to find some workaround to just optimize our resources. So yes, probably on a big scale, we live the some struggle as most startups.

J: Yeah. So can you talk about how you go about trying to maximize those resources, like what tactics or methodologies are you using to make the most of what might be a limited set of resources?

Andrea: Yeah, sure. We use design to do that, because we look at design as a business tool that you can use to solve business problems. The axioms that we all start from is that business values equal customer value.

J: Exactly.

Andrea: So we don't believe in delivering business for the sake of it, right? We want to say, "Okay, if we stay focused on the user, if we can deliver some value to the user, we will be able to build a sustainable business around that fulfilled need or needs." So that is something we have to say before moving on in any area of the design thinking, but we use design to do that because design is a wonderful tool that you can use, for example to mitigate cost. I'm not a big believer in, "Well, we can release something on the market and just collect feedback and then eventually pivot and change the direction." Of course we can do it, but I have the feeling that in many environments, people that take that approach as an excuse to skip a lot of the things that they can do before the delivery phase.

I can understand if you're a small startup and you don't have a clue about many things, you can release and then collect. But when you work for Sony or another big company, you don't really have the luxury of saying, "You know what? Let's release this product. Let's see if the people, they just start to write very bad reviews about it. Then eventually, we'll change it." Because probably the VPs get fired, or maybe the Chief of Marketing, I don't know, or the chief whatever-product is getting in trouble. So we can't really have that strategy when you work in a ... You have to think about the brand.

J: Yeah, especially if it's a physical product, because you've got manufacturing costs and supply chain and all of those other things to take into account.

Andrea: Exactly. Even the life cycle is completely different. So it's not just about release another thing in the Google Play on the App Store, that it takes 24 hours. So you release the wrong phone, you are done for good, at least for ten months, one year. So that's something that we don't just have the luxury to do it. But we don't need it, because we have design, and design can do a lot of things. One of the things it can do is to mitigate cost, because we can deliver ... if you think about it, 360 degree. We can use design to cut, or at least identify the right direction and then create a reduced funnel that we can follow. We'll never be a straight line, even if we had designed, because that's life. That's the nature of what we call the wicked problem. The problem is ill-defined, we don't know the solution till we look at that and we stare it right in the eyes.

A lot of the time we don't have a stuck moment, like in a technical problem, so we always have to iterate and improve the current situation. But even in this case, design can avoid a team and point it in completely opposite direction, compared to what eventually will be the optimal or sub-optimal solution. So that's how we optimize what we have. We structure the team, the people, and the processes, and the places in a way that we can get the best from the design thinking. That's our main approach to reduce cost, answering your question about also to get all the benefits. Maybe we can explore it later.

J: Yeah. So what's interesting is, if you're dealing with the physical products and you're dealing with things that have a long life cycle, you don't get the advantage of being able to put something into the market and prototype it. So how are you doing that prototyping? Are you bringing users in? Do you have a small group of people that you test things with? What does that look like?

Andrea: So first of all, it really depends for the problem that we try to solve. That dictates how we approach research. When it comes down to research, we have qualitative, quantitative. So it depends for the problem. We start first from quantitative and then qualitative, or vice versa. Most of the time, when we have to deal with that wicked problem, we prefer to start from qualitative because as we said, we have really no idea about what the solution will look like. So we have usability labs, and for the qualitative, we like to interview people again from the qualitative. We try to collect a lot of different quantitative type of data from analytics when we have to inspect how a service is performing or when we want to look at sales or when we want to look at any other type of quantitative KPIs, or the variable that we use to identify a type of performance.

Short answer is that we invite people. We believe that if you don't talk with people, you don't really go anywhere. We have to go for the "why" most of the time before the "what". So that's what we do. We try to connect in many different ways, and the good thing about working on a combination of service and product is that it gets interesting because you have the opportunity to go outside and look at how the people use the devices. So it's amusing things to do for the team. It's not just a digital service that you can replicate the experience everywhere, even if the surrounding environment is not really the same, but at least it's 80 percent when you can optimize the money you have because in-house is cheaper than going out. So basically, we combine qualitative, quantitative, and in a small way, it depends on the problem that we have to solve. We combine in-house and external observation to just try to understand the next step. Usually it's always about the next step. You can’t really plan more than a few steps ahead.

J: Right. So what's the sample size? Are you talking to 5 people, 50 people?

Andrea: We know the old rules, right? So they say five people, you get 75 percent, but it's right. It applies better to digital services or digital interfaces when you have to explore few qualitative attributes. It's a little bit random. So we can apply that rule. And the five people, we use that five people rule, and it's nice because it's an entire morning and then we can use the afternoon to just discuss the findings and eventually the next step. But when it comes to some unspoken and hard to articulate things, five people, they may not be the right number. I'll give an example. You use the phone in a certain way, and it's really an articulate way of doing things because maybe, I don't know, you have a disability in your hands, or maybe because ... I don't know what may be the real reason, but imagine it's a disability in your hands and you're never told that your design is not really optimized because it's not the average use case, but I have to at least be able to support some form of inaccessibility or disability.

It depends for the device that you design. If you just pull five guys from the set of the people that you selected, the chance that you get someone with disability is quite low. So in that case, you really have to go after a specific sample size, and you have to be aware it's not something that you solve randomly just because, "Oh, we got that ... This is just a fluke." If it happens, it's happiness for everyone, but sometimes when we talk about very small detail, a well thoughtful process is required in order to uncover those small problems. But this is just the edge case. In general, we put together a good combination of qual and quant, in-house and external observation to get the findings that we need in order to move on.

J: So it's interesting that you mentioned accessibility issues. Do you do anything specifically with accessibility? Obviously, if you just call five people at random, the chance of getting someone with some form of either physical or visual impairment is probably pretty low. But do you get specific groups of people with different types of impairments in testings?

Andrea: Yeah, if we want to address those things, that's the only way to do it. But usually, we rely on software for the accessibility, and there is just a few things around accessibility when we design hardware stuff. It can be a button, it can be something else, but the latest design is really minimalist when it comes to physical ...

J: Sure, and I guess you could rely on lots of history of product design at Sony to know button sizes and placement and things of those things that impact physical impairment. Visual and more of the screen type, moving things around on a digital UI is a little bit more challenging.

Andrea: Yeah, there's a lot of knowledge in the company, a lot of great people with huge experience. So yeah, you're correct. That's something that we always do, and that's why we never start anything without a proper investigation, both internally, externally because again, there is a lot of great people. Sometimes they are not where you are located, because Sony ... When we talk about Sony, we talk about, yeah there is London, but is it Lund? That is basically the European HQ. The reason because is, Lund is 10 minutes, 15 minutes from Malmö in Sweden. What today is Sony Mobile, in the beginning was Ericsson, Sony Ericsson, and then became Sony Mobile. So it's really a Swedish company. Well, now it's Japanese. And then of course, you have Japan, in Tokyo, in the HQ. So it's the challenge inside the challenge, but it's also the good part.

J: So can you talk a little bit about, once you identify a challenge that you want to solve and you've identified what your hypothesis is and you've started framing what questions you're gonna ask, can you walk us through the rest of that process? So once you've started to collect some research, what does the iteration and prototyping phases look like with the different people on your team?

Andrea: Yeah, that's good. Give me the chance to just share with you something that we do and started from, some investigation that we did in my team years ago. I didn't see a lot of people working like that. It works very well for us, so it's good that I have a chance to share it with you. So basically, think about the multidisciplinary team. We ask to that team to behave according to different states. One is the thinking mode, when we explore the ideas. The other one is the delivery.

J: Interesting.

Andrea: So the thing that doesn't happen in other ... Well, it may be common, but in the way we do ... So basically, the same guys, they are ... basically the same guys. So think about, it can be developers and it depends what you have. We have something, call it Experience Planner, that actually is a product owner, but we like to reframe the role to give the right feeling. So we use the word to ...

J: So you call your product owner an Experience Planner.

Andrea: Yeah, because we believe that the words are powerful, and the words can affect the perception of your world. So if I call you Experience Planner, and when you have to make a decision, you put first ... I don't know, cutting corners because of the sake of delivery? So that creates a different type of conversation if you look at yourself in the mirror and say, "I'm an Experience Planner," instead of just product owner or a product manager. That's why, for example, we don't call it front end guys, we call UX developers or UI experience prototyper, experience developers. We want to help people to just reframe their world in a good way, not in a bad way. That way, it's easier to put design at the center of any decision.

So basically, we have this team, and the very same people are in the thinking phase, and the very same people in the delivery phase. It's not like you have a group that are thinking about something where, for example, the developers just give the feedback and when you switch to delivery, maybe you start your sprint. You have the design doing something else, and then the developers doing their job. So probably the best way to give you a feeling is that we never have continuous sprints, because of course you have the thinking phase and then the delivery. This is something that doesn't happen ... Even in Sony, there is a lot of place when you have a more formal and standard way to apply Scrum, for example, with continuous sprint. But what we want to do, we want to engender the design thinking and the design doing phase in a good way. We don't want the delivery practice to take over on the other phases.

So you see those guys, they have a problem, they get a problem from somewhere. It can be the product, it can be the manager in line, it can be the CEO. So that team has a problem, and the first thing, they try to define the problem, in many different ways. As we say, it depends if you need research. Most of the time, if it's a wicked problem, you need research. If it's a technical problem, you can look back in the past and try to understand how to replicate the solution from other teams or the past experience in the company. So once you come up with a hypothesis, you connect with the user if you didn't already because it's a wicked problem, so you did your research in the beginning, and you start to elaborate your hypothesis and you start to give form to your hypothesis.

Now, the way you give form to the hypothesis is the bare minimum that you need to just get the answer, because you have to look at the prototype as a way to ask a meaningful question to someone. That's something that I love about industrial design, because they can't skip that phase. If you want to build a phone or if you want to build a chair, the only way to get feedback is to build a chair. You can have a sketch, but this is a design-ish conversation. You can't really show a sketch about a phone and a chair to someone and say, "Do you think it's comfortable?"

J: Yeah, you can't judge a three dimensional physical object by what you see on a piece of paper.

Andrea: Exactly. So we're trying to bring that approach into the digital space. So we never discuss any idea without some physical manifestation of the hypothesis. Of course, if it's a digital product, it's inside a physical object. If it's a physical product, it's the guy itself, the manifestation of the product itself. So once you get that feedback, you decide if you have enough degree of confidence to move on or to pivot. Of course, what I didn't say is that at first, you want to diverge and create as much solution as possible, and then you need a good way to converge and make your selection before you move on into the prototyping phase. That is a quite plain way to apply design thinking that is nothing new here.

The novelty and the things that I would like to share with you is that the very same group of people is 100 percent present in the thinking and in the delivery. It means that the thinking phase, the developers, they are not working in their strength. So there is now CTO of another guy that says, "Come on, guys, the burndown chart sucks! You have to deliver the points!" Because we don't care about the points now. Our job, like any other adjoined methodology is Scrum and is based on requirements, while design is based on hypothesis. So you can't really move into delivery phase until you have some solid degree of confidence about an hypothesis, that it can be translated into a set of requirements that are defining a given product or a given solution. So that is something we want to avoid. You have to have the heart to just implement that process. If you imagine you are a consultant, you go into a company and you say, "Okay, we want to bring design," and you start saying things like, "Oh, but you can't start the sprint because now we have hypothesis, what you want are requirements." We can't really do that.

J: Yeah, you won't be a consultant there very long.

Andrea: Yeah, exactly. That's what I'm trying to say. So the novelty in this approach is in the way you use the people and the ways you demand different things to those persons, more than the process itself. This is something that can happen pretty much everywhere. But how you embed, or probably even better way to frame it, how you use development to support the design is completely the opposite of what many people are trying to do: use design to support the sprint, the development process. So if you apply the opposite ... and it's not just because we want the world wrote by designers. That's not the case. A lot of the most brilliant ideas, they come from developers, they can come from person in the marketing ... It's because design is how something works. At the end of the day, it's not just how something look like. And this, if you like, we can discuss for example why I don't believe that design thinking is a good way to frame what we do and why I believe in ...

J: Yeah, I'd love to hear that. So first, I think it's interesting that you bring everybody in the team into what you're calling the thinking phase. So a couple questions on that real quick. How long is that thinking phase? Is it time-boxed in any way, or is it a little bit more free-form?

Andrea: Again, it depends for the product. In a very edge cases, there is no time box. That's the case, for example, imagine you want to say, "I want to reinvent the smartphone," or I'm working at Apple and I want to create or design the first touch device. You can't really time-box that process, because you don't really know what you're talking about. It's very, very complex to just get a solution.

J: Right. But at some point, you have to get back into the active development phase.

Andrea: Yeah, yeah. So this is just one percent of the cases. In 90 percent of the cases, you have to time-box what you are doing. One of the reasons is because when you work in time constraints, creativity can thrive and we also know, as designers, that it's also better for creativity if you put some boundaries. You don't have to lose everything, otherwise it's a chaos. So there are time boxes. We use different approaches. A very simple way to do it is to have different type of design sprints. For example, you can have the plain seven days. It can be five day sprint for a quite complex problem or question to answer. It can be three days. Can be one day. So imagine one, three, and five are your three options. You have your design sprint, and then you have maybe three sprints, three in-development sprints when you deliver that part. Or maybe you can have two design sprints and then maybe just one.

Let's say the development team is just creating a prototype, or got a good solution so they're working on the delivery. So maybe there are more sprints. So it's not written in stone, but the idea is to time-box into one, three, or five days design sprint, and then move into end cycles of development or Scrum in order to deliver the solution. In that phase, what we didn't say before is the design team spends the vast majority of its time supporting the development so its work can be an implementation of the guidelines, or maybe supporting the developers in the QA phase. That's why I say the entire team switch to development mode. It's not the design that just exit the room and work on another problem, because that's his team. He has to be present at that moment in the delivery phase. So that's pretty much what we do. We try to use that design sprint approach because it's simple, it's well-defined. A lot of people, they know that already in the company, so it's easy for us to evangelize. At the end of the day, it works very well, so it suits our needs.

J: So it sounds like it's a bit flexible, obviously depending on the question or the problem you're trying to answer. So it's a little bit flexible. You might have one thinking phase and two delivery phases, or three thinking phases and then four delivery phases. It really just kind of depends on the complexity of that particular problem and where you are in the entire process.

Andrea: Absolutely correct, J. The reason is because the entire team is focused on delivering a solution. So I have to be flexible and have to be able to make the right decision in order to deliver the solution. It's not just about how many design sprints, how many delivery sprints we have. It's just, we have to deliver that solution because that's what we are ... I want to say, "what we are paid for," but we know that designers, we don't look at the work that way. But yeah, if we want to be a little bit more cynicist, it's what we are paid for.

J: Yeah, that's the job that we're supposed to do. So I think the takeaway there is, don't put the process in front of the objectives that you're trying to achieve, and don't let your process ruin your product.

Andrea: Absolutely. So the process, like the discipline, like the mindset and like many other things, is just a tool that you use as a human being to solve a problem, and in our case, to deliver some value.

J: Yeah, and sometimes, just like with tools, you sometimes need a small screwdriver, sometimes you need a large screwdriver, or you need a different type of tip on the screwdriver to get the job done.

Andrea: Exactly. Another example is, as we said, imagine you use the thing to just create ... a high-fidelity type of prototype, you don't need to start a sprint. You can even use Trello. Maybe you just need to work three days. So why start the sprint, having the planning and then the retrospective and all the ceremonies that you get when you implement Scrum. Just use Trello. In the very same way I design and say, "Why should I have to build an app if what I need is just a paper prototype to get my answer in the very same way the developers are asking to just come up with the right delivery process in order to achieve the goal?"

J: Yeah, and that process can be very different, depending on which goal you're trying to achieve.

Andrea: Correct.

J: So a lot of the burden on design leadership is keeping that flexibility and making sure that your process can be adaptable.

Andrea: Correct. And in a way ... I had a friend that liked to frame it that design leadership, it's how to ... the team, to navigate the ambiguity that comes when you want to solve wicked problems and ultimately deliver premium value. Maybe this is a story for another conversation, difference between premium and non-premium value, how you deliver the premium, what are the tools they use to deliver premium value.

J: And how do you measure that.

Andrea: Yeah, exactly. This is food for another story. But yeah, I totally agree with you.

J: So, something else you touched on earlier was this alternation between divergent thinking and convergent thinking, and that reminds me of some of the writings of Edward de Bono many years ago. So can you talk a little bit about the benefits of those two approaches and how you see that help solve problems?

Andrea: Sure. The two types of thinking, they belong to what we call the thinking phase or the design thinking process. So when you try to diverge and come up with as much solution as possible, because it's true that if you want to have a good idea, we know that you have to get many ideas. But the unspoken part is that the team build on top of other people's idea, to get to the next idea.

Maybe I say something that goes in the right direction, and you say something that goes in the left, and it just reframed what I was thinking and say, "Oh, all right, I'm gonna steer to the left direction and come up with another idea." It's not just the plain quantity that solved the problem. It's that I say something that doesn't make any sense, but maybe triggers something in your head, and then you say something back to me that probably I completely disagree with, but ... not totally, but I believe what you say is right in that sense, and come up with something else, and that helps you to qualify your thoughts on something else. Maybe even in a big way, at the end of the day, nothing works, but most of the time, if nothing works today for this problem, then it can be used in the future. That's why it's important to build and track all the thinking activity of a team. Case in point is that Apple, they designed the tablet before the phone, and then they just brought back the tablet years later in the very same way.

But the goal here is to just explore the thinking more than create many, many, many ideas. This is something that requires brilliant people. That's the most difficult part. The words that you use affect the way you think, and the way you steer the conversation.

Imagine I'm your leader in the team, and I can say to you, "Look, we are working on the new Xperia phone, and we want to design a new case for the phone." So I ask you to design your case, you go back to your desk and you start to design a sketch or whatever, maybe in the team as a standalone task. That's not important now. But you come back and you show me a lot of different case for the phone, or maybe for the laptop. But think about it, if in a parallel world you have a leader that comes to you and say, "J, I need a new way to bring the smartphone with me." I'm asking, pretty much, the same thing. You can interpret it as, "Well, I need a new case," but maybe you can interpret it in a completely different way, for the reason that I framed the challenge in a more open way without giving you any type of boundaries, like "I want a new case." I just asked you, "J, I need a way to bring the laptop with me. I need a way to bring the phone with me." That doesn't mean that it's a case, doesn't mean that it's a bag, doesn't mean anything. It gives you a better chance to explore many different options in your process.

J: It seems like the real question there isn't whether you need to bring the device with you. The question is, you need to bring the capabilities the device gives you along with you.

Andrea: That's, for example, a very good way to frame the challenge. But again, if I say, "I want a new case," I already killed 90 percent of the good idea that you can come up with, because even if I don't want, I framed your creativity inside the case. If you come up with something that is innovative, it's just a fluke or you are so brilliant that you struggled so much to kill the cage that I put you in. You just broke the cage and you came up with a completely different approach. But again, as a leader, I have to put you in the best possible environment to do your job.

J: Right, so you have to frame it in a way that helps encourage that creativity instead of trying to box it in.

Andrea: Yeah, I have to make your life easier, not harder. So that's the values behind divergent thinking. And then you have the convergent ... at that phase, at that moment, you need a strong vision because you can't have a strong goal, a goal is something that you plan in details, but you can't when you have a wicked problem. So you need a vision, a guiding light that you can use to just reduce all your options, and then you also need a way to mitigate group thinking. One of the things is dot voting, zen voting, just a way to get the best of vertical way of thinking but at the same time, get the best from the cross communication that can happen in the same room between people. That is the challenge in part of the convergent thinking. You have five guys, you wanted the best idea from those five guys, but at the same time you need a way to just see those guys communicate.

So in the very same way, like the thinking and the delivery, you need those guys switching between vertical thinking and then group thinking. In order to see those things happen, you have to put in place a process or a meeting structure or a sprint structure that supports these different ways of communicating inside the team. So that's in a nutshell what we try to do. But probably, if you have a little bit more time, we can discuss the design thinking issues that can open a lot of doors or can bring something to the table for the people that are listening to just comment and bring their point of view. I believe that we all know that design thinking is, at the end of the day, just human-centered design.

J: It's just the most recent label that we put on this process we've been using for a very long time.

Andrea: Yeah, exactly, exactly. And the last of us that did that was David KellEy, that just reframed the user-centered design approach that he used at IDEO. And it served very well our purpose in the past years, because now we are here talking about design thinking. There's a lot of people working on project management, listening to this episode. So it's a huge achievement, something that was impossible to even imagine 10 years ago or 15 years ago. But I believe that now, design thinking doesn't help us to achieve what we want anymore. The reason is because when you have to bring design thinking inside a company, the design world and the thinking world, they are working against what we want to achieve. I'll give an example.

First, if you want design thinking adopted across the entire company, for the simple reason that you call it design thinking, you get a lot of people pissed off, like developers. They say, "I don't want to be a designer, and I don't need design thinking to just solve my problems." And they're right in some forms, because what they need is, they generate thinking that works in a completely different way. So it's about isolating variables, getting requirements. So that creates a barrier between you, for example, and your IT department if you try to evangelize and bring the design thinking or what design thinking is inside that department, because the people say, "We don't want to be designers. We are just IT guys."

So what I ask to those people, everywhere I go and in every context, is to be human-centered. I never ask them to think like a designer, even if it's the same thing at the end of the day. But I never frame that way, in the very same way that it depends how you frame the question. It affects the results. So I ask to developers, "Be human-centered," instead of, "Embrace design thinking." That is something that creates an instant reaction, a pulling away reaction. So, "be human-centered" means, "Think about the consequence of your coding activity, in terms of the user." What is the value that you deliver? How will your code affect positively or negatively the people's life? And if you don't know the answer, it's your responsibility to connect in some way with them. So if you frame it in this way, the people say, "Of course I want to understand what is my impact, what my coding is creating in people's life." But if I approach the same person and say, "You have to think like a designer, you have to use design thinking," I guarantee you it's not gonna work.

J:  Yeah, it won't work.

Andrea: Yeah. That's why one is just the design word. And that is the thinking word. We all know that the first thing that we have to do when we join a team as a leader or as a consultant in-house, if we have to bring the design practice in that place, we have to create trust. In a very same way, it's just about relationships. Doesn't matter if it's a romantic, if it's a professional, it's about human beings. So you have to create the trust that you need in order to engage people, to see people loosen up a little bit and get what you want, and bring the value in their life.

But for the very same reason they use the word "thinking," that reminds them the preconcept that design is just about thinking about things, talking about things, and never delivering. But what we mean here is delivering, and then if you spend a lot of time thinking about something, we are wasting time because we have to deliver. So again, using that word, which I love ... I love design, I love thinking, and I love design thinking together ... but I have to be honest with myself and say thinking doesn't help me to achieve my goal. Design thinking, in reality, is design thinking, design doing, and the design environment. They are the three pillars that you have to bring in in order to see a change in behavior.

So if you say that design thinking is just design thinking, people never get to the point and say, "Oh, but it's also design doing." Because we know that, because we are designers, but other people, they don't know that. So again, I never say "design thinking," I say, "Be human-centered," and behave and do your job in a way that you are able to explore all your ideas and then do your stuff, applying a human-centered approach to design doing. Creating an environment that helps you to do what is required. That is the design environment. But I never use the "design thinking" word because as I tried to explain, it just doesn't help the cause.

J: Yeah, exactly. I don't know if you follow Jared Spool or not, but there was a Twitter fight that happened a few weeks ago where he correctly said that anyone who's involved in the design process becomes a designer. Whether they're involved intentionally or whether they just come in and provide their feedback, anyone who has any kind of influence over the outcome of a product is essentially helping to design that product. So unless we engage people intentionally and give them a framework to work within, other people from outside what we think of as the design group or the people on the design team can easily come in and say, "Well no, that won't work because Accounting is gonna say this, or because Marketing is gonna say this," and they've just influenced the design in a way that wasn't intended. So by bringing them in, by inviting them in and by not using language that pushes them away, by saying, "Hey look, we're all on the same team here and we're trying to achieve this result, so let's just give it some thought and think about the user first," then we can achieve an outcome that's actually much more desirable.

Andrea: Complete agree. I remember that post, and 100 percent agree on what Jared said. It's true, it's true. An example that we didn't say is that design thinking, we say that design, the practice, is composed by design thinking, design doing, and design environment. This is something that I presented a couple of weeks ago in Istanbul in one of my talks. The video will be available quite soon, but you can get the slides in the meantime. I introduced a framework to scale design inside a company. Basically, you see design thinking when the people, they think and they connect, they empathize with the user. They connect with the customer base. This is the practice that you can scale in the very same way across the entire company. It doesn't matter if you work in marketing, it doesn't matter if you work in HR or even in finance. You can always apply the very same thing. So you connect with the user in a qualitative or quantitative way. This is the same.

Then you have, of course, the design environment that surrounds the other two pillars. Then you have the design doing. The design doing is specific for every department. So for the design team, you will see creating. The doing is maybe create a smartphone prototype, or maybe an email client prototype in order to trigger the mindset switch and engender the design conversation. But in the marketing, that's gonna be a different practice. I'll give you an example.

Something we did, we create a video for the new phone presented in Barcelona, the latest Xperia. Their design doing was, "Okay, we connected with the user. These are the values that we want to embed in this video." So for them, the design doing is not to create a smartphone. The design doing is not to create an email client to use in Flinto or Pixate or Axure or whatever sketch tool they use on the team. It was to create a storyboard when you just prototype the entire sequence, and then they create a very cheap and dirty After Effects video that they show to people, and then they say, "Okay, what are the emotional values that you get from this video? Are you experiencing innovation? Are you experiencing security? ... " It depends on which value you want delivered with that video. This is their prototype.

The marketing prototype that is working on a video is just a very simple After Effects video, maybe shot with the iPhone, without the expensive camera they use for those video. But for HR, it's something that we did also with HR. We had a problem hiring young developers from the university, so we used design thinking the very same way in HR, and then we come up with a prototype in order to attract young talents. So the prototype was a combination of a new website, a new kiosk in the university, and a new FAQ section and project presentation on the website. This was the HR prototype in order to test the hypothesis that if you expose your vision, if you connect with the people in the university, and if you present in a meaningful way through your website, you can increase the young talent that you get in your company. So the design doing for the HR was another completely different thing, but at the end of the day, design and marketing and HR, they all used a design practice, a human-centered design practice to solve a problem. In the design team it was, the new smartphone, the email client. In HR, it was how to get more young talent into this company. In the marketing team was, how can we deliver a video that embodies that value that we want to transmit to our customer's base?

J: Right. And you aligned all of those three things together to create a product that had a result you were looking for.

Andrea: Correct.

J: Yeah. So unfortunately, we've run out of time for today, but if somebody wants to get in touch with you to talk about things a little bit more or maybe get that slide deck you mentioned, what's the best way to get in touch?

Andrea: The best way is first on my website, AndreaPicchi.it. My name, last name dot I-T like Italy. And then @AndreaPicchi is my username on Twitter, so they can look for me on Twitter. It's my username on SlideShare, where they can get all the slides that I create. That's pretty much it. It's website, Twitter, and SlideShare. They can get everything about myself and contact me. Email, they can find on my website. Happy to get in any conversation about design with anyone.

J: That's great. So thanks again for being on the show today. It's been a great pleasure. You've been very insightful, and we look forward to having you on the show again real soon.

Andrea: Thank you, J, for having me. It was a pleasure.