Design Thinking is the Data Science of UX: an attempt to gain influence in fields that you don't have expertise in.
Even though there might be universal design principle that can be applied in many fields, the Design Thinking people think that they can just come in and design user interfaces, etc. without really having an expertise in the particular field.
Design Thinking works for selling consulting and not much else. Nobody wants another Agile(TM) process imposed on software developers (in my particular case) that attempts to turn developers into factory line workers.
Isn't design thinking just... thinking? There may be different design methodologies you apply in different domains (e.g. civil, aeronautics, automotive, electronics, software), but once you abstract that away, what you get is thinking. I once attended a design thinking workshop many years ago, and no one there was able to adequately explain what design thinking was, except by means of jargon, metaphor, or example. My understanding of the subject has not advanced much further in the intervening years.
Yes, excatly. This is why Nigel Cross descirbe is as the designly way of thinking. Everyone has some kind of design ability, yet (good) designers show better ability to interpret situations and connect the differnet factors to better define the problem and solution. The term is underpinned by the meaning of design. Check Shape of Things: A Philosophy of Design book––I should add this to the list.
Unlike other desciplines, design is looking at the factors from epstimological and constructivism approachs where the meaning of the problem elements is clearly interpreted during the design practice.
So, feel free to call it anything, at the early 20 century, it was never been called design thinking. I usually prefer to design process/acitvity/thinking.
Design thinking is a collection of techniques that have been professional-ized into a consulting practice. Hence the mystique.
What I appreciate about a good design thinking session is:
- It externalises the insides of peoples heads in a way that allows other participants to share that knowledge. Individual tacit knowledge becomes shared general knowledge.
- Knowledge elicited during the session is presented in a way that makes it actionable
A design thinking session is doomed to failure if it isn't comprised of:
- Domain experts
- Decision makers
- A facilitator who actually knows what they're doing
Well yes, but it is thinking from the other end, usually. The reason why companies may benefit from inviting a designer is that a good designer may both aesthetically and functionally take an entirely new approach from scratch, that has the end user in mind.
This is something certain types of companies and organizationa fail at often, because their daily involvement makws them hyperfocused on certain aspects while they are blind to entire classes of solutions.
That doesn't mean designers can be sprinkeled on every project and drive an evolutionary leap, but it can be a way to explore the solution space.
I got the same reaction from that “how intelligence agencies think” YouTube video. Come now, “situational awareness”? Who needs a conspiracy to pay attention to their environment? And other mental tricks that people who must be told what to do may not come up with for themselves.
Design however is a highly praiseworthy contemplation. There are those who do it well, and those who best learn to rip off what works as faithfully as means allow.
To achieve innovation through design. it needs an organisational mindset and this shift comes with understanding that design culture is applied in strategic, tectical, and operational levels. Check my article What is this Thing Called Design Management? (https://www.designorate.com/what-is-this-thing-called-design...). This application ensures building design driven organisation.
I think you’re doing situational awareness a disservice, and I’m guessing you’ve never worked in a field where it is a trained discipline.
It is not just paying attention to your surroundings, it is actively scanning and evaluating to anticipate changes to your situation. Big difference between standing on a hill taking in the view versus keeping your head on a swivel, identify avenues of approach and egress, all while looking, listening, and smelling for anything out of place.
It is more applicable to the physical world than any software domain.
I worked as a designer (digital products) for 15 years before moving to the academia. I used the same mindset to design medical technology devices. While the fields seems to be differnet, the design activities are the same regadlress the outcome artefact. Of course, the expetise inputs varies.
Okay soldier, can you tell you are not alone in your own mind, and that American Thought Control is running an extortion racket on the United States Military?
Can you tell Bannon looted the intelligence community and exposed the envelope of every clandestine military secret by getting Trump to gather all of those commanders into one room?
You have a veyr good point here. Sadly many people try to sell design thinking as a product without digging into its underpinning philosophy at all. This is driven by many business and egineering schools that tend to turn it into a creativity-making machine. Again sadly, it doesn't work. In order to benefit from design thinking, it is important look at it from the perspective of problem framing before the solution framing. You can check the Frame Innovation by Kees Dorst, who is built on the philosophy of Thomas Khun.
Another thing is that design thinking is sold as a process where we as desigenrs never think this way. The IDEO drove this approach to make it easy to understand. This is why I teach my students that design is an arena where all the factors and stages blend. You can check the last paper in the article about the Memoranda and Artfect as it sreflects on other proceeses such as the Agile.
Can you give an analogous example for data science? I confess ignorance here, and always took the term at face value. Is the issue that "data science" tries to be agnostic about the source of the data? (I'm not claiming that that is true, just guessing)
Sure. There are many examples of data scientists attempting to use complex Machine Learning and Deep Learning models to predict machine (bearings, gears, etc.) failures from vibration data, where a simple Fourier Transform (FFT) provides a lot more insight and predictive powers about the same problem.
However, spectrum analysis is not something that data scientists learn at school, yet every mechanical/electronics engineer working in the field knows about it. So, without an expertise in a particular field, data scientists often reach for a big hammer, when more specialized tools exist and are known to the experts in the field.
Another classic example is data scientists trying to model biological processes (or answer questions about processes while ignorant of which components regulate others). Systems biology has a long history of largely clueless attempts to predict outcomes from complex processes that no one understands well enough to model usefully. The biologists know this but the data scientists do not.
huh. I'm a professional data scientist, and my masters was in signal processing. In one class the final exam required us to transcribe fourier transforms of speech into the actual words. In another the final exam required us to perform 2d FFTs in our head.
Please be careful about generalizing.
I agree that many 'data science' programs don't teach these skills, and you certainly have evidence behind your assertation.
I don’t think anyone is making the claim that data science has no merit, or data scientists are universally ignorant of anything.
Simply that some data scientists, formally trained or titled by themselves or others, have been known to apply their skills to data without having special knowledge regarding the data.
It is a bit of a cliche in some of our experiences. The consulting company that analyzes data for a decision paralyzed organization, that seeks outside guidance in lieu of getting better leadership, is something I see.
That is a real phenomenon, and despite good intentions, can have all the effectiveness of reading tea leaves.
Because there is always data to be scienced. Competently or not.
But, you are making my point for me here. Most data scientists don't get masters in signal processing. You are also acknowledging that gaining expertise in a particular field was worth pursuing.
It's much worse than that. If you dare to ask that a team speak with the problem owners - mechanics, managers, etc, you will get booted right quick.
Since the 2010's data science has gone from scientific based curiosity in solving problems to pure technicians work. There's a set of algorithms they follow, no exceptions allowed. Kaggle is a horrible anti-pattern.
i confess, i've read both of your comments on this - your analogy and a deeper explanation of the analogy - and i still have no idea what you are saying. i'm not stupid. so first, my feedback here is, it sounds like you are an educator or in an education-adjacent role, and you should focus on making more sense haha. like lay out your beefs clearly, it sounds like you have a beef with interdisciplinary work, specifically between some STEM departments and especially with humanities and STEM departments, which is subjective. you don't have to be objective about everything. you can just say, "i don't like this design thinking thing because i don't like the people involved" or whatever. but i don't know! i cannot figure out what you are saying.
it sounds like your point is: "some ways of solving problems are superior to others." i've heard this take a million times. one perspective i'll offer to you is, math is not the only way to solve problems. it's not even the best way in many cases. not everything can be solved by defining a narrow goal, and then having a dispute about the methods, and then picking some objective method and then applying it very optimally, or whatever. this is also on you, as an educator, to understand! i could give a bajillion specific examples.
but first, you have to concede: an analogy nobody understands is bad, and you have to own that, and two, it's not really clear, what exactly is your dispute with Design Thinking? it doesn't have anything to do with user interfaces... so why the hell are you talking about it? why "Design Thinking people"? What is your beef here?
Me too don't understand the analogy between design thinking and data science. Both are too different. But even if I am a designer and teach design, I don't think there superiority here. it is how to benefit from each approach to achieve in intended goal.
As many other people on HN, I am an advocate for software engineers and I think it is important that software engineers themselves develop expertise and become owners in their particular fields of application, their processes, etc.
Attempts to undermine their role and turn developers into simple cogs in the machine rub me the wrong way.
I perceive (you might disagree) that Design Thinking, Agile, Scrum, and similar things as attempt for designers, PMs, etc. to insert themselves into the process, not as equal partners, but as people with elevated privileges over software developers.
I don't necessarily disagree with the idea and ideals of Design Thinking. I disagree with the practitioners and their perception of themselves as something special over software developer.
I also think that my original analogy at the top is perfectly understood by a lot of people here as much as I understand the type of people on HN.
having a specific negative experience can be interesting, why don't you talk about that instead? generally, having been both the "design thinker" and the thinkee, in both the formal big corporate setting you are lamenting and in a less formal research environment, my and my colleagues experiences have been unequivocally positive. nobody is thinking about things in terms of, "perception of themselves as something special over software developer." that may be a problem unrelated to "design thinking," i can see how any creative thinking exercise can test people's interpersonal relationships differently than say, telling Claude what to do.
it is normal to see people advocate their favourite tool or process. However, I always tell my design students to be critical and strategic when choosing their tools.
I believe he is trying to articulate the failings of e.g., JFK's Whiz Kids who were experts of statistical analysis and tried to use that knowledge to domains they knew little about. In a nutshell, these experts tend to deep dive on parts of the problem where data was available and ignore the parts of the problem that is not quantified. Which is usually a huge mistake.
Design thinking, at least in its formal STS approach, is essentially applied sociology; it's about using various toolkits to build a sufficient understanding of a domain from the "inside out" (using desk and field research) so that you can design valuable experiences that build upon the expertise of those actually inside the domain. In this, it's a bridge between UX/product and users/stakeholders (technical stakeholders are admittedly too often an afterthought, but that's a process problem). If anyone comes in and attempts to blindly shove workshops at you without first conducting in-depth research, interviews, and field studies in your domain, then they are (without resorting to the One True Scotsman) not doing design thinking, they're doing cargo-cult brainstorming. (It's also a process orthogonal to agile development, since by definition it's a linear process that needs to be conducted prior to developing the actual product features and requirements.)
The books and papers the OP cites are solid (Rittel and Webber, Buchanan, etc., though TRIZ, I think, is rather oversold), but in my experience the problem with most design thinking practitioners is that they aren't qualified sociologists and ethnographers, so a lot of design thinking is basically a reinvention of the last century of sociological middle-range theory and ethnographic principles, without being strongly informed by either, likely due to the field's foundation in early software requirements studies.
These are good points. Although I discussed the TRIZ in couple of my articles. I need to revisit my thoughts as it is over-egineered Russian tool that eliminate all the benefits of subjective constructivism design mindset. It is simply say, everything can be solved using one fo those 40 ways.
That's a great answer that offers concrete insight into what design thinkers are trying to achieve. And it seems like they have a chance to succeed if they also employ iterative experimental methods to learn whether their mental model of user experience is incorrect or incomplete. Do they?
Traditionally you use a lot of paper and experiential prototypes to iterate on, which doesn't cover everything but helps refine assumptions (I sometimes like starting with mocking downstream output like reports and report data, which is a quick way to test specific assumptions about the client's operations and strategic goals, which then can affect the detailed project). When I can, I also try to iterate using scenario-based wargaming, especially for complex processes with a lot of handoffs and edge cases; it lets us "chaos monkey" situations and stress-test our assumptions.
More than once early iterations have led me to call off a project and tell the client that they'd be wasting their money with us; these were problems that either could be solved more effectively internally (with process, education, or cultural changes), weren't going to be effectively addressed by the proposed project, or, quite often, because what they wanted was not what they actually needed.
Increasingly, AI technical/functional prototyping's making it into the early design process where traditionally we'd be doing clickable prototypes, letting us get cheap working prototypes in place for users to test drive and provide feedback on. I like to iterate aggressively on the data schema up front, so this fits in well with my bias towards getting the database and query models largely created during the design effort based on domain research and collaboration.
Not sure what your definition of 'Design Thinking' is.
Design Thinking isn't about people thinking "that they can just come in and design user interfaces, etc. without really having an expertise in the particular field."
It's a problem solving approach using UCD methods amongst others and working with experts in the field to come up with solutions and ideas to a given problem space.
Key thing is you work with the people who are experts in the field, for example working with medical experts to design a new health related application etc.
It is the practice that matters, which is the "designers" trying to elevate their position to something more special by inserting their special rules into the design process, often at the expense of other people involved, including the experts.
"Working with the experts" always turns into weird formalized brainstorming sessions or other rituals, where the designer defines the process and the rules, and others' role is just to be little players in the game, but not the referee.
This is nothing new. We have seen the same thing with PMs and "scrum masters" inserting themselves into the software development process with shit like Agile, Scrum, etc.
If design thinking is just a problem solving approach, experts and practitioners in the field are perfectly capable of doing that. We don't need the shamans of Design Thinking to guide the process.
Those experts and stakeholders have a day job (i.e. don't have time to do this) and are usually in silos. They are not experts in workshop facilitation, user testing, usability, rapid prototyping to iterate on ideas and to think more broadly.
It helps to avoid parts of the innovator's dilemma and to break out of siloed thinking, i.e. involve stakeholders from other functions of the org.
Not sure what you've been sold, but there are no special rules or rigid methods.
But you're right, unfortunately there are consultants who use this term to sell you a new wunder method to solve all your product problems, but they are not really design practitioners.
Same way as people took the Agile Manifesto and bastardized it to create SAFE.
> Not sure what you've been sold, but there are no special rules or rigid methods.
I am not intentionally trying to be argumentative, but
- I have seen UX designers refer to a team of developers as "my developers" and I take it negatively.
- I have been into countless design sessions where the UX designers conducted a weird formalized session with cards, sorting, voting with colored stickers, and assigning equal votes to newly hired participants and senior domain experts. They were beyond stupid.
Sounds like your ego was hurt by a process that's designed to expose ideas from a group on a level playing field. The process was working as intended. If it upset you, it might be worth reflecting on what you can do to be more flexible and open minded, which is hard to do as we gain more experience in life.
Uhh… What does Design Thinking have to do with UX? Sure, it could be used to come up with novel ideas for user interfaces but DT (nowadays) is an approach that's several orders of magnitude more general.
Sure. Let me then call it this way: "Design Thinking is the Data Science of design: an attempt to gain influence in fields that you don't have expertise in."
I’d retort that software developers aren’t domain experts either. At the end of the day you either luck out if domain experts and actual users are involved in eliminating toil (in the sense that Google defines that) and optimizing the user experience, while reducing friction in applications and providing insights into data.
Having read the other comments in reply to this one (and your subsequent replies) - I believe you might be falling into a "No True Scotsman" situation.
First of - I don't know what circles you've been around, but I've not been in work collectives where either designers, UX-ers or data scientists try to insert themselves to do things instead of software engineers. If anything, in any collective I worked in, if a software engineer was to say a peep everyone would retreat like there's no tomorrow and thank god that they don't have to deal with it and the software engineer will.
Secondly - I think you are mistaking a structuring and outlining of a process with that being a mandate or an order to follow the process. When I work with software engineers, I expect them to be agile - not to follow an agile process, but to achieve the objectives of the agile manifesto - namely, to iterate ruthlessly, keep an eye on usage signals and lead with MVP's rather than over-design. Good software engineers do that, bad software engineers don't. Ultimately, I don't even judge software engineers by that - I judge them by the ability to produce results.
I think the implication of your thinking is that this is all nonsense because software engineers innately solve data science problems and design thinking problems when appropriate with appropriate methods - to which I'd reply - there's a shocking amount of software engineers who can't do anything with data and are useless in fitting a linear regression to predict something, let alone doing a Fourier transform - to which, presumably, your response would be "No true software engineer is like that". That's great, but it's not true in the real world. Same with design thinking - there's software engineers who just can't solve problems from first principles (but can, say, create a fail-proof CRUD app to automate a business process).
The real world is messy and full of people who can't structure their thoughts, or can't structure them in all domains at the least - and things like design thinking - or generalists who can be thrown at any data problem and produce something (i.e. data scientists) - are useful. They're not the best solution always, sure, and if they start being protective of territory - it's a problem - but in a normal collective that doesn't happen.
Basically - your objection can be boiled down to "generalists are shit, because they impose process on everyone, including people who understand the domain better" - which tells me more about the collectives you've worked in than the nature of those jobs. In every collective I've worked in, generalists are what you throw at an ambiguous problem to produce some results before you get domain specialists in.
Even though there might be universal design principle that can be applied in many fields, the Design Thinking people think that they can just come in and design user interfaces, etc. without really having an expertise in the particular field.
Design Thinking works for selling consulting and not much else. Nobody wants another Agile(TM) process imposed on software developers (in my particular case) that attempts to turn developers into factory line workers.