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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
DOET (neé Psychology of Everyday Things) deeply influenced me. Articulated things I had observed, experienced. Expanded my thinking.
I was using, teaching, and developing for AutoCAD at the time. Knew nothing about UI beyond my intuition. Just perplexed by how difficult it was for most to use.
Reflecting back, Norman's treatment of mental models and kinds of errors were the most impactful, evergreen design challenges I faced.
I read the Design of Everyday Things and most of it was painfully obvious examples and was overly philosophical.
Design is solving problems so they're intuitive for the user. Obviously a door with a handle shouldn't be a push door, I don't really think you need to write a book about it. And the types of people creating bad design are generally constrained by cost, time, or practicality, not necessarily by education.
> Obviously a door with a handle shouldn't be a push door, I don't really think you need to write a book about it.
It’s common to illustrate principles with examples that appear obvious, i.e. that everyone agrees on, so that after having it conceptualized as a principle, you’ll apply it in less obvious circumstances. Many things are obvious only in hindsight.
> And the types of people creating bad design are generally constrained by cost, time, or practicality, not necessarily by education.
That’s not true, because a lot of flawed design is being promoted and defended in public as the thing to do.
> Obviously a door with a handle shouldn't be a push door, I don't really think you need to write a book about it.
And yet we've all encountered push doors with handles many times.
> And the types of people creating bad design are generally constrained by cost, time, or practicality, not necessarily by education.
Good design is far cheaper and easier than bad design in the long run. Being able to articulate the benefit of good design such that stakeholders provide the resources for good design is perhaps one of the most important reasons to have such an education.
uh, the fact that this is written down and carefully put in frameworks is a good thing. Otherwise you can say any academic book is intuitive. the fact that it sounds obvious means they're getting the message across. because lord knows it was needed and there's plenty of failed products and ideas because of shitty design.
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.
I love this. Thank you for introducing me to "Norman Doors". I hadn't realized someone else had described this in such detail. I have been complaining about this years.
Ok this will be a tangent, but I also take this one step farther and also talk about "documentation". Just for the record, I don't think documentation is all good or all bad, but it definitely can be used incorrectly and in excess. And Norman Doors and a great way to get this point across.
When someone creates or installs a Norman Door by accident or out of ignorance and then realizes there is a problem, they often think "I know, I will document it!" and they add little placards to the door that says "Push/Pull" or some such. They see that this helps with a small subset of users and thinks "there, I fixed the problem, people just need to read the documentation and now it is their problem if they don't". But if you watch users of the door, a large portion will still use the door incorrectly because... people don't read documentation. If they don't read documentation, is it the users fault the door was designed incorrectly or was it the designers problem?
I use this as an example for my developers on thinking before documenting troublesome code or a confusing interface to first ask "can I design this so it is less confusing?" and if so, that would usually be preferable to adding documentation "to solve the problem". Well designed code (or doors) with no documentation always beats poor designs with documentation.
Which reminds me of another "there, problem solved!" pet peeve of mine. I call it the Default Trap.
In many cases (Norman Doors are an example), there are two or more equally valid ways to do something. By "equally valid", I mean there is no clear standard for whether it should operate one way or the other, and if you ask 100 people which way it should work (which no one ever does), you get something approaching 50%.
So the product manager or perhaps developer simply says "make it a setting", and everyone agrees and declares the problem solved.
But the problem is, you have to choose a default. And 90% of the time, no one is going to change that default, or even discover how to. So you have to be very correct about assuming which value is the best default - and at that point, it probably doesn't matter that you make it an option.
The alternative I've seen to this is to ask the user which way they want it during the setup process. Light vs Dark mode is an example of this. The net result of this user choice is a longer, more complex, and burdensome onboarding process that is rife with decision fatigue. Once the user has chosen, if they don't like their choice, they may not know how to change it, since that initial action was outside of any standard interface.
The other issue with settings for everything is that the settings become bloated. In OS X, and to some extent iOS, I knew where all the settings were for the most part. Browsing them all to see what was available was a consumable thing, and I could largely remember where to go without much trouble. As macOS and iOS have added more settings to try and please everyone, and now redesigned the Settings apps... I've given up. I have no idea where most things are, what is in there, and have to search for everything and hope I use the right words.
There is an old video of Steve Jobs[0] talking about how every product is a series of decisions and trade offs. People pay companies to make all these decisions, and ideally, there is a company that makes decisions to similar enough sensibilities as yourself so that you can buy a product and use it without much fuss. It seems more and more that these decisions are all being pushed to the consumer, which in some ways makes a worse product. If I wanted infinite chose at the expense of complexity, I'd be running Gentoo or Arch. People choose macOS because it's supposed to be easy.
There's a funny example of even the "documentation" going wrong. At a local mall, there is a set of doors and they have put the word "PULL" (vertically like:
P
U
L
L
) on the window of the door, so from the wrong/opposite side, you still see the word "PULL" when you should PUSH (even if most of the letters are backward) so you still are tempted to take the wrong action when you see it. (I tried to explain the ridiculousness of it to the person I was with, but I don't think they cared.)
I've long suspected that I have a particular form of...dyslexia?, because I suffer from that Pull/Push thing, but also freeze when confronted with elevator door buttons that look like this: <>/><, and with public bathroom entrances, because in Spanish it's usually H/M (hombres/mujeres), but in English it's M/F (male/female), so the presence of the M throws me for a loop. My read on this is that if I see both options at the same time, my brain stutters for a second.
The thing about norman doors is that it's not really a design flaw, not in every case. Like handles on push doors. It's tempting to think of that as a design flaw but more likely it's designed to be mass produced and reversible, the cost of making two (or more) configurations being much higher than the occasional confused user. You could argue this only enhances the metaphor as a lot of design issues occur when things are optimised for the company and not the user.
I still see this as a design flaw, even if it explains why it was done. They save a little in manufacturing, and then thousands of people per day end up using it wrong for decades, in the case of a high traffic door, like at a mall.
Related… this is one of my favorite Far Side comics.
Wouldn't the solution to make the door so different handles can fit on both sides and then the installer can simply put the correct handle on each side as needed? Surely that is just as much of a manufacturing efficiency improvement.
My car has a staggeringly bad UI design choice - the cancel active navigation the control to do this only appears when you hold your finger close to the screen. Pretty much every time I want to do this I am flummoxed as to "Where did the button go" - before I eventually remember.
The navigation system is good - I prefer it to using my phone and CarPlay but that design is terrible.
Is it a VW? I had a VW with a proximity sensor like that. I didn’t use the in-car navigation, but it did that for the favorites on the radio. They only showed as I moved my finger close to the screen.
I also have a Skoda that also has that "feature". I prefer using Maps via Android Auto, but if I am in that interface, and I have to cancel it, the way I cancel it is using a voice command.
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.
May be it's just me, but the very first example (contacts form) looks better (easier to read) on the left than text in empty space on the right (which is supposed to be the good design)...
It's not just you, I didn't even open the link and know exactly which two examples you're talking about because I left this same comment on HN a while ago.
So much of modern design is fashion yet the designers pretend it isn't. Like it's some scientifically provable truth or axiom that faint lines between list items is "bad".
Either you want to support the authors and give them the price they ask or don't. You being on this platform gives me the assumption that you can definitely find pretty much any PDF on the Internet for free, in a way or another.
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
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.
My first recommendation would be to impose a hierarchy --- surely the books can be grouped in some fashion useful to the viewer? Perhaps by the intended reader? So maybe:
- beginning designer
- developer working with designer
- developer working without assistance from a designer
- supervisor working with team of designers and developers
Long flat lists of undifferentiated items are a common problem in design and your page not solving that is decidedly not confidence-building.
Also, was surprised not to see what I consider one of the best books on visual interface design listed:
Unfortunately, this book was marred reputationally by the reissue having a ghastly cover and poor quality screengrab reproductions --- track down a first edition if possible.
Most web design books are essentially going to tell you to put a navigation bar on top or on the side, with a big call to action button in the centre while laying everything out on a grid (hence why most websites now looks the same). Logo design books now are always going to tell you take inspiration from the Twitter or Nike logo e.g. something that is simple but easily recognisable from afar (everything is now a swirl or a a single polygon). The colour theory stuff is half pseudo-science and mostly going to tell you to pick from a small colour palette with a consistent primary/secondary colour while keeping in mind that colours are perceived differently in different cultures (now you have everything in black/blue/red and white). The only one that I liked was Refactoring UI because it demonstrated how small changes can add up to make something that looks amateur look professional. But you can probably learn more just by investigating things you like yourself and implementing them.
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 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.
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)
> maybe system thinking is really complex and thus hard to convey and use.
I'm pretty sure that's not true. If you can follow how A leads to -> B, then that's about it all. Systems thinking is the same principle at a larger scale, with interesting side effects at times (eg network effects/group think/emergent phenomenon showing up).
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.
It leans a bit more on the cybernetic side but gives an overview and has what is possibly equally important as the text itself: some 7 pages of references.
I started with openly accessible academic papers instead of books. If you find something interest there, you will surely have the direct reference to proceed further into that direction right at hand. Papers are shorter, you can switch the direction more easily. The price to pay is to miss the bigger picture a couple of times (which a book may convey) until some loose ends come together and create an aha moment.
(given what you said I would stay clear of all reinterpretations/popular science books. I would read something straight from the source, the people in the field, in whatever form it may show up.)
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.
Taking a theory (Systems Thinking), a mental model which has the primary goal of holistically identifying, describing, and understanding wholes and reducing it down to a set of methods/framework out of ease of use (the pragmatism) is exactly the wrong approach in my opinion.
Systems Thinking and all of its applications scenarios are based on epistemology. To turn it into a recipe is a wrongdoing. The whole notion is that one size does not fit all.
The operationalization of Systems Theory for a given case at hand is the responsibility and the transfer function of the operator whose approach this is. The process itself yields understanding and should not be abbreviated.
So your argument is don't use an off the shelf tool that gets the job done, build your own tool every time which likely doesn't offer any advantage over the standard tool?
If you think using Design Thinking goes against Systems Thinking, I don't think you really get either.
> So what do you mean by "Design Thinking does with its sole existence what Systems Thinking tried to avoid"?
It’s its approach to Systems. Take the 5 stages. Why 5, not 10 or 3? Why stages at all? Who’s to say? Why not enable people to create stages themselves and run from there? Or whatever fits their business.
Why not teach methodology instead of method?
>I'm not sure why you think it's relevant here.
I can only repeat myself:
The value is in the process of inquiry itself. Systems Theory is not a set of methods. It is an epistemological based theory and requires a shift in how a person perceives reality, the often cited worldview. How do you know what you know? By assuming 5 stages? Is that objectively induced? What happens to that if looking through the lens of radical constructivism? The theory requires to incorporate multiple worldviews and with that, negates the assumption of an objective truth.
I practiced Design Thinking at IDEO for 10 years, and I can assure you it's not "one size fits all." And you can onboard an intern or a client CEO in days, without requiring them to internalize a very abstract system for decomposing problems.
That may possibly explain your motivation but even ten years do not make it right, nor the speed of teaching.
You are saying it yourself: internalising the very abstract system for decomposing and adapting it has a value of its own you cannot replicate by pre-solving it. The spinning-off of Design Thinking only accomplished further segmentation of a space which was already too fractured and was a disservice to the field.
I don’t think we will approach a consensus here, and that’s fine.
It's always valuable to have a generalizable skill. But design is fundamentally a craft; an applied art. It's problem-solving. And like any craft, there are tools and techniques that are tried and true. You could approach woodworking with a ground-up Systems Thinking approach, but would you turn down the advice of a carpenter with 30 years of experience? Technically all you need to understand woodworking is a physics textbook and maybe an organic chemistry textbook.
My guess is you're a software developer (as I am), and in my opinion the fatal flaw of our group is the incorrect belief that we could do anything or solve any problem by simply decomposing it into smaller and smaller components. The thing is, for a big enough problem, there are an almost infinite number of ways to break it down and then build it back up. In optimization terms, complex projects are highly nonlinear problems, so you may be able to understand what the inputs are, but it sometimes takes wisdom and experience to tune the parameters.
Around ten years ago, I was a designer for some 20 years. A strange path led me to a different place which is intermixed or adjacent to the field of organisational theory.
At that time, I decomposed problems too, maybe a bit differently than a developer, I can’t really know. I still decompose, except that the difference to the past is that analysis only makes up one part of the larger whole. I knew many designers which never did either.
I agree with you that there are some areas which do not need theory. That depends on where you define the system boundaries. In the example of a carpenter: Yes, 30 years, the person indeed knows that stuff. One of first question of Systems Thinking, however, would be: What’s the reference system, is his company viable in the future?
I very much believe that if you apply this to complex projects, to ‘communication and control’ of an enterprise, that one should know the backstory.
The reductionist approach got us to the problems, applying reductionism to a theory trying to solve reductionism is courageous. In my opinion, the method which is used to teach must incorporate the principle which it is trying to convey. An alternative worldview needs to have a starting point somewhere, and I like to think it starts with the education, which is not to say that I do not understand the urge to speed up absorption of the theory.
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.
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.
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”.
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.
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.
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.
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.
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.
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.
NB: I am a data scientist.
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.
> ... my masters was in signal processing
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.
Yet I suspect that mechanical engineers are not writing software for companies in the large. There are software developers doing so.
I suspect that they should be consulted by data science folks as domain experts.
That said won’t AI replace both? ;)
Likewise, UX designers should consult HCI experts.
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?
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.
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.
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.
> people think that they can just come in and ...
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.
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.
> "I like your design thinking, I do not like your design thinking people. Your design thinking people are so unlike your design thinking."
- Gandhi
when Idea Guys™ never get told to buzz off
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.
The fact that it’s mostly being pushed by UX people.
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.
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.
DOET (neé Psychology of Everyday Things) deeply influenced me. Articulated things I had observed, experienced. Expanded my thinking.
I was using, teaching, and developing for AutoCAD at the time. Knew nothing about UI beyond my intuition. Just perplexed by how difficult it was for most to use.
Reflecting back, Norman's treatment of mental models and kinds of errors were the most impactful, evergreen design challenges I faced.
I read the Design of Everyday Things and most of it was painfully obvious examples and was overly philosophical.
Design is solving problems so they're intuitive for the user. Obviously a door with a handle shouldn't be a push door, I don't really think you need to write a book about it. And the types of people creating bad design are generally constrained by cost, time, or practicality, not necessarily by education.
> Obviously a door with a handle shouldn't be a push door, I don't really think you need to write a book about it.
It’s common to illustrate principles with examples that appear obvious, i.e. that everyone agrees on, so that after having it conceptualized as a principle, you’ll apply it in less obvious circumstances. Many things are obvious only in hindsight.
> And the types of people creating bad design are generally constrained by cost, time, or practicality, not necessarily by education.
That’s not true, because a lot of flawed design is being promoted and defended in public as the thing to do.
> Obviously a door with a handle shouldn't be a push door, I don't really think you need to write a book about it.
And yet we've all encountered push doors with handles many times.
> And the types of people creating bad design are generally constrained by cost, time, or practicality, not necessarily by education.
Good design is far cheaper and easier than bad design in the long run. Being able to articulate the benefit of good design such that stakeholders provide the resources for good design is perhaps one of the most important reasons to have such an education.
uh, the fact that this is written down and carefully put in frameworks is a good thing. Otherwise you can say any academic book is intuitive. the fact that it sounds obvious means they're getting the message across. because lord knows it was needed and there's plenty of failed products and ideas because of shitty design.
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.
I love this. Thank you for introducing me to "Norman Doors". I hadn't realized someone else had described this in such detail. I have been complaining about this years.
Ok this will be a tangent, but I also take this one step farther and also talk about "documentation". Just for the record, I don't think documentation is all good or all bad, but it definitely can be used incorrectly and in excess. And Norman Doors and a great way to get this point across.
When someone creates or installs a Norman Door by accident or out of ignorance and then realizes there is a problem, they often think "I know, I will document it!" and they add little placards to the door that says "Push/Pull" or some such. They see that this helps with a small subset of users and thinks "there, I fixed the problem, people just need to read the documentation and now it is their problem if they don't". But if you watch users of the door, a large portion will still use the door incorrectly because... people don't read documentation. If they don't read documentation, is it the users fault the door was designed incorrectly or was it the designers problem?
I use this as an example for my developers on thinking before documenting troublesome code or a confusing interface to first ask "can I design this so it is less confusing?" and if so, that would usually be preferable to adding documentation "to solve the problem". Well designed code (or doors) with no documentation always beats poor designs with documentation.
Which reminds me of another "there, problem solved!" pet peeve of mine. I call it the Default Trap.
In many cases (Norman Doors are an example), there are two or more equally valid ways to do something. By "equally valid", I mean there is no clear standard for whether it should operate one way or the other, and if you ask 100 people which way it should work (which no one ever does), you get something approaching 50%.
So the product manager or perhaps developer simply says "make it a setting", and everyone agrees and declares the problem solved.
But the problem is, you have to choose a default. And 90% of the time, no one is going to change that default, or even discover how to. So you have to be very correct about assuming which value is the best default - and at that point, it probably doesn't matter that you make it an option.
The alternative I've seen to this is to ask the user which way they want it during the setup process. Light vs Dark mode is an example of this. The net result of this user choice is a longer, more complex, and burdensome onboarding process that is rife with decision fatigue. Once the user has chosen, if they don't like their choice, they may not know how to change it, since that initial action was outside of any standard interface.
The other issue with settings for everything is that the settings become bloated. In OS X, and to some extent iOS, I knew where all the settings were for the most part. Browsing them all to see what was available was a consumable thing, and I could largely remember where to go without much trouble. As macOS and iOS have added more settings to try and please everyone, and now redesigned the Settings apps... I've given up. I have no idea where most things are, what is in there, and have to search for everything and hope I use the right words.
There is an old video of Steve Jobs[0] talking about how every product is a series of decisions and trade offs. People pay companies to make all these decisions, and ideally, there is a company that makes decisions to similar enough sensibilities as yourself so that you can buy a product and use it without much fuss. It seems more and more that these decisions are all being pushed to the consumer, which in some ways makes a worse product. If I wanted infinite chose at the expense of complexity, I'd be running Gentoo or Arch. People choose macOS because it's supposed to be easy.
[0] https://www.youtube.com/watch?v=XmRNIGqzuRI
There's a funny example of even the "documentation" going wrong. At a local mall, there is a set of doors and they have put the word "PULL" (vertically like:
P
U
L
L
) on the window of the door, so from the wrong/opposite side, you still see the word "PULL" when you should PUSH (even if most of the letters are backward) so you still are tempted to take the wrong action when you see it. (I tried to explain the ridiculousness of it to the person I was with, but I don't think they cared.)
I've long suspected that I have a particular form of...dyslexia?, because I suffer from that Pull/Push thing, but also freeze when confronted with elevator door buttons that look like this: <>/><, and with public bathroom entrances, because in Spanish it's usually H/M (hombres/mujeres), but in English it's M/F (male/female), so the presence of the M throws me for a loop. My read on this is that if I see both options at the same time, my brain stutters for a second.
The thing about norman doors is that it's not really a design flaw, not in every case. Like handles on push doors. It's tempting to think of that as a design flaw but more likely it's designed to be mass produced and reversible, the cost of making two (or more) configurations being much higher than the occasional confused user. You could argue this only enhances the metaphor as a lot of design issues occur when things are optimised for the company and not the user.
I still see this as a design flaw, even if it explains why it was done. They save a little in manufacturing, and then thousands of people per day end up using it wrong for decades, in the case of a high traffic door, like at a mall.
Related… this is one of my favorite Far Side comics.
https://fifetli.wordpress.com/wp-content/uploads/2019/01/scr...
Wouldn't the solution to make the door so different handles can fit on both sides and then the installer can simply put the correct handle on each side as needed? Surely that is just as much of a manufacturing efficiency improvement.
My car has a staggeringly bad UI design choice - the cancel active navigation the control to do this only appears when you hold your finger close to the screen. Pretty much every time I want to do this I am flummoxed as to "Where did the button go" - before I eventually remember.
The navigation system is good - I prefer it to using my phone and CarPlay but that design is terrible.
Is it a VW? I had a VW with a proximity sensor like that. I didn’t use the in-car navigation, but it did that for the favorites on the radio. They only showed as I moved my finger close to the screen.
VW Group yes - a Škoda
I also have a Skoda that also has that "feature". I prefer using Maps via Android Auto, but if I am in that interface, and I have to cancel it, the way I cancel it is using a voice command.
Voice commands and Scottish accents are not a great combination.
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.
The Norman door was a powerful example for me, as it emphasises that the user is not the problem but the push door with the handle is the problem.
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.
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.
Yes this I agree with and was my whole goal with the book
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.
https://www.refactoringui.com
PS. Refactoring UI is from the guys who created TailwindCSS.
May be it's just me, but the very first example (contacts form) looks better (easier to read) on the left than text in empty space on the right (which is supposed to be the good design)...
It's not just you, I didn't even open the link and know exactly which two examples you're talking about because I left this same comment on HN a while ago.
So much of modern design is fashion yet the designers pretend it isn't. Like it's some scientifically provable truth or axiom that faint lines between list items is "bad".
Just judging by eye, I'll bet in both of those designs the "Team/Member" text would fail one of the WCAG grades.
Thin, light grey text on a white background is not really very good design.
$99 for a 218 page PDF which, while it has a Goodreads page which rates it highly:
https://www.goodreads.com/en/book/show/43190966-refactoring-...
doesn't have a working "Purchase on Amazon" link, and searching there for:
"Refactoring UI Adam Wathan , Steve Schoger"
returns no results.
One can get two "free" chapters in exchange for one's e-mail address.
Book deal fall through? Why?
Either you want to support the authors and give them the price they ask or don't. You being on this platform gives me the assumption that you can definitely find pretty much any PDF on the Internet for free, in a way or another.
I would prefer to support the authors by the purchase of a dead tree/printed book.
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.
I read it and thought it contained several good ideas, but was excessively wordy and would have benefited from being half as long.
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
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.
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.
[0]: https://www.designorate.com/design-thinking-guide-what-why-h...
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...)
It doesn't claim to be different? It puts more emphasis on the design part.
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.
https://en.wikipedia.org/wiki/Don't_Make_Me_Think
I was surprised this wasn't on there, even with a caveat that it's for online sources like you note.
Ha ha, I love even the cover photo of “The Design of Everyday Things.”
Noted couple of books.
I've been curating (mostly design) books on a digital library: https://links.1984.design/books
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.
Any suggestions are welcome. I would be happy to increase the quality of the library.
My first recommendation would be to impose a hierarchy --- surely the books can be grouped in some fashion useful to the viewer? Perhaps by the intended reader? So maybe:
- beginning designer
- developer working with designer
- developer working without assistance from a designer
- supervisor working with team of designers and developers
Long flat lists of undifferentiated items are a common problem in design and your page not solving that is decidedly not confidence-building.
Also, was surprised not to see what I consider one of the best books on visual interface design listed:
https://www.goodreads.com/book/show/344729.Designing_Visual_...
Unfortunately, this book was marred reputationally by the reissue having a ghastly cover and poor quality screengrab reproductions --- track down a first edition if possible.
Thanks, added the book to the library and will explore categorization options.
Most web design books are essentially going to tell you to put a navigation bar on top or on the side, with a big call to action button in the centre while laying everything out on a grid (hence why most websites now looks the same). Logo design books now are always going to tell you take inspiration from the Twitter or Nike logo e.g. something that is simple but easily recognisable from afar (everything is now a swirl or a a single polygon). The colour theory stuff is half pseudo-science and mostly going to tell you to pick from a small colour palette with a consistent primary/secondary colour while keeping in mind that colours are perceived differently in different cultures (now you have everything in black/blue/red and white). The only one that I liked was Refactoring UI because it demonstrated how small changes can add up to make something that looks amateur look professional. But you can probably learn more just by investigating things you like yourself and implementing them.
Nice collection, "Weniger, aber besser" by Rams will suffice and is at home on any shelf.
This looks like a really nice collection of books. Thanks for sharing!
Wow excellent thank you
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.
Here's their website for the book, along with some tools and useful instructional videos https://www.creativeconfidence.com/tools/
+1 agreed, Creative Confidence is an insipiring book.
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 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.
Please don’t use Design Thinking.
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.
Someone tried to explain systems thinking to me with respect to a planning effort we had.
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.
I have no idea what the exact topic is, but
> maybe system thinking is really complex and thus hard to convey and use.
I'm pretty sure that's not true. If you can follow how A leads to -> B, then that's about it all. Systems thinking is the same principle at a larger scale, with interesting side effects at times (eg network effects/group think/emergent phenomenon showing up).
Well my 0.2c: in that case it sounds like Systems Thinking is just a subset of Thinking when we live in a world of systems
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.
There are so many subsets of the theory and I have no idea what would interest you and what you already know. Have you seen this paper?
https://www.researchgate.net/publication/220231906_The_Origi...
It leans a bit more on the cybernetic side but gives an overview and has what is possibly equally important as the text itself: some 7 pages of references. I started with openly accessible academic papers instead of books. If you find something interest there, you will surely have the direct reference to proceed further into that direction right at hand. Papers are shorter, you can switch the direction more easily. The price to pay is to miss the bigger picture a couple of times (which a book may convey) until some loose ends come together and create an aha moment.
(given what you said I would stay clear of all reinterpretations/popular science books. I would read something straight from the source, the people in the field, in whatever form it may show up.)
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.
That is exactly the point.
Taking a theory (Systems Thinking), a mental model which has the primary goal of holistically identifying, describing, and understanding wholes and reducing it down to a set of methods/framework out of ease of use (the pragmatism) is exactly the wrong approach in my opinion.
Systems Thinking and all of its applications scenarios are based on epistemology. To turn it into a recipe is a wrongdoing. The whole notion is that one size does not fit all.
The operationalization of Systems Theory for a given case at hand is the responsibility and the transfer function of the operator whose approach this is. The process itself yields understanding and should not be abbreviated.
So your argument is don't use an off the shelf tool that gets the job done, build your own tool every time which likely doesn't offer any advantage over the standard tool?
If you think using Design Thinking goes against Systems Thinking, I don't think you really get either.
>If you think using Design Thinking goes against Systems Thinking
No, not against. One is a subset of the other. but you are free to prove me wrong.
> likely doesn't offer any advantage over the standard tool?
The process in itself has value. Are you sure about the meaning of epistemological?
> No, not against. One is a subset of the other. but you are free to prove me wrong.
So what do you mean by "Design Thinking does with its sole existence what Systems Thinking tried to avoid"?
> Are you sure about the meaning of epistemological?
Yes, but I'm not sure why you think it's relevant here.
> So what do you mean by "Design Thinking does with its sole existence what Systems Thinking tried to avoid"?
It’s its approach to Systems. Take the 5 stages. Why 5, not 10 or 3? Why stages at all? Who’s to say? Why not enable people to create stages themselves and run from there? Or whatever fits their business.
Why not teach methodology instead of method?
>I'm not sure why you think it's relevant here.
I can only repeat myself: The value is in the process of inquiry itself. Systems Theory is not a set of methods. It is an epistemological based theory and requires a shift in how a person perceives reality, the often cited worldview. How do you know what you know? By assuming 5 stages? Is that objectively induced? What happens to that if looking through the lens of radical constructivism? The theory requires to incorporate multiple worldviews and with that, negates the assumption of an objective truth.
I practiced Design Thinking at IDEO for 10 years, and I can assure you it's not "one size fits all." And you can onboard an intern or a client CEO in days, without requiring them to internalize a very abstract system for decomposing problems.
>I practiced Design Thinking at IDEO for 10 years
That may possibly explain your motivation but even ten years do not make it right, nor the speed of teaching.
You are saying it yourself: internalising the very abstract system for decomposing and adapting it has a value of its own you cannot replicate by pre-solving it. The spinning-off of Design Thinking only accomplished further segmentation of a space which was already too fractured and was a disservice to the field.
I don’t think we will approach a consensus here, and that’s fine.
It's always valuable to have a generalizable skill. But design is fundamentally a craft; an applied art. It's problem-solving. And like any craft, there are tools and techniques that are tried and true. You could approach woodworking with a ground-up Systems Thinking approach, but would you turn down the advice of a carpenter with 30 years of experience? Technically all you need to understand woodworking is a physics textbook and maybe an organic chemistry textbook.
My guess is you're a software developer (as I am), and in my opinion the fatal flaw of our group is the incorrect belief that we could do anything or solve any problem by simply decomposing it into smaller and smaller components. The thing is, for a big enough problem, there are an almost infinite number of ways to break it down and then build it back up. In optimization terms, complex projects are highly nonlinear problems, so you may be able to understand what the inputs are, but it sometimes takes wisdom and experience to tune the parameters.
Around ten years ago, I was a designer for some 20 years. A strange path led me to a different place which is intermixed or adjacent to the field of organisational theory.
At that time, I decomposed problems too, maybe a bit differently than a developer, I can’t really know. I still decompose, except that the difference to the past is that analysis only makes up one part of the larger whole. I knew many designers which never did either.
I agree with you that there are some areas which do not need theory. That depends on where you define the system boundaries. In the example of a carpenter: Yes, 30 years, the person indeed knows that stuff. One of first question of Systems Thinking, however, would be: What’s the reference system, is his company viable in the future? I very much believe that if you apply this to complex projects, to ‘communication and control’ of an enterprise, that one should know the backstory.
The reductionist approach got us to the problems, applying reductionism to a theory trying to solve reductionism is courageous. In my opinion, the method which is used to teach must incorporate the principle which it is trying to convey. An alternative worldview needs to have a starting point somewhere, and I like to think it starts with the education, which is not to say that I do not understand the urge to speed up absorption of the theory.
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.
Probably means this article wasn't written by AI!
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.
I will add : "The Design of Design" by Fred Brooks (of The Mythical Man Month fame)
I love 101 Things I Learned at Architecture School.
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.
I improved my doodling skills from that book, but I'm not sure I learned anything generalizable.
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”.
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.
At least there's an author to the article I guess
I was very disappointed when I learned that this wasn't about designing books that think.
https://en.wikipedia.org/wiki/Garden-path_sentence
"Must read" ? Must?
GTFO with this hyperbolic language