No doubt, you’ve probably heard a lot about Design Thinking in 2013, particularly if you are Employee or Partner of SAP. It's the design philosophy that we are encouraging our software development teams to use. The aim is quite simple; get a much better understanding of users so that we can provide much better solutions.
Although I first learned about the methodology last year from SAP colleagues, it has been around for almost 30 years. Last year filmmakers released a movie about it, the trailer alone looks interesting and it features many of the early pioneers of the method such as Tim Brown, CEO of IDEO.
I confess I am not in software design or development, so why should I care about Design Thinking? And what gives me any authority to speak about it. Well, fortunately I work in a labs location, so by chance in February this year we were able to get some Design Thinking training for our team . We wanted to learn more about the approach, and evaluate if it could also help us with a particular problem we wanted to solve. Namely, how to improve the overall enablement experience for our partner? Why this problem? Well, my team is constantly preoccupied with helping to make life for our partners as simple as possible.
So what happened? The good news was the training itself was enjoyable, at times very entertaining, and also equally insightful. The concept is not difficult to understand, and the principles are fairly straightforward. This meant that we could cover the theory relatively quickly and get straight into applying it, by using it to try to solve our problem.
When it comes to the benefits of Design Thinking, there seem to be two very different camps. There are those who claim it is a revolutionary approach that can be used to solve all the world’s problems, from poor product design to pollution, and healthcare, and there are those who see it as a way that consultancy firms take a good idea, package it and sell it to business companies as a cure-all remed....
I believe, like many things in life, the real answer lies somewhere in the middle of the extremes. When I look at the concept, I am reminded of an ill-fated career choice back when I was a hapless 16 year old.
Back then my school ran a work experience program. Students had to choose a local business to work in for 2 weeks of free work experience. The aim was that we got an idea of what the real world was going to be like. I decided I would work in a local Toyota garage for the two weeks, despite having limited knowledge of cars. Over the course of the two weeks I did some basic car maintenance tasks like oil filter changes, tire rotations while also greatly expanding my vocabulary of swear-words.
Engine repair is dirty difficult work, and the mechanics had a particular brand of hatred for a certain model of van. The van was quite popular with businesses at the time, since it was relatively cheap and drove well. But the mechanics hated it because of the way the engine was constructed. There were twice as many nuts on the parts than was necessary, and in order to change one part, you could often have to remove two or even four adjacent parts just to get to the one you wanted to change. As a result the labor time was double what it was for other models. The mechanic might add on additional charges on top for “the emotional stress” of having to try to fix the bloody thing. Needless to say that the van ended up getting a reputation of being expensive to maintain, which at some point must have affected on sales. In any case the van model was dis-continued a few years later.
So what does this anecdote have to do with Design Thinking? Well clearly the engineers who designed the van were thinking of the end user being the driver, so they had comfy seats, and a decent dashboard to make them happy. But when it came to the engine design, they focused making it compact and small, but did not spare any thoughts on what that meant for those who had to maintain and repair it. The designers never considered the broader scope of all their users were, and what needs they had. In comparison to other van models, which both suited the drivers’ needs and at least didn't make the mechanics want to tear their hair out, this troubled model was designed with little thought for the mechanics.
What did I learn from my work experience? Well surprisingly little about cars, but I see now that when it comes to design, we need to take into account everyone who uses the final product, and so the best d Design Thinking teams should come from a cross mix of people. A few mechanics would have been useful to have around when the plans for the van were being drawn up.
It also shows me the importance of co-innovation when it comes to design. We need to involve both our customers and our partners in the process, since they represent the user (driver) and implementer (mechanic) in this scenario and the best solution is one that fits both their needs.
Design Thinking when applied correctly can really benefit software project because it helps project teams have greater understanding of the problem they are trying to solve, and the people affected by that problem. The greater we understand both of these elements, the higher chance we have of designing something which all the users want.
