The design thinking movement is absurd (2018)(sts-news.medium.com)
sts-news.medium.com
The design thinking movement is absurd (2018)
https://sts-news.medium.com/the-design-thinking-movement-is-absurd-83df815b92ea
75 comments
Its funny to see this phenomenon repeat itself again and again in corporate America. Company X manages to become successful due to bunch of amorphous reasons. Some academic decides to reverse-engineer this messy process into a neatly packaged theory that has some kernal of obviousness at the heart of it. Then the academia-consultant-management complex takes it over and starts evangelizing it for $$ to companies and contexts that are only tangentially similar to the original company. Obviously the cut-paste theory fails to take hold in its new home. Rinse repeat till a new fad comes in. Lean, Agile, Design thinking...
I think this person is against the cottage industry that's popped up around the idea itself?
The core concept of "design thinking" isn't that wild — figure out what ails people, and design / build stuff that people need/want that makes their lives better. Then there's a bunch of tactics to go into how to do that.
I don't really understand the hype around it- seems like consultants and institutions have taken it on as the next big thing to squeeze a buck from it, but the core concepts and tactics are really useful for those who like building products for real users and use cases.
The core concept of "design thinking" isn't that wild — figure out what ails people, and design / build stuff that people need/want that makes their lives better. Then there's a bunch of tactics to go into how to do that.
I don't really understand the hype around it- seems like consultants and institutions have taken it on as the next big thing to squeeze a buck from it, but the core concepts and tactics are really useful for those who like building products for real users and use cases.
Based on over 15 years of experience as a product designer, having worked with Fortune 50 companies and having contributed to numerous successful products, I have reservations about the efficacy of design thinking. Just as there are both proficient and underperforming programmers, the same distinction exists among designers. Is it challenging to discern the difference? Absolutely. However, a process is just that — a process. What truly counts at the end of the day is the final product and the quality of communication throughout its development.
Excellent takedown. In my area there was a big "Systems Thinking" movement a few years ago. Not sure what happened to it.
It runs deep and wide though. "Unendurable Horrors of Leadership Camp" is another good one.
https://www.currentaffairs.org/2016/06/the-unendurable-horro...
It runs deep and wide though. "Unendurable Horrors of Leadership Camp" is another good one.
https://www.currentaffairs.org/2016/06/the-unendurable-horro...
six sigma was replaced by agile, which in 2023 often includes design thinking
I was put on a Six Sigma project when I was new to a company. Had run it after the guy leading it got lucky and died. Holy smokes... I can't begin to describe the codswallop that was dished out.
I studied this, it looked very nice in the abstract but when we had to apply it to actual design it was terrible way to do things.
Way more important was learning to do project profitability estimates based how each feature would contribute to increasing revenues, increasing expenses, decreasing revenues, decreasing costs. Simple as
Way more important was learning to do project profitability estimates based how each feature would contribute to increasing revenues, increasing expenses, decreasing revenues, decreasing costs. Simple as
what did you study specifically? Like what resource did you use?
Design Thinking is not about the actual design. Is a method or process to understand user needs, generate solutions and then review those solutions with the actual users.
Why I ask this and add the explanation is thar design thinking is not a project management metodology so it is not concerned with estimation, profitability, revenue, expenses, costs as a main focus. It can add those as constraints on the convergent phase but it is not about managing those. Or at least this is what I know about it from my experience.
Design Thinking is not about the actual design. Is a method or process to understand user needs, generate solutions and then review those solutions with the actual users.
Why I ask this and add the explanation is thar design thinking is not a project management metodology so it is not concerned with estimation, profitability, revenue, expenses, costs as a main focus. It can add those as constraints on the convergent phase but it is not about managing those. Or at least this is what I know about it from my experience.
Author spends a lot of time complaining about Design Thinking, and worrying about it "infecting" education, but he doesn't actually say what is wrong with it. He quotes a few woolly phrases that look like the introductory sentences in an Overview section, then extrapolates from those as a detailed description of the whole topic. No wonder it looks vapid to him.
I'm not a design expert but AIUI, Design Thinking brings empathy with the user to the forefront of the design process and makes it a first-class factor. My own experience of the outcome of this process (writing software to such designs) is very largely positive.
I'm not a design expert but AIUI, Design Thinking brings empathy with the user to the forefront of the design process and makes it a first-class factor. My own experience of the outcome of this process (writing software to such designs) is very largely positive.
The problem with Design Thinking is that Design Thinking has become a cargo-cult of meaningless buzzwords and hot air. The same can be said about Agile -- it's just a collection of buzzwords loosely connected into a "framework" or "approach" or "school of thought" but it's certainly difficult to put an exact pin on what exactly DT and Agile entail.
But if we can't agree on the specifics -- at least we can agree on the broad points right? - Agile is about iterating quickly, making smaller changes more frequently, etc. - DT is about empathizing with the end user, considering the problem before solving it, and then attempting to fix it and asking for feedback
The problem is, once you cut through all the bullshit, you're left with what is really just common-sense wisdom. So they're faced with a choice: - Either you teach the core concept sans-BS, which can't be monetized. - Or you build an entire ecosystem of hot air, buzzwords, tooling, artifacts, blog posts and rituals around your obvious wisdom, which is how we ended up with Stories and Sprints and User Points and Epics and JIRA and Scrum and all the other crap. You can now sell $12,000 bootcamps, $100k software, etc.
But if we can't agree on the specifics -- at least we can agree on the broad points right? - Agile is about iterating quickly, making smaller changes more frequently, etc. - DT is about empathizing with the end user, considering the problem before solving it, and then attempting to fix it and asking for feedback
The problem is, once you cut through all the bullshit, you're left with what is really just common-sense wisdom. So they're faced with a choice: - Either you teach the core concept sans-BS, which can't be monetized. - Or you build an entire ecosystem of hot air, buzzwords, tooling, artifacts, blog posts and rituals around your obvious wisdom, which is how we ended up with Stories and Sprints and User Points and Epics and JIRA and Scrum and all the other crap. You can now sell $12,000 bootcamps, $100k software, etc.
Agile is clearly defined below
Design thinking is letting user requirements and their actual use cases dictate product definition and execution rather than feature cram and technology momentum.
It's literally the base of Steve Jobs most famous speech before launching the iPod -- it's not about Mips and Bips, it's about the experience users wants. Something the author of this gets insanely wrong.
Like the author, you complain about something rather simple and obvious to understand -- then just sort of... rant.
Design thinking is letting user requirements and their actual use cases dictate product definition and execution rather than feature cram and technology momentum.
It's literally the base of Steve Jobs most famous speech before launching the iPod -- it's not about Mips and Bips, it's about the experience users wants. Something the author of this gets insanely wrong.
Like the author, you complain about something rather simple and obvious to understand -- then just sort of... rant.
> Agile is about iterating quickly, making smaller changes more frequently, etc.
Agile is about revising the plan frequently to adjust it for reality. All of those things are tools, not the goal; and if you do all of them but still don't revise the plan, you won't get any of the benefit.
Agile is about revising the plan frequently to adjust it for reality. All of those things are tools, not the goal; and if you do all of them but still don't revise the plan, you won't get any of the benefit.
Good point actually, thanks.
Granted, it's even a bit hard to make fast iterations without revising the plan, so it's natural to ignore the difference. But some management structures achieve just that.
Stanford's website is apparently unable to explain it either: https://www.gsb.stanford.edu/exec-ed/programs/design-thinkin...
Judging from the "participant profile", it sounds like the kind of thing you do when you have money to spend before the end of the year.
Judging from the "participant profile", it sounds like the kind of thing you do when you have money to spend before the end of the year.
I'm gonna take a stab at this because I don't think it's that complicated.
Design thinking is a methodology for designing things, often products. It has 5 steps:
1. Empathize. Find your intended user and try to understand them, their expectations, wants, needs, and fears.
2. Define. Based on understanding your user, what are you trying to actually do? What are the problem(s) you want to solve for the user?
3. Ideate. Get a bunch of people in a room and have a no-judgement brainstorming fest around solving the problem(s) you defined. Come up with a ton of ideas! Then look at them all critically and remove the less priomising ones.
4. Prototype. Make MVPs for a promising idea or ideas.
5. Test. Take your MVP to your target user. See how they react. Go back to prototype and adjust the idea based on feedback, or pick a different idea out of the ideation process if this one is a bust. Repeat until your prototype is good enough that you're confident to scale up.
Within each of these steps, there are a few tools/techniques you can learn to structure them more if you like. There are also no shortage of experts and consultants who will take your money to expound on the finer points of each part of the process. You can go as deep into the rabbit hole as is useful.
Design thinking is a methodology for designing things, often products. It has 5 steps:
1. Empathize. Find your intended user and try to understand them, their expectations, wants, needs, and fears.
2. Define. Based on understanding your user, what are you trying to actually do? What are the problem(s) you want to solve for the user?
3. Ideate. Get a bunch of people in a room and have a no-judgement brainstorming fest around solving the problem(s) you defined. Come up with a ton of ideas! Then look at them all critically and remove the less priomising ones.
4. Prototype. Make MVPs for a promising idea or ideas.
5. Test. Take your MVP to your target user. See how they react. Go back to prototype and adjust the idea based on feedback, or pick a different idea out of the ideation process if this one is a bust. Repeat until your prototype is good enough that you're confident to scale up.
Within each of these steps, there are a few tools/techniques you can learn to structure them more if you like. There are also no shortage of experts and consultants who will take your money to expound on the finer points of each part of the process. You can go as deep into the rabbit hole as is useful.
Isn't all that just the standard process of design/development? Have I been engaging in "Design Thinking" all these years without even knowing it?
The difference is Design Thinking requires extensive documentation for each step.
You don't just empathize, you create characters with backstory.
You don't just define, you create a story outline with plot, protagonists, and antagonists.
You don't just ideate, you write novellas of your greatest achievements: deciding on the right color for error messages, the perils of rounded corners, and how you overcame the adversity of outdated stereotypes to make buttons that are fair and equitable to all people.
And so on...
You don't just empathize, you create characters with backstory.
You don't just define, you create a story outline with plot, protagonists, and antagonists.
You don't just ideate, you write novellas of your greatest achievements: deciding on the right color for error messages, the perils of rounded corners, and how you overcame the adversity of outdated stereotypes to make buttons that are fair and equitable to all people.
And so on...
> The difference is Design Thinking requires extensive documentation for each step.
Design thinking is not a fixed process. If you make a lot of documentation on each step, that's on you.
The idea is just to define what you create from the point of view of the users. And yes, it's probably what the GP was doing all this time.
Design thinking is not a fixed process. If you make a lot of documentation on each step, that's on you.
The idea is just to define what you create from the point of view of the users. And yes, it's probably what the GP was doing all this time.
Could be a standard workflow to many designers.
At least for new products. But I think some of these steps can be forgotten in established products. Many teams find themselves building features stakeholders asked, and DT can help going back to discovering what users actually want
However this can also backfire and good independent ideas can be shut down because they weren't found in the first 2 steps of the Design Thinking process.
With DT thinking "solution first" is kind of forbidden.
At least for new products. But I think some of these steps can be forgotten in established products. Many teams find themselves building features stakeholders asked, and DT can help going back to discovering what users actually want
However this can also backfire and good independent ideas can be shut down because they weren't found in the first 2 steps of the Design Thinking process.
With DT thinking "solution first" is kind of forbidden.
The magic sauce is the empathy part. Which is different than what was done back then in male-dominated, boomer-centric work places. It's equivalent of making a safe space before embarking on the rest of the standard design/dev processes.
How you feel about safe spaces will be analogous about how you feel of design thinking. A lot of consultants cashed in on this trend to sell all kinds of stupid things. That's also what he's talking about.
Now with new generation coming in, empathy is by default. Therefore, if you really think about it, design thinking is fizzling out because it's now the standard.
How you feel about safe spaces will be analogous about how you feel of design thinking. A lot of consultants cashed in on this trend to sell all kinds of stupid things. That's also what he's talking about.
Now with new generation coming in, empathy is by default. Therefore, if you really think about it, design thinking is fizzling out because it's now the standard.
No better at MIT/Sloan. The illustration under "Here’s what you need to know to get started" is utterly generic and trite.
https://mitsloan.mit.edu/ideas-made-to-matter/design-thinkin...
https://mitsloan.mit.edu/ideas-made-to-matter/design-thinkin...
> Design Thinkers giver their students power without knowledge, “creative confidence” without actual capabilities.
this is the problem. a lot of curicculum time has been taken away from basic/fundamental skills in order to do DT.
this is the problem. a lot of curicculum time has been taken away from basic/fundamental skills in order to do DT.
And to make matters worse a much better way to learn true design is applying these basic/fundamental skills to problems for real.
Opportunity costs matter in education and are swept under the rug by every promotor of new content.
Opportunity costs matter in education and are swept under the rug by every promotor of new content.
He also doesn't actually describe what it is. I don't think he knows any more than the people he's complaining about.
Really? I thought it was pretty clear that the author thinks Design Thinking is composed of vague ideas and vapid phrases. Moreover, the author cites a significant number of noteworthy designers that make compelling arguments that Design Thinking is nonsense that produces a skewed picture of the design process.
I think your comment dismisses the article without giving a compelling reason why.
I think your comment dismisses the article without giving a compelling reason why.
He eventually quotes someone as:
“It’s an approach to problem-solving based on a few easy-to-grasp principles that sound obvious:‘Show Don’t Tell,’ ‘Focus on Human Values,’ ‘Craft Clarity,’ ‘Embrace Experimentation,’ ‘Mindful of Process,’ ‘Bias Toward Action,’ and ‘Radical Collaboration.’”
All of those are pretty sound principals proven to be effective by most innovators though. Screaming at people is easier than actually learning to be effective, and I suspect is the root of his outrage.
“It’s an approach to problem-solving based on a few easy-to-grasp principles that sound obvious:‘Show Don’t Tell,’ ‘Focus on Human Values,’ ‘Craft Clarity,’ ‘Embrace Experimentation,’ ‘Mindful of Process,’ ‘Bias Toward Action,’ and ‘Radical Collaboration.’”
All of those are pretty sound principals proven to be effective by most innovators though. Screaming at people is easier than actually learning to be effective, and I suspect is the root of his outrage.
Those are some strong opinions of design thinking.
I always thought it was just requirements and design but done by specialists from service design backgrounds. I’ve seen the results of workshops, and although very expensive, are very useful because they put the project focus’s on the users rather than the technology. And, if someone has hired design thinking specialists, then you at least know that the leadership has a commitment to usability and not putting the cart before the horse. For instance, I’ve seen results of design thinking result in drastically reduced savings because they avoided buying technology that they didn’t need.
I always thought it was just requirements and design but done by specialists from service design backgrounds. I’ve seen the results of workshops, and although very expensive, are very useful because they put the project focus’s on the users rather than the technology. And, if someone has hired design thinking specialists, then you at least know that the leadership has a commitment to usability and not putting the cart before the horse. For instance, I’ve seen results of design thinking result in drastically reduced savings because they avoided buying technology that they didn’t need.
You may want to edit this, unless you see an upside to "drastically reduced savings."
In addition to the usual Medium related complaints, I spend an inordinate amount of time scrolling a giant polemic against something I didn’t even have a notion of a definition of, only knowing thst it was supposedly bullshit, whatever it was.
This article needs work.
This article needs work.
Over the years, organizations look inward. Their products, features and practices become more self-serving and less user-serving. Design Thinking aims to flip people's mindset to re-focus on user needs over and above internal corporate needs. That's pretty much all there is to it.
The way I see it, Design Thinking is an idea is older than Agile, and has followed a similarly problematic evolution. At the core of both, there are a number of insightful and meaningful observations about how to approach difficult problems, and both offer some useful tools. But once both ideas got into the wild, people just mutated them until they were barely recognizable, made them incomplete and, okay, absurd. Consultants took them over and turned them into products: got a dysfunctional engineering team? Just add Agile. Need creativity? Sprinkle some Design Thinking on it. That's just what people do.
But I work in an organization that is still building its product side, and this stuff is not obvious to them. I talk to a lot of smart people who don't know that you should build small things and iterate on them. I meet a lot of people who don't think to question the assumptions of the problem statement. I assumed all this stuff was natural, because I came here from tech startups, where it's been in the air for twenty or thirty years. But, it turns out it's not all obvious, it has to be taught. I guess that, whatever faults they have, Agile and Design Thinking have nudged a lot of people in the right direction, when nothing else is apparently doing that.
But I work in an organization that is still building its product side, and this stuff is not obvious to them. I talk to a lot of smart people who don't know that you should build small things and iterate on them. I meet a lot of people who don't think to question the assumptions of the problem statement. I assumed all this stuff was natural, because I came here from tech startups, where it's been in the air for twenty or thirty years. But, it turns out it's not all obvious, it has to be taught. I guess that, whatever faults they have, Agile and Design Thinking have nudged a lot of people in the right direction, when nothing else is apparently doing that.
All these frameworks are ways of turning what should be common sense into bureaucratic procedures that can be used without needing to think independently and thus more widely used. "Lean" is another example of this. They serve the dual purpose of sounding better to leadership types who don't like the idea of just studying the problem and coming up with a solution, and requiring less experience and autonomy to execute.
I mean, you're not wrong, but the problem isn't with the frameworks themselves.
The problem is that there is a cottage industry of companies, consultants and individual contributors trying to sell those ideas to everyone else, but common sense doesn't really pay the bills. So they must package "Agile" or "Design Thinking" or whatever into something that actually costs a lot of money and makes them feel important and authoritative.
"Individuals and interactions over processes and tools" doesn’t pay and actually saves money, so things like Agile naturally get lost in the translation.
The problem is that there is a cottage industry of companies, consultants and individual contributors trying to sell those ideas to everyone else, but common sense doesn't really pay the bills. So they must package "Agile" or "Design Thinking" or whatever into something that actually costs a lot of money and makes them feel important and authoritative.
"Individuals and interactions over processes and tools" doesn’t pay and actually saves money, so things like Agile naturally get lost in the translation.
Don't hate the player, hate the game...
It's difficult for leaders of legacy-built organizations to create space for common sense thinking, and when they see a room full of their employees creating and collaborating in new ways, then they pay to have you come back because for whatever reason they didn't have the time, skill or capacity to make their teams act more creatively and collaboratively on their own. Rarely is it transformative. Sometimes it's completely useless (especially when packaged into buzzword-y platitudes). Most of the time it's somewhere in-between just like any other process/culture/change improvement from leadership.
These leaders hire these companies and consultants because they were resting on their laurels instead of actively building culture while the legacy org was doing fine. Then comes a crisis or paradigm shifting moment and there is no recourse.
With visionary leadership and proactive management toward better culture and talent (which is hard to do consistently), said "cottage industry" would be much smaller.
It's difficult for leaders of legacy-built organizations to create space for common sense thinking, and when they see a room full of their employees creating and collaborating in new ways, then they pay to have you come back because for whatever reason they didn't have the time, skill or capacity to make their teams act more creatively and collaboratively on their own. Rarely is it transformative. Sometimes it's completely useless (especially when packaged into buzzword-y platitudes). Most of the time it's somewhere in-between just like any other process/culture/change improvement from leadership.
These leaders hire these companies and consultants because they were resting on their laurels instead of actively building culture while the legacy org was doing fine. Then comes a crisis or paradigm shifting moment and there is no recourse.
With visionary leadership and proactive management toward better culture and talent (which is hard to do consistently), said "cottage industry" would be much smaller.
I call that industry "holistic agile" because it is to agile what holistic medicine is to medicine.
Nah. Common sense isn't common, logical, or innate. It's important to communicate common sense, otherwise people just won't have it.
Those frameworks were created because those specific instances of common sense were exceedingly rare but still important. They were condensed into short lessons so people could read them, think for themselves about gains and loses, and adapt them to where they are needed.
The fact that leadership often can't do any of those 3 things right created an industry of fraudulent education teaching bureaucratic procedures. But that doesn't take anything from the original movements.
Those frameworks were created because those specific instances of common sense were exceedingly rare but still important. They were condensed into short lessons so people could read them, think for themselves about gains and loses, and adapt them to where they are needed.
The fact that leadership often can't do any of those 3 things right created an industry of fraudulent education teaching bureaucratic procedures. But that doesn't take anything from the original movements.
Two things consider: First, common sense is merely the accumulated human wisdom available to a group at one time. It's common sense today because Lean and Agile has made it common sense.
Second, we can think about these methodologies as duplo blocks, and smaller practices in concert as lego blocks. You're welcome to make more bespoke blocks, but iterating from first principles every time is just not necessary when we can rely on the common wisdom gained by using more common toolkits. First principles thinking is expensive and doesn't scale.
Second, we can think about these methodologies as duplo blocks, and smaller practices in concert as lego blocks. You're welcome to make more bespoke blocks, but iterating from first principles every time is just not necessary when we can rely on the common wisdom gained by using more common toolkits. First principles thinking is expensive and doesn't scale.
Planning is not common sense. It's a skill that takes years of practice, just like playing a piano or programming.
And just like programming or playing a piano, you can spend years of doing it and learn nothing because you were doing it wrong.
There are people who apply design patterns without really understanding them and there are people who apply planning methodologies without understanding them. I'd say that it's more common than not.
And just like programming or playing a piano, you can spend years of doing it and learn nothing because you were doing it wrong.
There are people who apply design patterns without really understanding them and there are people who apply planning methodologies without understanding them. I'd say that it's more common than not.
But we aren't teaching management "planning", we are teaching rigid structured systems for ticket tracking. We are teaching meaningless mumbo jumbo to people with zero experience, seemingly even with toy examples, of solving difficult or complicated problems that require expert input, and managing people.
Every single course I have ever seen on this stuff treats humans as black box cogs that perfectly do anything you define in a ticket, even when you do a terrible job defining something. That's not teaching management to plan, that's teaching management a board game.
Meanwhile my CS class on agile and project management was just managing a real, large, somewhat purposely overwhelming project so we could stress the system and deal with failures. It showed us the value that some structure could bring, and also how you often clearly need to step back from that structure to do actual work.
Every single course I have ever seen on this stuff treats humans as black box cogs that perfectly do anything you define in a ticket, even when you do a terrible job defining something. That's not teaching management to plan, that's teaching management a board game.
Meanwhile my CS class on agile and project management was just managing a real, large, somewhat purposely overwhelming project so we could stress the system and deal with failures. It showed us the value that some structure could bring, and also how you often clearly need to step back from that structure to do actual work.
No different than CS classes dumping design patterns onto students.
I think you just had a good teacher.
I think you just had a good teacher.
Frameworks are created by abstracting a solution from a class of problems. Users adopt frameworks as they provide a solution to a class of their problems. A key benefit frameworks can provide is scale.
Now there is a class of people (framework industrial complex) that do not care about real solutions but see an opportunity to scale themselves leveraging frameworks to push them to unsuspecting victims, uncaring managers and their teams. As long as universal applicability and scale expands faster than bad press in places decision makers frequent the bubble expands and money is made.
Now there is a class of people (framework industrial complex) that do not care about real solutions but see an opportunity to scale themselves leveraging frameworks to push them to unsuspecting victims, uncaring managers and their teams. As long as universal applicability and scale expands faster than bad press in places decision makers frequent the bubble expands and money is made.
Lean manufacturing in Japan has been a thing since the 50s, with a focus on kaizen, flow, pulling, etc, yet lots of companies still do work in batches today, to their detriment and waste.
Great points. Kind of resonated and caused a flood of thoughts - appreciative of it.
The kinship between design sprints and agile sprints can look like a match made in heaven… on the oversimplified views of details yet to be found, and can be useful if the problem and some possible solutions are unknown and need to be understood.
But once unknowns are better understood, it feels better to consider multiple methodologies.
Scrum oddly can feel great pre product launch, but doesn’t always make sense afterwards. It can really help get a lot done in some cases. But, is the team experienced, or not, and self directed or not, and how familiar are they with the domain they are working in.
My product consulting background revealed the value of a hybrid design-agile/waterfall loop that leverages the sweet spot of figuring out the unknowns and executing what was known in a way that the business could understand.
Product continues to teach me that there’s always lots to learn from other. Being too attached to one way instead of learning how the currents of each style can be aligned, or not is becoming a lot of fun for me, and I hope to be able to connect with others feeling similarily.
Except, as a technologist on the product side, being acutely literate and aware of what hardware, networking, and software can, and can't do today and in the next few years can become a bit of an unfair advantage when looking at a pipeline or roadmap, along with business trends or wishes of the business.
Design thinking allows people to come together to understand a problem and some ways to maybe solve it. I think that’s always been the biggest benefit it’s provided me, including letting the team learn together when a hypothesis turned out to be right and when it wasn’t.
What design can have a tough time with is not knowing the capabilities and possibilities where tech is involved to sovle it.
Too often, the outputs of Design sprints are thrown on the laps on tech to figure out, when technologist are human beings as well, are left downstream to pick up the pieces.. too often much to the chagrin to business degrees.
Design Thinking when driven by the business degrees can be a form of keeping more seats than needed at that design / influence / direction table.
I don't advocate for removing or reducing those seats, only increasing the seats for the people who can help give feedback on the feasibility of something in the given timelines and budget.
All to say there's not a better time for tech folks to be able to learn more business than it is the other way around.
This hybrid Technical/Business Analyst or Architect is increasingly here to stay, and you can't fluff your way through it as much.
The kinship between design sprints and agile sprints can look like a match made in heaven… on the oversimplified views of details yet to be found, and can be useful if the problem and some possible solutions are unknown and need to be understood.
But once unknowns are better understood, it feels better to consider multiple methodologies.
Scrum oddly can feel great pre product launch, but doesn’t always make sense afterwards. It can really help get a lot done in some cases. But, is the team experienced, or not, and self directed or not, and how familiar are they with the domain they are working in.
My product consulting background revealed the value of a hybrid design-agile/waterfall loop that leverages the sweet spot of figuring out the unknowns and executing what was known in a way that the business could understand.
Product continues to teach me that there’s always lots to learn from other. Being too attached to one way instead of learning how the currents of each style can be aligned, or not is becoming a lot of fun for me, and I hope to be able to connect with others feeling similarily.
Except, as a technologist on the product side, being acutely literate and aware of what hardware, networking, and software can, and can't do today and in the next few years can become a bit of an unfair advantage when looking at a pipeline or roadmap, along with business trends or wishes of the business.
Design thinking allows people to come together to understand a problem and some ways to maybe solve it. I think that’s always been the biggest benefit it’s provided me, including letting the team learn together when a hypothesis turned out to be right and when it wasn’t.
What design can have a tough time with is not knowing the capabilities and possibilities where tech is involved to sovle it.
Too often, the outputs of Design sprints are thrown on the laps on tech to figure out, when technologist are human beings as well, are left downstream to pick up the pieces.. too often much to the chagrin to business degrees.
Design Thinking when driven by the business degrees can be a form of keeping more seats than needed at that design / influence / direction table.
I don't advocate for removing or reducing those seats, only increasing the seats for the people who can help give feedback on the feasibility of something in the given timelines and budget.
All to say there's not a better time for tech folks to be able to learn more business than it is the other way around.
This hybrid Technical/Business Analyst or Architect is increasingly here to stay, and you can't fluff your way through it as much.
I used to work for a company that makes CAD software for architects.
Quite a lot of our customers and potential customers that I'd bump into at conferences and the like were insufferable. They think of themselves as "designers" not "architects", and they wore black turtlenecks and talk about Changing the World through the power of Design. It's like a cult. No one can talk specifics, no one can point to a design that will change the world, just Design in general, and they even have their little uniforms.
I had to sit through so many goddamn talks about Design Thinking and how it's Revolutionizing Everything.
Three years in that job and I still don't have a clue was Design Thinking is. It reminds me more than anything of those useless "collaboration frameworks" that HR keeps coming up with.
Quite a lot of our customers and potential customers that I'd bump into at conferences and the like were insufferable. They think of themselves as "designers" not "architects", and they wore black turtlenecks and talk about Changing the World through the power of Design. It's like a cult. No one can talk specifics, no one can point to a design that will change the world, just Design in general, and they even have their little uniforms.
I had to sit through so many goddamn talks about Design Thinking and how it's Revolutionizing Everything.
Three years in that job and I still don't have a clue was Design Thinking is. It reminds me more than anything of those useless "collaboration frameworks" that HR keeps coming up with.
Architects live in a weird world. Putting a lot of effort into puffing yourself up via dress, language, charisma, and arrogance is tolerated and to some extent is even the norm. People tolerate it in their peers because they all understand how much can depend on their ability to impress people who have no way to judge their professional skill. Unlike software development, the profession of architecture appreciates architects who enhance its glamor and mystique. It's a weird thing, because they understand how ridiculous it is, but they also encounter clients who expect it. Sometimes they'll look down on someone who enjoys it too much or inhabits it too thoroughly, but at the same time, they respect it as a professional skill that they would use if they had it.
I empathize with that as I went to grad school in a school of architecture. Ended up specializing in software in their department of urban planning. Calling yourself a designer instead of an architect is just a way to be more inclusive to landscape architects, interior designers, material engineers, and everyone else who works in a the design software space.
Design thinking is just a concept for thinking about problems. Whether you're a plumber or a fashion designer, solving your problem with software first is the antithesis of design thinking. It's just a philosophy of first principles built for anyone who creates physical or digital products.
Design thinking is just a concept for thinking about problems. Whether you're a plumber or a fashion designer, solving your problem with software first is the antithesis of design thinking. It's just a philosophy of first principles built for anyone who creates physical or digital products.
> Three years in that job and I still don't have a clue was Design Thinking is.
The things you create must have a form derived from how the people that interact with it think and what problem they are trying to solve.
I'd say it's Bauhaus adapted to complex products, but then, Bauhaus themselves were just adapting the idea too. I wouldn't be surprised if somebody has some source for the idea from Ancient Greece.
The things you create must have a form derived from how the people that interact with it think and what problem they are trying to solve.
I'd say it's Bauhaus adapted to complex products, but then, Bauhaus themselves were just adapting the idea too. I wouldn't be surprised if somebody has some source for the idea from Ancient Greece.
I wonder how much money I'd be making by now if I always wore nothing but black turtlenecks. There seems to be something to it in terms of convincing others that one is more competent than they are.
[deleted]
I once worked for a company that was kind of like this for Agile. They had an old legacy app that was the cash cow. The next gen thingy was agile w/ a capital A we'd say but we really just wasted a lot of time doing agile ceremonies and other nonsense.
To me, this is a weird argument to make. I'm a product manager, and I use design thinking as part of my approach all the time. Does that mean I'm reducing all product innovation to a linear five-step approach? Hell no!
I think the best way to use design thinking outside of a pure design agency context is eclectically, not as a religion. The point of methodology is not to take the humans out of the process - it's to give humans tools that they can then consciously use to define and adjust the process according to their own needs. If you go pay $12k for a design thinking bootcamp and expect that that's somehow going to make you design radically different or better things, that's off-base. What you're getting for your time and money are a few new tools/approaches you can whip out when appropriate.
This is similar to a lot of the complaints I see about Agile/Scrum from teams who've had it forced on them in a very rigid way by PMs, scrum masters, or corporate policy. If the process is causing more pain than it's preventing, we should change it or remove it. If we can't do that, the process is a prison, not a helper. IMO that's what "people over process" means.
Aside: Two quick rebuttals to points the author made:
- There's no room for "crit" in design thinking. That's just wrong - what do you think the "converge" step is about?
- The Post-it notes. My workplace is 100% remote. When we do in-person gatherings, we sometimes use post-it notes for ideation. Otherwise, we use Notion, Google Docs, and Figma. Again, I think the problem is the author is working with design thinking zealots who are taking the methodology to an inflexible extreme.
I think the best way to use design thinking outside of a pure design agency context is eclectically, not as a religion. The point of methodology is not to take the humans out of the process - it's to give humans tools that they can then consciously use to define and adjust the process according to their own needs. If you go pay $12k for a design thinking bootcamp and expect that that's somehow going to make you design radically different or better things, that's off-base. What you're getting for your time and money are a few new tools/approaches you can whip out when appropriate.
This is similar to a lot of the complaints I see about Agile/Scrum from teams who've had it forced on them in a very rigid way by PMs, scrum masters, or corporate policy. If the process is causing more pain than it's preventing, we should change it or remove it. If we can't do that, the process is a prison, not a helper. IMO that's what "people over process" means.
Aside: Two quick rebuttals to points the author made:
- There's no room for "crit" in design thinking. That's just wrong - what do you think the "converge" step is about?
- The Post-it notes. My workplace is 100% remote. When we do in-person gatherings, we sometimes use post-it notes for ideation. Otherwise, we use Notion, Google Docs, and Figma. Again, I think the problem is the author is working with design thinking zealots who are taking the methodology to an inflexible extreme.
Innovations are hard, UI and especially UX even harder and establishing a successful product in the market - you get the superlative.
That said, I have never heard that DT has established a product that is widely popular (Wikipedia features only minor and highly unspecific use cases). There are some cases within a larger project, were DT might bears fruit.
Innovation is an iterative process which costs money independently of the approach you take. Is the company willing to do this? In most cases the answer is no.
So how could DT help then? Using interdisciplinary approaches and methods? Then you might have a communication problem in general which won't DT solve. Why should a team magically work differently, takes care of other views and perspectives?
My experience with DT (IT domain) has always been negative. You apply 10 minute solutions to hard problems - this does not work, it often made things worse ("Use DT! I don't get why it takes you so long while DT is a matter of minutes to hours."). In my experience it is the "feeling better but not getting better" approach to problems.
That said, I have never heard that DT has established a product that is widely popular (Wikipedia features only minor and highly unspecific use cases). There are some cases within a larger project, were DT might bears fruit.
Innovation is an iterative process which costs money independently of the approach you take. Is the company willing to do this? In most cases the answer is no.
So how could DT help then? Using interdisciplinary approaches and methods? Then you might have a communication problem in general which won't DT solve. Why should a team magically work differently, takes care of other views and perspectives?
My experience with DT (IT domain) has always been negative. You apply 10 minute solutions to hard problems - this does not work, it often made things worse ("Use DT! I don't get why it takes you so long while DT is a matter of minutes to hours."). In my experience it is the "feeling better but not getting better" approach to problems.
My graphic design bachelor thesis for uni was a exhaustive usability&a11y study on all my uni had for web at that moment. From that work we built and made a redesign for all of its web portals and websites and co, which somehow still stands today, almost 10 years after.
Back then I was told _that_ was design thinking. Kind of a scientific method approach to do things.
But over the years I felt it became another buzzword. Everybody started to talk about it, everybody was allegedly doing it, but everybody got ahold of their own definition for it, so now it seems it lost its meaning.
Back then I was told _that_ was design thinking. Kind of a scientific method approach to do things.
But over the years I felt it became another buzzword. Everybody started to talk about it, everybody was allegedly doing it, but everybody got ahold of their own definition for it, so now it seems it lost its meaning.
Yikes. I had to dig deep to read that rant. Ultimately, the best definition in the article defines Design Thinking as such:
> “It’s an approach to problem-solving based on a few easy-to-grasp principles that sound obvious: - ‘Show Don’t Tell,’ - ‘Focus on Human Values,’ - ‘Craft Clarity,’ - ‘Embrace Experimentation,’ - ‘Mindful of Process,’ - ‘Bias Toward Action,’ and - ‘Radical Collaboration.’”
I'm not really sure why he is ranting though - these are the principals espoused by some of the most successful VC's, founders, and world renowned Architects.
Does anyone understand why he is so angry?
> “It’s an approach to problem-solving based on a few easy-to-grasp principles that sound obvious: - ‘Show Don’t Tell,’ - ‘Focus on Human Values,’ - ‘Craft Clarity,’ - ‘Embrace Experimentation,’ - ‘Mindful of Process,’ - ‘Bias Toward Action,’ and - ‘Radical Collaboration.’”
I'm not really sure why he is ranting though - these are the principals espoused by some of the most successful VC's, founders, and world renowned Architects.
Does anyone understand why he is so angry?
The whole design thinking mania in the early 2010s was just annoying for actual designers, having to fend off more entry level ideas that have already been considered and rejected. Just because you did a workshop in astronaut thinking doesn't entitle you to start planning spacewalks.
There seems to be a certain type of personality/intellect that tends to develop a powerful aversion to oversimplifying abstractions.
After reading this, I’m still not quite sure what “Design Thinking” is? It seems like a fancy term for focusing your design on the user, but then I don’t understand the hype nor the hate. Maybe it’s just hype hate? What am I missing?
The way I've interpreted it, when done well, it's usually focused on designing experience first (ie the "what") and then focusing on the "how" afterward. Think about a well designed mobile app with thought out user journeys vs. a circa 1999 VB6 app, which was focused on whatever IT nonsense was were doing first.
When done poorly, it means you get trapped in a room with some folks with religious zeal and a set of post-it notes in various colors, sharpies, and colored paper sticky dots for a few days. Afterward, you get... not much. It's just like agile.... if the "practitioner" is hyper-focused on the rituals and ceremony, it's easy to miss doing actual work.
My personal beef with the concept is that the ceremonial aspects mean you need a special UX/design/etc specialist, who comes in and leaves. Usually the "design" processes focus on 80% solutions, and nobody comes back to finish the other 20%. You used to notice this when people built out responsive websites -- key functions that weren't in the "Top X", would just disappear on mobile.
When done poorly, it means you get trapped in a room with some folks with religious zeal and a set of post-it notes in various colors, sharpies, and colored paper sticky dots for a few days. Afterward, you get... not much. It's just like agile.... if the "practitioner" is hyper-focused on the rituals and ceremony, it's easy to miss doing actual work.
My personal beef with the concept is that the ceremonial aspects mean you need a special UX/design/etc specialist, who comes in and leaves. Usually the "design" processes focus on 80% solutions, and nobody comes back to finish the other 20%. You used to notice this when people built out responsive websites -- key functions that weren't in the "Top X", would just disappear on mobile.
A realistic portrayal. Always amusing when I step into a conference room and the little cubbies or trays full of post it notes and sharpies and markers left behind telegraphs how the next few hours in talking with the stakeholders will go since it's clear now I'm here for the "how".
Then when I started leading the design thinking sessions all I can think of is how silly all this is. When we went remote during covid, introducing in virtual whiteboards like Miro and Figma, made the rituals and ceremonies more tolerable and more importantly actionable.
After all this time weaving through Stanford where this all went down, the corporate war rooms all over, settling down now, ultimately I think it just comes down to this: design thinking is really just empathetically solving problems rather than apathetically solving problems (as in working off requirement documents or best practices or protocols or just because you're told what to do).
All the little ceremonies and rituals is inclusivity of everyone to empathize and feel good about each other, and consider things from additional POVs. Which back then at the tail end of Gen-Y transition into the workforce was needed. Now you talk to the Gen-Z workforce about using empathy at work more and they'll just go: facts.
Then when I started leading the design thinking sessions all I can think of is how silly all this is. When we went remote during covid, introducing in virtual whiteboards like Miro and Figma, made the rituals and ceremonies more tolerable and more importantly actionable.
After all this time weaving through Stanford where this all went down, the corporate war rooms all over, settling down now, ultimately I think it just comes down to this: design thinking is really just empathetically solving problems rather than apathetically solving problems (as in working off requirement documents or best practices or protocols or just because you're told what to do).
All the little ceremonies and rituals is inclusivity of everyone to empathize and feel good about each other, and consider things from additional POVs. Which back then at the tail end of Gen-Y transition into the workforce was needed. Now you talk to the Gen-Z workforce about using empathy at work more and they'll just go: facts.
So I guess it’s almost like the “Scrum” of the design world. It can help you focus on the right thing, but just following the process won’t magically give you good results.
Focusing on the what with no grounding of the how is the start of the ongoing struggle between design and engineering. Eventually you need a tight feedback loop between what and how, as the how will do a good job tearing up those post-it notes otherwise.
Well put.
I work in architecture and went to school for it. The only reasonable definition of design thinking that I’ve heard is “a way of thinking that considers the affordances of a design decision across multiple scales or perspectives.”
For instance, you need a floor plate of the second floor of a building to be a bit bigger to accommodate a certain type of room. So you make the second floor cantilever over the entrance, thereby also providing the functionality of an awning that protects people from rain while they wait for the bus. This is a bit of a silly example because the cantilever adds cost etc but that’s the general idea. Identifying opportunities that are “win-win,” might be a crude way to say it.
In my experience this is a particular mode of thinking that some people are clearly better at, and those people tend to be the superstar designers. Whether it can be taught or not is a bit of an open question.
Any other definition I’ve heard for “design thinking” doesn’t really make sense to me, but that might just reflect my background.
For instance, you need a floor plate of the second floor of a building to be a bit bigger to accommodate a certain type of room. So you make the second floor cantilever over the entrance, thereby also providing the functionality of an awning that protects people from rain while they wait for the bus. This is a bit of a silly example because the cantilever adds cost etc but that’s the general idea. Identifying opportunities that are “win-win,” might be a crude way to say it.
In my experience this is a particular mode of thinking that some people are clearly better at, and those people tend to be the superstar designers. Whether it can be taught or not is a bit of an open question.
Any other definition I’ve heard for “design thinking” doesn’t really make sense to me, but that might just reflect my background.
Couldn't you come to the same conclusion about making the 2nd floor cantilever over the entrance and call it engineering? I guess it depends on how you personally arrive to the conclusion, but the results can be interpreted.
My biggest critique of design thinking is that it has this Taylorist elitism (designer observes how a user does something) sorta built into it, and as a consequence, it caters to new users rather than power users. In other words, there is no consideration that the most effective tools actually require some learning and expertise to master them.
IMHO it's better if the designer becomes the user, by actually learning the particular discipline for which the thing is being designed, rather than just observing an expert. Kind of like method acting.
IMHO it's better if the designer becomes the user, by actually learning the particular discipline for which the thing is being designed, rather than just observing an expert. Kind of like method acting.
The strongest opinion I came away with (having never heard of design thinking previously) is that this author is sunk so far in his own soup of smugness that he is largely unqualified to judge whether or not Design Thinking is a worthwhile idea/technique/movement.
Examples of points the author makes:
* Popularity is bad, because Jim Jones was popular and poisoned a bunch of people with Koolaid.
* d.school is a dumb name because it's not capitalized or punctuated the way the author would prefer
* Design Thinking is dumb because it uses terms like "empathy" when we already know we should be listening to our clients, so it's dumb to use words like "empathy"
* Design Thinking is dumb because there are some designers who don't like it
* Design Thinking is dumb because the author of the blog post found a cheesey image of post-it notes on Google Image search when he googled "Design Thinking"
* Design Thinking is dumb because when the author asked his friends if they use the term "Design Thinking" - most of them don't.
* Design Thinking is dumb because it's too aspirational.
* Design Thinking is dumb because someone used the technique to design an impractical water pump.
* Design Thinking is dumb because sometimes things that are designed well sell well, and that's marketing, not design.
After very confidently condemning Design Thinking for pages and pages worth of text on the above grounds, the author admits that he has no standing to do so, because:
> "Here’s my one caveat: it could be true that the DTs are a good way to teach design or business. I wouldn’t know. I am not a designer (or business school professor)."
Oh you don't say.
The author then goes on for another (approximately) 400 paragraphs to continue to criticize Design Thinking and its use in education.
The odd bit is that I actually broadly agree with the author. There's plenty of bullshit in design and architecture and business education, and silly nebulous concepts that get treated like world-changing ideas. There are plenty of people making money selling overpriced classes based on this bullshit. There are too many buzzwords. People heavily invested in them lose sight of the bigger picture, and think that if we only followed their creative framework, we'd solve world hunger, end poverty and usher in a brave new utopia.
I recently watched an effusive hour-long documentary on Bauhaus, and couldn't confidently at the end of it define: "what is Bauahus," and it was full of people making similar claims about a the world changing power of an architectural movement that originated in early 20th century Germany.
To some degree, all creative frameworks are bullshit. And to some degree, they can all be useful.
The author seems to have spent a lot of time and effort ranting against one particular framework. I hope they're OK.
Examples of points the author makes:
* Popularity is bad, because Jim Jones was popular and poisoned a bunch of people with Koolaid.
* d.school is a dumb name because it's not capitalized or punctuated the way the author would prefer
* Design Thinking is dumb because it uses terms like "empathy" when we already know we should be listening to our clients, so it's dumb to use words like "empathy"
* Design Thinking is dumb because there are some designers who don't like it
* Design Thinking is dumb because the author of the blog post found a cheesey image of post-it notes on Google Image search when he googled "Design Thinking"
* Design Thinking is dumb because when the author asked his friends if they use the term "Design Thinking" - most of them don't.
* Design Thinking is dumb because it's too aspirational.
* Design Thinking is dumb because someone used the technique to design an impractical water pump.
* Design Thinking is dumb because sometimes things that are designed well sell well, and that's marketing, not design.
After very confidently condemning Design Thinking for pages and pages worth of text on the above grounds, the author admits that he has no standing to do so, because:
> "Here’s my one caveat: it could be true that the DTs are a good way to teach design or business. I wouldn’t know. I am not a designer (or business school professor)."
Oh you don't say.
The author then goes on for another (approximately) 400 paragraphs to continue to criticize Design Thinking and its use in education.
The odd bit is that I actually broadly agree with the author. There's plenty of bullshit in design and architecture and business education, and silly nebulous concepts that get treated like world-changing ideas. There are plenty of people making money selling overpriced classes based on this bullshit. There are too many buzzwords. People heavily invested in them lose sight of the bigger picture, and think that if we only followed their creative framework, we'd solve world hunger, end poverty and usher in a brave new utopia.
I recently watched an effusive hour-long documentary on Bauhaus, and couldn't confidently at the end of it define: "what is Bauahus," and it was full of people making similar claims about a the world changing power of an architectural movement that originated in early 20th century Germany.
To some degree, all creative frameworks are bullshit. And to some degree, they can all be useful.
The author seems to have spent a lot of time and effort ranting against one particular framework. I hope they're OK.
Design is a deep and difficult skill, but "design thinking" is not a deep set of ideas. If you listen to amazing designers and mediocre designers speak about how they approach design problems, they sound very much the same. It's like listening to professional athletes: a Major League all-star might use exactly the same words to describe how they hit a baseball as your Little League coach used when they tried to teach you how to do it.
Some designers are more poised and articulate, some are better at telling stories for an audience, but the best designers don't distinguish themselves by having different or better ideas about how to do design, any more than the best hitters have different and better ideas about how to hit a baseball. The fundamentals are well-established, encoded in a set of timeworn clichés, and it's important to be familiar with them, but the difficulty lies in picking the right cliché at the right time to focus your mind in the right direction.
Some designers are more poised and articulate, some are better at telling stories for an audience, but the best designers don't distinguish themselves by having different or better ideas about how to do design, any more than the best hitters have different and better ideas about how to hit a baseball. The fundamentals are well-established, encoded in a set of timeworn clichés, and it's important to be familiar with them, but the difficulty lies in picking the right cliché at the right time to focus your mind in the right direction.
Tbh, I had Design Thinking down as a buzzword and never really engaged with it or even knew what it really was. Then someone recently suggested using DT to revamp the UI in a place where most of us weren't quite happy about the current solution. We got some pretty good ideas after three sessions stretched out over a few days, and several of those ideas have already made it into production, with great feedback so far. So I actually had to revise my opinion - my n=1 experience was that for a narrow, well-defined problem like "Create a UI for this process", and if you count something as small getting someone senior to give up strongly held convictions as a success, then I'd say it actually worked pretty well.
My experience?
As soon as it has a Name, it has a Holy Book, and a [self-appointed] priesthood.
At that point, it (no matter what "it" is) has vaulted the Selachimorpha.
As soon as it has a Name, it has a Holy Book, and a [self-appointed] priesthood.
At that point, it (no matter what "it" is) has vaulted the Selachimorpha.
Some people evidently think that the process is too obvious to merit teaching, but to fixate on this is to miss the point. It doesn't matter that the principles are easy and intuitive to understand. It's about providing a framework that nudges people away from unhelpful human tendencies that arise in the context of a design problem. People tend to assume the type of solution they need up front without doing due diligence of establishing exactly what problem they're trying to solve. When left to their own devices, people tend to zoom in on particular ideas and do "depth-first" searches, immediately looking for reasons why an idea might not work. This is a natural instinct, and it's the wrong way to behave in a brainstorm. IDEO's original process was merely meant to push people towards a more fruitful approach. To politicize this as the solution to all of world's problems is dumb, but to throw the baby out with the bathwater is equally ignorant.