Over the last couple of decades, we’ve seen concerted efforts in organisations to apply new philosophies about workflow and organisational processes to improve efficiency, increase employee satisfaction, enable scale, and increase customer fulfilment. An example is design thinking, a creative problem-solving methodology that helps transform complex problems into valuable opportunities by putting the customers‘ needs first. I recently spoke with Bermon Painter, Senior UX Manager for EY Digital about the potential and practices of design thinking, before his presentation at Codemotion’s online conference: The Spanish edition.
Bernard brings 20 years of product strategy, design and development experience in varying industries including aerospace, automotive, financial services, government, manufacturing, publishing, and retail.
How you define design thinking?
According to Bermon, design thinking is “a way for us to take complex problems that other human beings have to deal with. And then be able to successfully think through how to potentially solve them and come up with practical solutions that make an experience better whether that experience is an application like a web app, mobile app, or a physical experience such as the logistics of a retail location or a service like Uber or Lyft. So it’s very flexible.”
Design thinking aligns with processes such as design sprints “where the approach is very condensed and very short, you can do a Sprint in a few days for example. Conversely, you have “approaches like service design, which really takes these broader omnichannel, multiple touchpoint type experiences and makes them consistent. Design thinking, kind of sits in the middle in its flexibility, but these approaches are all based on similar user-centred design concepts and methodologies.
How does design thinking benefit developers?
Bermon asserts that design thinking is “a huge help” to developers:
“I think the most significant challenges from a development standpoint is that developers are at the tail end of the waterfall. They’re the last one to know, sometimes, especially if you’re working in enterprise. So this impacts their decisions. Typically, there’s a content strategy, there are wireframes, there are the mock-ups, and then there’s some prototype or something.
Developers typically get this package of stuff that defines what they need to build. And in a lot of cases, by the time they start building, the conversations at the top have changed, the business may have changed their mind, something has happened. And by the time those changes, get down to the developer, they’re essentially done developing. And so, if you take a more integrated approach and include the business and technology people, and you include the design or user experience, then they’re collectively thinking through these problems. You’re reducing the time that it takes for information to go from one group to the other to the other, and you’re jointly agreeing on what you’re doing and how you’re doing something, the translation layer is much more simplified.”
What are the barriers to implementation?
Succinctly put, Bermon notes that the biggest obstacles are “People and politics.”
He notes we’re typically not solving unique problems but that rather, “getting people to align and dealing with politics and ‘horse-trading’ requires a different mindset. “In super technical terms, whether it’s design or development, you’ve got to elevate those conversations at a business level, play the politics a little bit and try to drive those conversations to a better resolution and a shorter time frame. Otherwise, it just takes forever.”
Executive buy-in is critical. Bermon asserts that one of the biggest helps is have an executive champion, “Someone that sits on that leadership team, either at the C suite level or senior management level, that is taking up the banner and driving some of those political conversations. So that the product and the design and the technical teams can focus on doing the things that they’re good at. Otherwise, if you’re trying to manage up essentially, it’s very difficult and very slow.”
What do companies need to consider?
Bermon concedes that conferences and events can give a skewed perception of implementing design thinking in that “it’s going to be very rare that you find something that’s a 100% fit. What I would suggest is that these talks are where you get a snapshot of an idea. All of these conference talks are essentially a snapshot of the lessons learned in some cases, and sort of a breakdown of the methods that we use. But if you try to follow it fairly closely to solve a problem that you have, it’s probably not going to work as well.”
Instead, Bermon suggests that you use your initial exposure to design thinking to understand terminology and phrasing and approaches. And then riff on it. Experiment to figure out what’s going to work for you, for your product, your service, your environment and your culture. And, spend a handful of months tweaking.”
Bermon notes that cross-team involvement is critical. If design thinking is siloed within the design team and you’re not including your business and technology peers:
“You’re going to have a really hard time: “It’s almost a design thinking exercise in and of itself, in that you’re leveraging your peers and their knowledge and their needs. And you’re empathising with that and collectively trying to figure out, how can you apply something like design thinking or service design, or Scrum or whatever, so that collectively, you’re all effective? And you’re getting some of those speed gains and effective gains on how you’re collaborating. But you can’t do this in a silo.”
How you measure success in design thinking?
According to Bermon, its a challenge sometimes for designers to put on their business hat and consider things from a business lens:
“That almost always comes back to things that generate revenue, how your company makes money. Design thinking sort of has to come back to that. I mean, you’re creating great experiences, but if those experiences don’t generate money for the company, the company is not going to be around for too long.
So the way that I think about it, we’re looking at common value drivers, where whatever we do, either needs to save money or create money, create revenue, on top of driving customer satisfaction, reducing time to market.
So if we follow this approach, it’ll take us less time to get the right solution out the door, it’ll reduce the time that it takes for us to collaborate with the development team etc. So if I’m a customer, it reduces the time that it takes for me to understand how to use this product. So that it, in turn, reduces customer support calls and costs. So it’s a valuable saving from that standpoint. And then if we’re increasing customer satisfaction, and we’re engaging more with them, they’re probably talking about it with their friends. So that allows us to improve our conversion rates, and drive more business or drive more revenue. So you’re looking at drivers centred around the customer. But they’re focused on how improving that customer experience drives more value to the business or saves costs in other areas.”
