Design Thinking Bergen Program - What is it, and should you take it?
Dataingeniør og forretningsutvikler João Ribeiro fra M'Labs reflekterer rundt Design Thinking-studiet og ser metodikken opp mot andre metodeverktøy
If you are reading this article you are probably curious about the DT Bergen program (Design Thinking: Strategic Design for Innovation). You might be thinking about joining the next cohort, just browsing around for ideas, or maybe comparing with other education options out there. By the end of this post you should have some deeper insights into what Design Thinking is (and is not) about from as insider’s perspective (in this case, my perspective). This will hopefully help you to decide if you should enrol or not in the next 2016 cohort.
A bit about me: My name is Joao (Jay). I work as Biz Dev Director at Mobiletech and am responsible for all our new business development.
I hold a MSc in Computer Engineering and am an entrepreneur myself, so I always had a strong interest for methodologies and tools that help to build better products and businesses. I am very comfortable with Lean Startup, SCRUM (I am certified product owner) and User Experience (UX) methodologies and their related tools.
Everything in its right place
When I found this program I had to decide to enrol or not and in what way the program would fit into my previously existing knowledge base.
The picture above, in my opinion, depicts fairly well where Design Thinking fits with Lean Startup and Agile methodologies. It shows how Design Thinking, Lean startup and Agile methodologies relate to each other in terms of Abstract/Concreteness and Problem/Solution focus.
A very simplified way to put it all together can be:
- Got a complex and fuzzy challenge? Not really sure how to approach it since it has many dimensions to it? Go for Design Thinking!
- Want to start a company or new business line and focus heavily on finding a product-market-fit and a business model that can scale? Go for Lean Startup!
- Want to build a software solution for a problem you known fairly well/got enough to get started or are working in the next version of a solution? Go for SCRUM, XP, < your favourite agile methodology here>!
- Know very well the problem and the solution, been at it for years and want to innovate and discover new customers and opportunities? Go for Design Thinking!
In other words, the more multidimensional and fuzzy your challenge is, or the more you want to get new and fresh insights into it, the better Design Thinking can help you to approach it.
What makes Design Thinking, Design Thinking?
The very short answer: Empathy!
I could tell you how Design Thinking is based on human-centered and participatory design, about its cross-functional collaboration style, etc. But if I have to choose one thing that in my opinion distinguishes this methodology from the others it’s Empathy!
Or better yet, the amount of time and effort you spend empathising with people.
Notice I say people and not users. This is on purpose because the term user typically implicates a person “using” something, some kind of solution. Design Thinking goes way broader than this as it looks to empathise and deeply understand the values and emotions of all people involved in a complex problem, even those who do not “use” anything.
Our group’s challenge within DT Bergen
Within the DT Bergen program you work with a real life challenge throughout the entire 9 months. Our challenge, sponsored by Tryg forsikring, was “How can we help reduce the incidence of scalding in children from 1–5 years old?”
Take a second to think about this question! Is this a health challenge? Is it an educational challenge? Is it a social challenge?
The answer is YES.
It’s all of the above and that’s why it is such a great candidate for a Design Thinking process. The challenge is specific enough (children, 1–5 years old, scalding) but still broad and multidimensional as it can be approached from multiple perspectives.
To answer this question we need to empathise with parents, children, educators, nurses, doctors, siblings, grandparents, etc. We also need to look into extreme groups like refugees, parents who had multiple scalding episodes with their child, etc. We need to interview and observe all this people in different places (home, kindergarten, outside playing, hospital, etc.), collect a gazillion of information and make sense out of it.
This is where the tools of Design Thinking shine. You learn first to collect all this data (how to observe, how to interview, how to go deeper into empathy, etc.) and then you learn how to make sense out of it (analysis/synthesis, themes, insight generation, etc.).
Only after this are you ready to frame a starting Point-of-view (POV) for a problem or need and start working on solution prototypes to respond to it. Here is where potentially Design Thinking can meet Agile Development if solutions shape totally or partially in the form of “usable” systems (websites, apps, etc.).
How is this different from User Experience Design?
There are many shared tools between UX methodologies and Design Thinking such as personas, user journeys, etc.
I have found that the simplest way to put it is that UX methodologies typically focus on the “user(s)”. The name itself implies there is an “usage” of a system (solution) of some sort and UX tools and methodologies tend to optimise for that. Of course UX can be much more than this, just like Design Thinking is also called “thinking” when it is really about doing, but nonetheless this is a fair-enough simplified way to put it.
You can expand a UX methodology into Design Thinking and still call it UX (e.g. broadening the User Research), but you cannot shrink Design Thinking into an UX methodology and call it Design Thinking.
In a nutshell, if you learn and practice Design Thinking you will become much better equipped to understand your users, including their values and motivations outside their “usage” of a system.
By the way, how does Design Thinking relate to the Lean Startup?
The Lean Startup is a methodology that imports ideas and tools from many other methodologies like Design Thinking, Lean Manufacturing and Agile software development.
With Lean Startup you look to known your users, your customers, and to find and solve problems or needs these actually have. You do this by running experiments and constantly testing your hypothesis to get further validated learning, typically around product-market fit in the initial stages of a startup.
The Lean Startup includes many ideas from Design Thinking (with a special focus on Customer/Problem fit discovery), nevertheless these are different methodologies.
There are many differences between the two methodologies but the fundamental one is that the ultimate goal of Lean Startup is to discover a business model that works for (drumroll please…) a startup. Though of course you will also bring business considerations into a Design Thinking process (remember empathy?), this does not necessarily have to produce a Business Model nor does it have to be ran in the context of a startup.
In a nutshell, if you learn and practice Design Thinking you will become much better equipped to tackle Problem/Customer fit within the Lean Startup.
Hmmm… how about Design Thinking and Agile?
Agile methodologies were designed to help create better software solutions, where there is a low level of certainty and/or requirements can change often. The keywords here are software and solutions! Born as an opposition to the waterfall approach to software development, agile development introduces ideas around adaptation vs blindly following a plan, iterative development cycles, early customer exposure to products, etc.
Agile methodologies help you create software solutions and are optimised for that, and not for need finding and problem discovery. Of course when you expose users to solutions you also get some insights into their problems. Nonetheless you learn if your solution works or not, but you don’t go very deep into the problem (which is exactly one of the problems the Lean Startup tries to solve by combining Agile with Design Thinking).
Design Thinking has a prototyping stage highly focused on solution building, mainly concerned with validating solutions in the most efficient way possible in a “Show! Don’t tell!” manner. These solutions can potentially be services without any software at all! At this stage, the methodology connects with a lot of the Lean Startup principles and the idea of running experiments and building Minimum Viable Products (MVP) to get the most validated learning/insights that allow the project to progress with the minimum amount of effort possible!
In a nutshell, if you learn and practice Design Thinking you will become better equipped to create prototypes that help you validate solutions in the form of Product Increments in Agile lingo or MVPs in Lean Startup lingo.
So Design Thinking is the “God” methodology that rules all others?
Let me say that again: no!
If we look at fig. 1 we see all these touch each other at some point and many tools are shared by Design Thinking, The Lean Startup and Agile methodologies. I won’t go into detailed history now but if I did you would see how these relate to each other over time coming from common lines of thinking dating back to the 60s, with the The Lean Startup being the most recently born methodology (2011).
It’s not about asking what is the best methodology, but more what is the best one for a certain project/team/timeframe/goal (e.g. improve an existing website workflow VS starting a new business VS reducing an airport’s security waiting time). Also, you can import tools from one methodology into another (just like Eric Ries did when he created The Lean Startup).
An analogy I usually use is the band analogy. If each instrument is a tool, the music style is the methodology, the project is the current playing song and the band members are the team!
The same band can play different songs always within the same style with great results. Sometimes the band needs to play a new type of song and for this it needs to learn and play in a different style (rock&roll vs rumba). As the musicians get to known more styles and each other better, they can start fusing styles with one another, able to turn even the most boring song into something new and special ;)
In the end, I believe it’s important to know and experience methodologies in their purest form so we can later refer back to these when we need to move forward with the challenge at hand :)
Ok, so back to the DT-Bergen program. Should I go for it or not?
The final decision is of course yours! I won’t spend time writing about the program structure and the great speakers and mentors of it. You can read about that in the program’s website here.
What I can tell you is that I am very happy that I joined the program. It fits well with my previous knowledge, and its structure allows me to go deeper in practice into tools that are relevant within other methodologies too. I feel I am learning a lot that I can take back to our company and apply immediately (e.g. importing analysis/synthesis techniques into an ongoing User Research project).
As a bonus, the program is great fun too and I was lucky to be a part of a fantastic team with very clever and kind people with different professional and cultural backgrounds. This makes each time we work together a learning experience, not just from the program itself but also from each other.
To wrap up, one practical tip. If you do decide to enrol, I recommend you try to choose a project you can relate to in a deep level! If you cannot find one ask how you can propose another. I believe this is absolutely crucial since you and your team will be spending an intense and exciting 9 months working on it!
If you have questions or observations please drop me an email at firstname.lastname@example.org
And I will do my best to get back to you!