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.
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)
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.
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.
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.
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.
I'm a dev and recently picked up "The Design of Everyday Things" as an attempt to become more design-oriented. Everyone raves about this being like the bible of design.
So far I'm about 80 pages in and have found it extremely academic and not very practical, sometimes deriving conclusions that are so far from reality that they are a bit concerning, like how a strong password does not matter because once they inevitably leak they can always be cracked via rainbow tables (the author doesn't use this exact term). As we know the exact point of a strong password is that it will not be in a rainbow table.
Of course the original version is pretty old but I picked up the latest revised version. Still some interesting insights and I haven't given up on the book quite yet but it's been a ton of theory and a lot of terminology so far.
I've used The Design of Everyday Things in many classes I teach. I would agree that it's not practical, but that's not its goal. Instead, it gives you frameworks for thinking about things as well as vocabulary for talking about those things.
Off the top of my head, some of the key ideas include:
* Affordances, that objects should have (often visual) cues that give hints as to how to use things
* Mental models, that every design has three different models, namely system implementation, design model, and user model, and that the design model and user model should try to match each other
* Gulf of Evaluation (the gap between the current system state and people's understanding of it) and Gulf of Execution (the gap between what people want the system to do and how to use the system to do it)
* Kinds of Errors and how to design to prevent and recover from them, e.g. slips (chose the right action but accidentally did the wrong thing, e.g. fat finger) vs mistakes (chose the wrong action to do)
What's particularly useful about Norman's book is that these key ideas apply for all kinds of user interfaces, from command-line to GUI to voice-only to AR/VR to AI chatbot. I'd encourage you to think about this book in this kind of framing, that it gives you general frameworks for reasoning and talking about UX problems rather than specific practical solutions.
I was gifted this book my a CIO when in college. She had a dozen copies in her office to hand out to various people.
It took me a few tries to get up the will to actually read it. It was years ago, so I don’t remember a lot of details. My main take away was to make controls logical for the thing being controlled. “Norman doors” are the big one, but I often think about it while I’m in my car trying to do something on a touch screen, when all I want is a knob, button, or switch.
In the modern era of web design I think it would point to these websites (like most of Apple’s product pages), that make users scroll through indulgent animations, just to get to the content. It may be cool the first time, but is very annoying for repeat visits, and it feels like it breaks my scrolling expectations. Not to mention all the horizontal scrolling thrown in there, which becomes a headache for those without the hardware to do it easily, and confusing to change scroll direction all the time.
It tells lots of things but you can takeaway a few things.
One of the key takeaway example for me was that if you make an approachable flat surface, people will put things on it. This is a small example but tells a lot about design of common things.
Another was that I shouldn't be blaming myself for failing to use an everyday thing, I should be blaming its design.
After reading the book I now keep seeing so many design flaws in so many things around. It also made me appreciate good design similarly. I probably think a bit more about users of code etc now, doesn't mean I write better, but it has changed perspective quite a bit.
"Bible of design" might be a bit excessive. It's a good design 101 book. Definitely longer than it should be, and kind of fumbles the explanation of "affordances", which the author had to clarify later. It's representative of "design thinking" as a historically well-situated concept in design, but that's not necessarily a good thing in itself.
It really depends what you're looking for. If you want something deeper, more abstract, I would recommend going straight to something like Notes on the Synthesis of Form by Christopher Alexander, which I think typically appeals to the more abstraction-oriented part of the mind of engineers. If you want to get more actionable, practical day to day recipes, Refactoring UI as suggested somewhere else in the thread is a decent suggestion.
For me the real capability unlock from The Design of Everyday Things was that it made me start noticing and thinking deliberately about design decisions, which pushed me to begin evaluating everything through that lens. In general it comes down to looking at something and asking "what is good / effective and what is bad / annoying about this". If you keep doing that enough you develop your own taste and a greater appreciation of the world. Donald Norman isn't handing you a map, he's teaching you how to build your own.
For Devs/Engineers and even many designers, things some of us tend to take for granted were amazing to them. So, my first recommendation is to read Refactoring UI end-to-end and keep a copy handy at your desk.
Still more on the psychological and even philosophical side than being about how to do design, I really enjoyed Jenny Davis, "How artifacts afford" (2020). It takes consideration of 'affordance' to a new level. If that rings bells, you'll love it.
Like you say, it's old and I'm nostalgic for the time that I associate reading it with. I think that explains some of the love folks (or at least me) have for it.
I've never revisited the book and thanks to your comment I might not ever now ha
That point about rainbow tables seems to ignore how modern hashing works. We use salted hashes (bcrypt, Argon2) specifically to render rainbow tables ineffective. Since the salt is unique per user, pre-computing tables isn't feasible, so a strong password absolutely still matters against brute-forcing the specific hash.
my take on this book is that 1) it contains a lot of foundational knowledge/wisdom about design as interpreted broadly that is very useful across contexts, and 2) it is itself, ironically, an example of poor design. Not in the visual sense, but in that it's structure and writing do a pretty bad job actually conveying that knowledge to the reader and being navigable.
I tried reading it and hated it, then I came back knowing bits and pieces of its contents from elsewhere and was like "yup, this is the only place I've seen all of this together".
i also picked up the book with high hopes and dropped off about where you are at. useful concepts like affordances and signifiers but felt like a lot of filler.
I took a Computer Science class decades ago that used that book as the core of the class material. I don't remember a single thing about that class now except that I hate that book and the professor bragging about designing cockpit instruments or some such. I learned more out of a cognitive psych class.
My two cents as a 20 year product manager with +10 enterprise applications under my belt (and having read several of these):
# "Don't make me think" is a seminal work on design thinking for online services. I've yet to come across a book with as much relevance and substance even though
it was written for the dot com era.
# "Positioning" by Al Reis is a book I wish I read 15 years ago when I started my company... your product's strategic positioning will greatly inform and shape design decisions (typography, colors, tones, copy, etc)
# "Ogilvy on Advertising" - written by the legend himself, once you read this book, it will change the way you see all ads in any medium
I have similar experience and agree with your book recommendations. Depending on your vertical I would add the Toyota Way later to understand factory design and efficiency. It’s interesting to read back to back.
Design thinking is a human-centered, iterative approach to creative problem-
solving, focusing on deeply understanding users' needs to develop innovative
solutions through phases like Empathize, Define, Ideate, Prototype, and Test.
Apparently. It's not immediately clear how it's different from your good old "regular" design.
Yes I agree, and the replies don't really make it any more clear.
The biggest differentiator of design thinking is really addressing the XY problem. In 95% of cases clients will come to you to design their solution. Ie they already think they have a solution to their problem and now they want it to look good.
Design thinking is basically more like root cause analysis, or the 5 why's.. and an emphasis on taking to end users (the people with the problem) without having a solution.
Once you understand the problem more fundamentally is only when you start cooking up with a solution.
And the result of that process might not even be a traditional design, but perhaps just a tweak to something, like moving your onboarding to later in the ca process..
In practice however.. 95% of designers who say they practice design thinking disregard this, and just want to design wherever the client asks for
I was confused when I first heard about 'Design Thinking' as a thing because as a designer it sounded just like the standard design process that I already knew inside-out and backwards.
After a while I realised a few things about it:
1. Yes it is the standard design process, but with a fancy title.
2. It's been given a fancy title as that helps sell books and launch consulting careers
3. It's actually useful as it gets clients and stakeholders involved in the design process. They start thinking about the problems they want to solve and who they want to solve them for - and more importantly have a personal stake in the outcomes. Moves the conversation from 'I want this' to 'here's the problem'.
I've run design thinking workshops with everyone from primary school children to CEOs and they've all loved it.
I think that's the point. The underpinning exhortation is to "think about design" where the outcome is something that successfully addresses users needs, is feasible to create, and commercially viable.
"Design Thinking" as a brand has codified that in several ways - not all successful. But the underlying principle is sound: there are plenty of examples of products/services that failed to address one or more of the 3 dimensions.
I found this quote from the linked article [0] more helpful:
> Design thinking can be described as a discipline that uses the designer’s sensibility and methods to match people’s needs with what is technologically feasible and what a viable business strategy can convert into customer value and market opportunity.
it is not - just a way to position design and untie it from the visual output that is also called design. Design thinking will not make you a logo (but a logo designer could pretty much do design thinking...)
I know it is more niche to the online/websites POV, but “Don’t Make Me Think” is a book that needs to be somewhere in the lines of “The Design of Everyday Things.” Of course, I re-read the latter as reminders and catch-up readings.
This isn't really a tasteful collection. It is just a bunch of popular books, all of which that I have read being about minimalism.
If that's what you want you can just use Apple as a case study because that's what you end up getting if you want "modern" and minimal. Even just drop the CSS file from source into an LLM and go through how it is implemented.
Tom Kelley and David Kelley, founders of Stanford's Design School and IDEO (the industrial design firm that made things like Apple's first mouse and the standup toothpaste tube) have a great book, Creative Confidence.
I’m not a game designer, but 15 years after initially reading it, Jesse Schell’s “The Art of Game Design: A Book of Lenses” really sticks with me in any product design context. Organizing your thoughts around the lenses presented in this book makes for productive discussion, and can turn subjective points (an example might be how frictionless or not a UI element might be) into more objective points. I suggest checking it out. The author posted a deck of the lenses here: https://deck.artofgamedesign.com
Design Thinking is a subset of Systems Thinking (this is the polite interpretation).
Design Thinking does with its sole existence what Systems Thinking tried to avoid: Another category to put stuff into, divide and conquer. It is an over-simplified version of the original theories.
Better: Jump directly to Systems Thinking, Cybernetics and Systems Theory (and if measurements are more your thing, even try System Dynamics).
I can only recommend that anyone interested in this topic take a look at the work of one of the masters of Systems Thinking, Russel Ackoff:
This talk from 1991 is several dozen books heavily condensed into one hour.
(Russell Ackoff is considered one of the founders of Operations Research and ironically came to be regarded an apostate as he tried to reform the field he co-founded. He subsequently became a prominent figure of Systems Thinking)
Design Thinking (and more broadly, human-centered design) is a pragmatic framework for doing product design in an effective and productive manner. Systems Thinking is a massively more general superset. I'm not really sure how you'd operationalize that on a design project, except by following first principles, which would essentially get you to DT / HCD.
I've been very interested in cybernetics and systems thinking lately — would you be able to recommend some good books? I'm not afraid of difficult academic or philosophical reading, but I'm looking for stuff that's large in scope, applies to general fields, etc.
I like how the author correctly shown the cover image for the "The Sciences of the Artificial", with plural 's' in 'sciences', but then in the paragraph praising it gleefully ignored it.
Thanks, I will fix this one. And yes, I am an old guy who doesn’t use AI in writing my articles. I tried once, and I felt like I was a slave to the machine ;) So, I am proud of my human mistakes in the age of AI perfection.
Design thinking is a scam. I once had to took part in a design thinking class (my company wanted that). The consultant clearly were just waiting to see what kind of ideas we would come up with for some product. If an interesting idea came up in their classes they would later try to monetize it. So basically you pay them so they get your product ideas for free.
If anyone's interested in how environment shapes behavior: I wrote "Leave the Door Open." It's about designing spaces that reduce isolation and relax the nervous system.
Based on research like the Rat Park experiments showing environment beats willpower. Practical room-by-room changes.
The Substack for Open Enough Design is here: https://OEDmethod.substack.com and you can find a link to the book there too.
It seems that I have learned to distrust websites that show ads.
I don't think there's nothing wrong with wanting to get paid via ads. But I don't see why a list of "design thinking" books should be some piece of info that you should be paid for.
What most people fail to realise is something quite simple about “design” - it’s the discipline of bridging human behaviour and “things” (be that objects or software).
Don Norman’s book covers a lot on human behaviour, which is the correct lens through which to view “design”.
bsoles|1 month ago
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.
hliyan|1 month ago
rrm1977|27 days ago
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.
ccppurcell|1 month ago
HillRat|1 month ago
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.
jjtheblunt|1 month ago
SOC2 is like this: a collection of security ideas thought up by a group of CPAs, so they can partake in software engineering. It's beyond bizarre.
tengbretson|1 month ago
- Gandhi
uxcolumbo|1 month ago
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.
b00ty4breakfast|1 month ago
codethief|1 month ago
kwanbix|1 month ago
Mentlo|1 month ago
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.
yakkomajuri|1 month ago
So far I'm about 80 pages in and have found it extremely academic and not very practical, sometimes deriving conclusions that are so far from reality that they are a bit concerning, like how a strong password does not matter because once they inevitably leak they can always be cracked via rainbow tables (the author doesn't use this exact term). As we know the exact point of a strong password is that it will not be in a rainbow table.
Of course the original version is pretty old but I picked up the latest revised version. Still some interesting insights and I haven't given up on the book quite yet but it's been a ton of theory and a lot of terminology so far.
jasonhong|1 month ago
Off the top of my head, some of the key ideas include:
* Affordances, that objects should have (often visual) cues that give hints as to how to use things * Mental models, that every design has three different models, namely system implementation, design model, and user model, and that the design model and user model should try to match each other * Gulf of Evaluation (the gap between the current system state and people's understanding of it) and Gulf of Execution (the gap between what people want the system to do and how to use the system to do it) * Kinds of Errors and how to design to prevent and recover from them, e.g. slips (chose the right action but accidentally did the wrong thing, e.g. fat finger) vs mistakes (chose the wrong action to do)
What's particularly useful about Norman's book is that these key ideas apply for all kinds of user interfaces, from command-line to GUI to voice-only to AR/VR to AI chatbot. I'd encourage you to think about this book in this kind of framing, that it gives you general frameworks for reasoning and talking about UX problems rather than specific practical solutions.
al_borland|1 month ago
It took me a few tries to get up the will to actually read it. It was years ago, so I don’t remember a lot of details. My main take away was to make controls logical for the thing being controlled. “Norman doors” are the big one, but I often think about it while I’m in my car trying to do something on a touch screen, when all I want is a knob, button, or switch.
In the modern era of web design I think it would point to these websites (like most of Apple’s product pages), that make users scroll through indulgent animations, just to get to the content. It may be cool the first time, but is very annoying for repeat visits, and it feels like it breaks my scrolling expectations. Not to mention all the horizontal scrolling thrown in there, which becomes a headache for those without the hardware to do it easily, and confusing to change scroll direction all the time.
smusamashah|1 month ago
One of the key takeaway example for me was that if you make an approachable flat surface, people will put things on it. This is a small example but tells a lot about design of common things.
Another was that I shouldn't be blaming myself for failing to use an everyday thing, I should be blaming its design.
After reading the book I now keep seeing so many design flaws in so many things around. It also made me appreciate good design similarly. I probably think a bit more about users of code etc now, doesn't mean I write better, but it has changed perspective quite a bit.
davidivadavid|1 month ago
It really depends what you're looking for. If you want something deeper, more abstract, I would recommend going straight to something like Notes on the Synthesis of Form by Christopher Alexander, which I think typically appeals to the more abstraction-oriented part of the mind of engineers. If you want to get more actionable, practical day to day recipes, Refactoring UI as suggested somewhere else in the thread is a decent suggestion.
jbs789|1 month ago
And if you’re designing the door, it is your responsibility to think deeply and observe behaviour, to design an intuitive interface.
I do agree that it’s rather academic, but I did leave with that one takeaway.
TheAceOfHearts|1 month ago
Brajeshwar|1 month ago
https://www.refactoringui.com
PS. Refactoring UI is from the guys who created TailwindCSS.
asplake|1 month ago
elicash|1 month ago
I've never revisited the book and thanks to your comment I might not ever now ha
storystarling|1 month ago
nemetroid|1 month ago
bschne|1 month ago
I tried reading it and hated it, then I came back knowing bits and pieces of its contents from elsewhere and was like "yup, this is the only place I've seen all of this together".
kennyk37|1 month ago
philote|1 month ago
lefstathiou|1 month ago
# "Don't make me think" is a seminal work on design thinking for online services. I've yet to come across a book with as much relevance and substance even though it was written for the dot com era.
# "Positioning" by Al Reis is a book I wish I read 15 years ago when I started my company... your product's strategic positioning will greatly inform and shape design decisions (typography, colors, tones, copy, etc)
# "Ogilvy on Advertising" - written by the legend himself, once you read this book, it will change the way you see all ads in any medium
stevenhubertron|1 month ago
huhtenberg|1 month ago
arnorhs|1 month ago
The biggest differentiator of design thinking is really addressing the XY problem. In 95% of cases clients will come to you to design their solution. Ie they already think they have a solution to their problem and now they want it to look good.
Design thinking is basically more like root cause analysis, or the 5 why's.. and an emphasis on taking to end users (the people with the problem) without having a solution.
Once you understand the problem more fundamentally is only when you start cooking up with a solution.
And the result of that process might not even be a traditional design, but perhaps just a tweak to something, like moving your onboarding to later in the ca process..
In practice however.. 95% of designers who say they practice design thinking disregard this, and just want to design wherever the client asks for
mattkevan|1 month ago
After a while I realised a few things about it:
1. Yes it is the standard design process, but with a fancy title.
2. It's been given a fancy title as that helps sell books and launch consulting careers
3. It's actually useful as it gets clients and stakeholders involved in the design process. They start thinking about the problems they want to solve and who they want to solve them for - and more importantly have a personal stake in the outcomes. Moves the conversation from 'I want this' to 'here's the problem'.
I've run design thinking workshops with everyone from primary school children to CEOs and they've all loved it.
spinningslate|1 month ago
"Design Thinking" as a brand has codified that in several ways - not all successful. But the underlying principle is sound: there are plenty of examples of products/services that failed to address one or more of the 3 dimensions.
I found this quote from the linked article [0] more helpful:
> Design thinking can be described as a discipline that uses the designer’s sensibility and methods to match people’s needs with what is technologically feasible and what a viable business strategy can convert into customer value and market opportunity.
[0]: https://www.designorate.com/design-thinking-guide-what-why-h...
yashasolutions|1 month ago
epolanski|1 month ago
Brajeshwar|1 month ago
https://en.wikipedia.org/wiki/Don't_Make_Me_Think
LocalPCGuy|1 month ago
JKCalhoun|1 month ago
kaizenb|1 month ago
I've been curating (mostly design) books on a digital library: https://links.1984.design/books
password54321|1 month ago
If that's what you want you can just use Apple as a case study because that's what you end up getting if you want "modern" and minimal. Even just drop the CSS file from source into an LLM and go through how it is implemented.
barrenko|1 month ago
jgeurts|1 month ago
janeway|1 month ago
smurda|1 month ago
Here's their website for the book, along with some tools and useful instructional videos https://www.creativeconfidence.com/tools/
chrisweekly|1 month ago
listenfaster|1 month ago
gond|1 month ago
Design Thinking is a subset of Systems Thinking (this is the polite interpretation). Design Thinking does with its sole existence what Systems Thinking tried to avoid: Another category to put stuff into, divide and conquer. It is an over-simplified version of the original theories.
Better: Jump directly to Systems Thinking, Cybernetics and Systems Theory (and if measurements are more your thing, even try System Dynamics).
I can only recommend that anyone interested in this topic take a look at the work of one of the masters of Systems Thinking, Russel Ackoff:
https://m.youtube.com/watch?v=9p6vrULecFI
This talk from 1991 is several dozen books heavily condensed into one hour.
(Russell Ackoff is considered one of the founders of Operations Research and ironically came to be regarded an apostate as he tried to reform the field he co-founded. He subsequently became a prominent figure of Systems Thinking)
My 2c. I'll show myself out.
turnsout|1 month ago
baxtr|1 month ago
I have to admit that it was very hard to me to follow what they were saying.
Maybe I’m dumb, maybe the person didn’t explain it well, or, maybe system thinking is really complex and thus hard to convey and use.
Design thinking on the other hand is easy to understand and apply.
logicprog|1 month ago
eleventyseven|1 month ago
smikhanov|1 month ago
Probably means this article wasn't written by AI!
rrm1977|27 days ago
carlsborg|1 month ago
rrm1977|27 days ago
amai|1 month ago
rrm1977|27 days ago
truenfel|1 month ago
Based on research like the Rat Park experiments showing environment beats willpower. Practical room-by-room changes.
The Substack for Open Enough Design is here: https://OEDmethod.substack.com and you can find a link to the book there too.
unknown|1 month ago
[deleted]
TZubiri|1 month ago
I don't think there's nothing wrong with wanting to get paid via ads. But I don't see why a list of "design thinking" books should be some piece of info that you should be paid for.
At least there's an author to the article I guess
andai|1 month ago
It's a very light, approachable book, dealing with surprisingly universal principles. Also it has very nice pictures.
Most of it also applies to game dev, and to the design of experiences.
what_was_it|1 month ago
ines_leal|1 month ago
unknown|1 month ago
[deleted]
7tythr33|1 month ago
Don Norman’s book covers a lot on human behaviour, which is the correct lens through which to view “design”.
unknown|1 month ago
[deleted]
any1|1 month ago
bradbeattie|1 month ago
seemaze|1 month ago
[deleted]
gizzlon|1 month ago
GTFO with this hyperbolic language
wetpaws|1 month ago
[deleted]