Where the design community meets.
I think Natasha Jen is mostly correct.
Just two articles down from this post on DesignerNews is this article: "Code Complexity is a Design Problem" (link: https://builttoadapt.io/code-complexity-is-a-design-problem-e53e4229b5de ). There are some potentially worrisome ideas tucked away in here:
Quote 1: "Think of it this way: The best design in the world, when in the form of an image file, sketch, or prototype, can be admired for its beauty, clever interactions, and innovation, but it can’t deliver value to the user."
Quote #1 subversively says design thought means nothing unless it's in code. This is design as seen through the lense of an engineering mind. Do they realize design solves problems that have 0 code requirements (furniture making, graphic design, architecture, etc.) Designers test and iterate with users. Designers can facilitate (and should) with the team, but ultimately the design solution to a problem needs an owner. This is the perspective a designer provides to an organization... a focus on user research and humanized solutions. Design thinking often obfuscates this through an immense amount of post-it note exercises. Do these exercises to clarify and understand—but at the end of the day someone is going to have to make a decision based off of what the user's behaviour is telling you. Or what you THINK It's telling you.
Quote 2: "If two ideas are equally impactful to the user, but engineering expresses real concerns about one, you should be able to it kill on the basis of being high-cost, even if engineering just has a gut feeling"
Quote #2 handwaves away a good idea because developers are concerned with the time it takes to make it. Except a more likely scenario is Option B, the expensive one, is simply better than Option A. Seldom are solutions "equal". Descoping good ideas is VERY common in agile processes. This is another key reason design needs to be separate (but integrated) with engineering—the user outcome should matter as much as the core technology. We had git for YEARS before github nailed the experience everyone wanted out of code management. That was a good design that was hard to crack—complexity that simplified code management for devs.
The collaborative aspects of design thinking isn't a risk — it is the diminished user advocacy in the vision, metrics and process by people who have a lot of other constraints on their shoulders. Engineers shouldn't be descoping good solutions because of complexity, and design needs to be championed as a way of providing customer value. Great products often outright own complexity and sacrifice this hardship for a design that solves the problem better for the human on the other side. You need a person to humanize and advocate for users, and it's a full-time job to facilitate: the designer.
It's not clear to me how that article confirms the idea that "design thinking is bulls***." It seems to lump design thinking and the broader definition of design together. Your argument seems to be that the article is bad, so are you in fact asserting that its unorthodox definition of design/design thinking is good?
I'm agreeing with Natasha Jen that design thinking is a risk, but I'm disagreeing that the risk is inherent with design thinking itself.
Design thinking can be a great tool that a designer can use to facilitate a strong design culture with their team. Democratizing design DOES risk the process being used negatively by people who don't know, or care to know, about the user's experience. Ensure your design process is owned by a designer and NOT everyone. That expectation should be set. Because if everyone owns something then no one does, and design as a voice may end up being diminished in your organization. (the article I pointed out shows how common it is for engineering to do this and not realize it, so the risk is already here)
Where the design community meets.
Designer News is a large, global community of people working or interested in design and technology.