Design Thinking Books (2024)

2026-01-2211:51309155www.designorate.com

An updated list of design thinking books and papers to understand the principles underpinning the design thinking process and its practice.

Can you think that following a design thinking process with five steps turns you into a creative innovator?! Believe me, it isn’t and never has been this way. The spread of the term design thinking is aligned with a significant amount of misleading criticism. The doubts about the effectiveness of design thinking are influenced by the promotional language used by some companies, training places, and public speakers. The truth is that there is no secret recipe to turn someone into a creative designer. Yet, there is a way to use the design expertise inside each of us. Understanding the design thinking core values can help team members improve their design ability and appreciate the creative practice inside the organization to achieve the next competitive advantage. This is why I wanted to share with you those key design thinking books to learn the core principles underpinning the design practice.

This is an updated list of design thinking books that I keep adding to their new book suggestions. So, please keep the link or subscribe to the newsletters to receive updates once new books are added. I am also starting to add papers that represent the cornerstone in the design thinking principles that I believe are as important as the book. In this update, two books and one paper added: The Science of Artificial, Wicked Problems in Design Thinking, and How Designers Think.

Previously, we explored different challenges that can be faced when applying design thinking inside the organization ( Why Companies Need to Apply Design Thinking and Why Companies Need to Apply Design Thinking). The majority of these factors rely on the lack of understanding of the core value of design thinking, which can be a reason for over-promotion and misuse of a commercialized language (check Why Design Thinking Doesn’t Work). Above all, many design thinking trainers are not designers themselves and never practice the creative practice before teaching it which causes the gap between classrooms and practices.

To expand my knowledge of the core values behind design thinking, I thought I would share with you some of the book titles that highlight design characteristics. Each of these books explores design from a specific perspective. Learning about these design aspects is essential for both designers and non-designers before jumping to learn design thinking. While there are several books about design thinking toolkits, the books below don’t teach you to design thinking methodology but the core principles behind design thinking to develop new alternatives of ideas and improve the analytical thinking of problems and solutions. They aim to guide you in understanding the core values and practices of design as a collaborative process. By acquiring this knowledge, you can effectively apply any of the design thinking processes we discussed earlier in previous articles with effectiveness. I am sure that those are not the only books out there, so please share with us your book suggestions in the comments below the article.

Related article:

The Double Diamond Design Thinking Process and How to Use it

What is Design? And What is not?

Design Thinking Guide: What, Why and How

Why Design Thinking Doesn’t Work

Measuring the Impact of Design Thinking

The Design Expertise, written by Lawson and Dorst, focuses on the understanding of design practice in the creative industry. The book aims to explore the nature of design from a practitioner’s perspective. It starts by exploring the different definitions of design and how they contributed to identifying the border of the discipline of design.

Design Expertise
Design Expertise by Kees Dorst

The book presents design work for different designers and tries to use this overview of their work to provide a practical example of design characteristics. This book provides you with a base idea about design, what it is, and its characteristics. Exploring the characteristics through design thinking case studies, and examples helps you see design’s core value. This value is the main cornerstone behind the application of the design thinking process.

One of the main design characteristics is to solve problems or move from one position to an improved one. However, this can’t be achieved without a clear idea of the problem and its different borders. In his book Frame Innovation, Dorst explores the cognitive design process’s problem and solution frames. Also, he explores how designers move from one frame to another and how this feedback process contributes toward an optimum solution for wicked problems.

frame innovation
Frame Innovation by Kees Dorst

Many of the design thinking process models move from the exploration stage (divergent) to defining the solution (conversion). While this practice shares the principle of critical thinking, they all move between the problem frame and solution frame. Through this book, you will explore the principles and practices of problem/solution frames to develop creative potential ideas.

The book extends discussion of of the principle of frame innovation by covering the opportunities and challenges related to its application in creative industries. The book ends by putting a practice action plan to move toward using the frame innovation in different business models.

In this small yet informative book, Design Thinking, Nigel Cross explores how designers think and reach creative ideas in the design field and the nature of design from the perspective of idea formation. To this goal, the book overviews design practice based on observing and interviewing creative designers and exploring expert tips with them. Design processes try to explore the design expertise from creating the idea to applying it. However, the design ability comes earlier when ideas are formulated. The book’s first chapter explores this design ability and how each of us has a level of design ability to develop new ideas. Yet, some people are more designers than others, which is known in Lusy Kimbel’s two papers as the creative class (Rethinking Design Thinking: Part 1 and Part 2).

Design Thinking: Understanding How Designers Think and Work
Design Thinking: Understanding How Designers Think and Work by Nigel Cross

The book overviews designers’ practice in different fields and stories. The aim of this overview through creative designers’ experience is to build an understanding of the inspiration or exploration stage in the design thinking process. For instance, what is brainstorming, and why is it applied at an early point in the design thinking process (How to Successfully Apply Inspiration in Design Thinking)? Linking similar questions to the practice helps you map your practice to rational reasoning and subsequently improves the progress of the process in the future.

Change by Design, by Tim Bowen, CEO of the IDEO, is probably one of the commonly known books about design thinking because of the popularity of the IDEO in the application of design thinking in various social innovation contexts. In his book, Tim Brown manifests his ideology about design thinking and interprets it from the organisational perspective. The book aims to clarify what design thinking is, and where to go from theory to practice. In the first part, the books focus on the main concepts of design thinking (check Design Thinking Tools and Methods Complete Guide), such as extending behind the aesthetics, shifting toward a human-centred approach (i.e. improving customer experience and building inclusive design), the power of prototyping, and the importance of storytelling. The second part of the book aims to interpret these principles for practicality to identify the business opportunities for design thinking and the use of design to achieve innovation inside organisations through creative collaboration between stakeholders. 

Change by Design book
Change by Design by Tim Brown.

The book is a good resource for both designers and business people to understand design thinking and its applications. Despite several criticisms of the IDEO design thinking model, the book describes the theoretical base of design thinking, which could have a positive, innovative impact on organisations, especially if applied properly to develop viable business strategies. The IDEO Field Guide can be a good companion for the book as it presents a toolbox to apply Tim Brown’s ideology in practice.

Don Norman is one of the leading professors in behaviour psychology and human-computer interaction (HCI). His book, The Design of Everyday Things, is based on a simple observation: why do we love and hate some elements in our lives? And what is the psychology behind our behaviour toward products? Addressing these two questions presents a cornerstone of your design practice. For example, why do some people love products such as Apple, Mini Cooper, or IKEA? By understanding how consumers love or hate products, the design team can target these features to build an empathic relationship between the product (or service) and the client, known as emphatic design.

The Design of Everyday Things
The Design of Everyday Things for Don Norman

The book explores human-centred design and its impact on usability interaction design principles, as well as user experience. While other books covered this aspect of design experience, Norman studied the experience from a psychological point of view to examine this complex design process. The book covers the psychology behind our daily actions, knowledge, design limitations, and human error. Later, the book explores design thinking as a tool to solve problems and the usage of the Design Council Double Diamond design thinking process. The book is not only for UX designers but for designers from different practices, as you can learn the following:

  1. How the brain works and the psychology related to products and services,
  2. The limitations related to our experience with interacting with designs around and
  3. Human error and a bad design causes .

How Designers Think? by Bryan Lawson is one of the design thinking books I recommend for my students who are still new to problem-solving and understanding the philosophical approach underpinning the problem and solution space in the design thinking process, How Designer Think for Bryan Lawson overviews the design definition, the relation between problem and solutions and the design thinking process.

How Designers Think? by Bryan Lawson

Unlike other books, Lawson doesn’t aim to teach you his method or derive a specific point; it is more like a discussion book to allow you to reflect and synthesise on the design practice and finally come up with your conclusion. The book presents a flow of ideas as a case study, making it easy to understand and enjoyable for new readers in design thinking. I recommend reading it before moving to more advanced books such as The Science of Artificial.

The Science of Artificial is one of Simon’s most famous and irritating works based on three lectures for him at MIT in 1968, a year before the book was first published. The book discusses the nature of human thinking and the “artefact.” In eight chapters, it explores how humans use artefacts to solve everyday problems. His expression of human rationale is expressed with three premises:

  • The limitations in the human’s cognitive ability
  • The time available to make a decision, and
  • The complexity of the problem

Based on these three premises, he concluded that we are under the illusion that we can choose the optimal solution for problems. Instead, we find a way to determine the reasonable solutions (check What Are The Six Thinking Hats? And How to Use Them?).

The Science of Artificial by Herbert Simon

Simon was awarded a Nobel Prize for his theory and its contribution to economic rationality. According to the above theory, Simon defined three problem-solving activities: the ability to conduct a heuristic search for alternatives, evaluate solutions, and allocate resources for search. He illustrates this concept in his statement:

” Human problem solving involves nothing more than varying mixtures of trial and error and selectivity. The selectivity derives from various rules of thumb, or heuristics, suggesting which paths should be tried first and which promising leads.”

Wicked Problems in Design Thinking by Buchanan was published in Design Studies in 1992. Buchanan linked design and analytical philosophy by understanding the design problem’s nature and elements. He discussed two terms: “category” and “placement”, where we frame the different aspects of the problem. Buchanan describes them as follows:

“Understanding the difference between a category and a placement is essential if design thinking is to be regarded as more than a series of creative accidents. Categories have fixed meanings that are accepted within the framework of a theory or a philosophy and serve as the basis for analysing what already exists. Placements have boundaries to shape and constrain meaning but are not rigidly fixed and determinate. The boundary of placement gives a context or orientation to thinking, but the application to a specific situation can generate a new perception of that situation and, hence, a new possibility to be tested. Therefore, placements are sources of new ideas and possibilities when applied to problems in concrete circumstances.”

Wicked Problems in Design Thinking paper by Richard Buchanan

The expandable nature of the “placement” presents a critical element of wicked problems and how we can see them as a universal concept whose boundaries can change based on the situation. This manifestation of the definition of the problem elements presented the cornerstone for Kees Dorst’s problem/solution frame discussed in the earlier book Frame Innovation (What is the 8D Problem-Solving? ).

His ideas of wicked problems link with Simon’s concept about the design thinking process and how it can be seen as a non-linear process where different design ideas interact in the design arena. Also, In this placement, Buchanan differentiated between four elements of the design thinking process:

  • Signs: material objects
  • Things: actions
  • Thoughts: complex systems or environments, which is a weird characterisation.

As he links the above elements and the two terms described earlier (category vs placement), he describes the nature of wicked problems:
“However, when a designer’s conceptual placements become categories of thinking, the result can be mannered imitations of an earlier invention that are no longer relevant to discovering specific possibilities in a new situation. Ideas are then forced onto a situation rather than discovered in the particularities and novel possibilities of that situation.”

The above manifestation describes how wicked problems are constructed and change over time, paving the way for a new perspective on problems and their analysis to identify new solutions (check also How to Use TRIZ in the Problem-Solving Process).

The Dilemmas in a General Theory of Planning by Rittel and Webber, despite its age, remains a seminal work that has significantly influenced the understanding of wicked problems. Published in 1969, this paper laid the groundwork for Kees Dorst’s Frame Innovation and Buchanan’s Wicked Problems, both of which we’ve discussed. While the paper’s focus is on planning and policy science, its insights can be applied to problem definition and the process of solving them. 

The Dilemmas in a General Theory of Planning by Rittel and Webber

Rittel and Webber distinguished between two types of problems: tame and wicked problems. Tame problems are well-defined and clearly stated, and there is a clear direction to finding the solution, such as scientific and business problems (check how this concept influenced TRIZ problem-solving). In contrast, wicked problems are ill-defined, and we can’t define the problem until we reach a solution. However, a wicked problem is never solved, yet it moves from one state to an improved, desirable one. 

The other nature of wicked problems is that we cannot reach a definitive formulation for them. To describe them, we need to develop an exhaustive inventory of conceivable solutions when asking questions about the problem. So, problem understanding and resolution are linked and change as we build an understanding of the problem at a particular moment in time. 

As you can see, the above books and papers give us a novel look at design problems and how we perceive them. My question is, why do we see problems the way we used to? A big part of the answer lies in our language, which presents mental models that stand as barriers to seeing the core nature of problems, especially the wicked ones. Therefore, we needed new vocabulary that helped us to escape these constraints. The New Process, New Vocabulary: Axiofact = A_tefact + Memoranda, by my PhD supervisor, Professor Gilbert Cockton, presents a cornerstone of new vocabularies that can help us see design thinking and how to solve problems. 

The paper eliminated the so-called design thinking process, as the term employs a linear nature; while design thinking is far from linear, it is intersected activities. Cockton described the design practice as design arenas; these arenas are distinguishing “artefacts” and “memoranda.” The “artefact” represents the design outcome, and the “memoranda” is the thing to be borne in mind. This new terminology replaces the problem and solution spaces. However, the Latin root of an artefact means the product of change or doing some art. However, this term is limited as wicked problems are not understood until we solve them, which means artefacts. So, the outcome of the design arena may remain the same as the original state, or the change is against the target user, such as preventive design and design against crime. So, Cockton replaced the word artefact with A_tefact.  The memoranda consist of three arenas:

  • Beneficiaries: The purpose of design
  • Purposes: The Artefact and Evaluation
  • Evaluations: Modifications to the Artefact

The design arenas. Recreated from Cockton (2017).

Other terms were also introduced in the paper, such as episodes to replace stages (or phases) that are inherited from linear process age. The multiple foci (sequence by concurrency) replaced the centre of the process term to indicate the complex nature of the iteration with no simple way to describe it. The term “iteration” is replaced with balanced concurrent drama, and validation is replaced with the term “axiofact,” or the value generated. The new terminology presented in Cockton’s paper allows us to escape the old mental model when addressing wicked problems. If you check the MPPF method in Design Thinking, which we discussed previously, you will find it a useful tool as it can help us address wicked problems. 

Each of the above books and papers focuses on specific aspects of design and how we observe the design thinking practice driven by feedback from both academia and industry. The different design thinking models are based on appreciating these characteristics of design and encouraging it inside the organization. By applying the steps alone, you will never reach any improved status. You need to recognize these characteristics of design and try to practice them during the design process. Again, the above books came to my mind as key books in design. I am sure there are other titles. So, please share it in the comments below.

Brown, T. and Katz, B., 2011. Change by design. Journal of Product Innovation Management28(3), pp.381-383.

Buchanan, R., 1992. Wicked problems in design thinking. Design issues8(2), pp.5-21.

Cockton, G., 2017, May. New process, new vocabulary: Axiofact= a_tefact+ memoranda. In Proceedings of the 2017 CHI Conference Extended Abstracts on Human Factors in Computing Systems (pp. 747-757).

Cross, N., 2023. Design thinking: Understanding how designers think and work. Bloomsbury Publishing.

Dorst, K., 2015. Frame innovation: Create new thinking by design. MIT press.

Norman Donald, A., 2013. The design of everyday things. MIT Press.

Lawson, B., 2006. How designers think. Routledge.

Rittel, H.W. and Webber, M.M., 1973. Dilemmas in a general theory of planning. Policy sciences4(2), pp.155-169.

Simon, H.A., 1988. The science of design: Creating the artificial. Design Issues, pp.67-82.


Read the original article

Comments

  • By bsoles 2026-01-2215:1211 reply

    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.

    • By hliyan 2026-01-2215:384 reply

      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.

      • By rrm1977 2026-02-0322:24

        Yes, excatly. This is why Nigel Cross descirbe is as the designly way of thinking. Everyone has some kind of design ability, yet (good) designers show better ability to interpret situations and connect the differnet factors to better define the problem and solution. The term is underpinned by the meaning of design. Check Shape of Things: A Philosophy of Design book––I should add this to the list.

        Unlike other desciplines, design is looking at the factors from epstimological and constructivism approachs where the meaning of the problem elements is clearly interpreted during the design practice.

        So, feel free to call it anything, at the early 20 century, it was never been called design thinking. I usually prefer to design process/acitvity/thinking.

      • By rukuu001 2026-01-234:101 reply

        Design thinking is a collection of techniques that have been professional-ized into a consulting practice. Hence the mystique.

        What I appreciate about a good design thinking session is:

        - It externalises the insides of peoples heads in a way that allows other participants to share that knowledge. Individual tacit knowledge becomes shared general knowledge.

        - Knowledge elicited during the session is presented in a way that makes it actionable

        A design thinking session is doomed to failure if it isn't comprised of:

        - Domain experts

        - Decision makers

        - A facilitator who actually knows what they're doing

        • By rrm1977 2026-02-0322:27

          Yes, I totally agree. Good expertise is crucial indeed.

      • By atoav 2026-01-2217:571 reply

        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.

        • By rrm1977 2026-02-0322:34

          Yes, this is a very good point indeed.

      • By gnosis67 2026-01-2216:382 reply

        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.

        • By rrm1977 2026-02-0322:39

          To achieve innovation through design. it needs an organisational mindset and this shift comes with understanding that design culture is applied in strategic, tectical, and operational levels. Check my article What is this Thing Called Design Management? (https://www.designorate.com/what-is-this-thing-called-design...). This application ensures building design driven organisation.

        • By mcmcmc 2026-01-237:292 reply

          I think you’re doing situational awareness a disservice, and I’m guessing you’ve never worked in a field where it is a trained discipline.

          It is not just paying attention to your surroundings, it is actively scanning and evaluating to anticipate changes to your situation. Big difference between standing on a hill taking in the view versus keeping your head on a swivel, identify avenues of approach and egress, all while looking, listening, and smelling for anything out of place.

          It is more applicable to the physical world than any software domain.

          • By rrm1977 2026-02-0322:42

            I worked as a designer (digital products) for 15 years before moving to the academia. I used the same mindset to design medical technology devices. While the fields seems to be differnet, the design activities are the same regadlress the outcome artefact. Of course, the expetise inputs varies.

          • By gnosis67 2026-01-2312:182 reply

            Okay soldier, can you tell you are not alone in your own mind, and that American Thought Control is running an extortion racket on the United States Military?

            Can you tell Bannon looted the intelligence community and exposed the envelope of every clandestine military secret by getting Trump to gather all of those commanders into one room?

            You’re screwed and you don’t even know it.

    • By rrm1977 2026-02-0322:17

      You have a veyr good point here. Sadly many people try to sell design thinking as a product without digging into its underpinning philosophy at all. This is driven by many business and egineering schools that tend to turn it into a creativity-making machine. Again sadly, it doesn't work. In order to benefit from design thinking, it is important look at it from the perspective of problem framing before the solution framing. You can check the Frame Innovation by Kees Dorst, who is built on the philosophy of Thomas Khun.

      Another thing is that design thinking is sold as a process where we as desigenrs never think this way. The IDEO drove this approach to make it easy to understand. This is why I teach my students that design is an arena where all the factors and stages blend. You can check the last paper in the article about the Memoranda and Artfect as it sreflects on other proceeses such as the Agile.

    • By ccppurcell 2026-01-2215:191 reply

      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)

      • By bsoles 2026-01-2215:337 reply

        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.

        • By randcraw 2026-01-2217:14

          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.

        • By mythical_39 2026-01-2217:242 reply

          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.

          • By Nevermark 2026-01-2217:44

            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.

          • By bsoles 2026-01-2218:09

            > ... 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.

        • By Grosvenor 2026-01-2218:54

          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.

        • By IOT_Apprentice 2026-01-2215:551 reply

          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? ;)

          • By layer8 2026-01-2217:15

            Likewise, UX designers should consult HCI experts.

        • By doctorpangloss 2026-01-2219:123 reply

          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?

          • By rrm1977 2026-02-0322:50

            Me too don't understand the analogy between design thinking and data science. Both are too different. But even if I am a designer and teach design, I don't think there superiority here. it is how to benefit from each approach to achieve in intended goal.

          • By bsoles 2026-01-2220:062 reply

            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.

            • By doctorpangloss 2026-01-2221:351 reply

              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.

              • By rrm1977 2026-02-0322:53

                it is normal to see people advocate their favourite tool or process. However, I always tell my design students to be critical and strategic when choosing their tools.

          • By rawgabbit 2026-01-2219:58

            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.

        • By runlaszlorun 2026-01-2314:16

          Sorry... OT... But I'm dying to know how you use FFT for machine failures. Is it just a matter of looking for unwelcome vibrations? Or more?

    • By HillRat 2026-01-2216:082 reply

      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.

      • By rrm1977 2026-02-0322:56

        These are good points. Although I discussed the TRIZ in couple of my articles. I need to revisit my thoughts as it is over-egineered Russian tool that eliminate all the benefits of subjective constructivism design mindset. It is simply say, everything can be solved using one fo those 40 ways.

      • By randcraw 2026-01-2217:181 reply

        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?

        • By HillRat 2026-01-2217:43

          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.

    • By jjtheblunt 2026-01-2217:07

      > 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.

    • By tengbretson 2026-01-2219:00

      > "I like your design thinking, I do not like your design thinking people. Your design thinking people are so unlike your design thinking."

      - Gandhi

    • By uxcolumbo 2026-01-2219:081 reply

      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.

      • By bsoles 2026-01-2219:401 reply

        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.

        • By uxcolumbo 2026-01-2221:211 reply

          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.

          • By bsoles 2026-01-2223:581 reply

            > Not sure what you've been sold, but there are no special rules or rigid methods.

            I am not intentionally trying to be argumentative, but

            - I have seen UX designers refer to a team of developers as "my developers" and I take it negatively.

            - I have been into countless design sessions where the UX designers conducted a weird formalized session with cards, sorting, voting with colored stickers, and assigning equal votes to newly hired participants and senior domain experts. They were beyond stupid.

            • By cjmcqueen 2026-01-2310:30

              Sounds like your ego was hurt by a process that's designed to expose ideas from a group on a level playing field. The process was working as intended. If it upset you, it might be worth reflecting on what you can do to be more flexible and open minded, which is hard to do as we gain more experience in life.

    • By b00ty4breakfast 2026-01-2217:13

      when Idea Guys™ never get told to buzz off

    • By codethief 2026-01-2215:252 reply

      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.

      • By bsoles 2026-01-2215:381 reply

        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."

        • By IOT_Apprentice 2026-01-2216:01

          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.

      • By layer8 2026-01-2217:201 reply

        The fact that it’s mostly being pushed by UX people.

        • By codethief 2026-01-2415:07

          Is it? Personally, I've never even encountered it in that context, and I have attended several workshops on Design Thinking.

    • By kwanbix 2026-01-2320:02

      Design Thinking is NOT about UX design.

    • By Mentlo 2026-01-2315:54

      Having read the other comments in reply to this one (and your subsequent replies) - I believe you might be falling into a "No True Scotsman" situation.

      First of - I don't know what circles you've been around, but I've not been in work collectives where either designers, UX-ers or data scientists try to insert themselves to do things instead of software engineers. If anything, in any collective I worked in, if a software engineer was to say a peep everyone would retreat like there's no tomorrow and thank god that they don't have to deal with it and the software engineer will.

      Secondly - I think you are mistaking a structuring and outlining of a process with that being a mandate or an order to follow the process. When I work with software engineers, I expect them to be agile - not to follow an agile process, but to achieve the objectives of the agile manifesto - namely, to iterate ruthlessly, keep an eye on usage signals and lead with MVP's rather than over-design. Good software engineers do that, bad software engineers don't. Ultimately, I don't even judge software engineers by that - I judge them by the ability to produce results.

      I think the implication of your thinking is that this is all nonsense because software engineers innately solve data science problems and design thinking problems when appropriate with appropriate methods - to which I'd reply - there's a shocking amount of software engineers who can't do anything with data and are useless in fitting a linear regression to predict something, let alone doing a Fourier transform - to which, presumably, your response would be "No true software engineer is like that". That's great, but it's not true in the real world. Same with design thinking - there's software engineers who just can't solve problems from first principles (but can, say, create a fail-proof CRUD app to automate a business process).

      The real world is messy and full of people who can't structure their thoughts, or can't structure them in all domains at the least - and things like design thinking - or generalists who can be thrown at any data problem and produce something (i.e. data scientists) - are useful. They're not the best solution always, sure, and if they start being protective of territory - it's a problem - but in a normal collective that doesn't happen.

      Basically - your objection can be boiled down to "generalists are shit, because they impose process on everyone, including people who understand the domain better" - which tells me more about the collectives you've worked in than the nature of those jobs. In every collective I've worked in, generalists are what you throw at an ambiguous problem to produce some results before you get domain specialists in.

  • By yakkomajuri 2026-01-2213:1114 reply

    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.

    • By jasonhong 2026-01-2215:242 reply

      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.

      • By specialist 2026-01-2218:46

        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.

      • By 65 2026-01-2216:383 reply

        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.

        • By layer8 2026-01-2217:29

          > 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.

        • By jjk166 2026-01-2217:44

          > 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.

        • By gdilla 2026-01-2217:10

          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.

    • By al_borland 2026-01-2213:583 reply

      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.

      • By Nemi 2026-01-2214:552 reply

        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.

        • By drivers99 2026-01-2218:201 reply

          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.)

          • By EugenioPerea 2026-01-2219:361 reply

            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.

            • By drivers99 2026-01-2320:13

              > but also freeze when confronted with elevator door buttons that look like this: <>/><

              Same here! It's especially difficult when you're trying to quickly figure out the button to help someone who is about to miss the elevator.

        • By creeble 2026-01-2217:201 reply

          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.

          • By al_borland 2026-01-2218:25

            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

      • By ccppurcell 2026-01-2215:242 reply

        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.

        • By al_borland 2026-01-2216:08

          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...

        • By gtowey 2026-01-2216:43

          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.

      • By arethuza 2026-01-2214:061 reply

        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.

        • By al_borland 2026-01-2214:201 reply

          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.

          • By arethuza 2026-01-2214:421 reply

            VW Group yes - a Škoda

            • By barrkel 2026-01-2216:161 reply

              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.

              • By arethuza 2026-01-2216:38

                Voice commands and Scottish accents are not a great combination.

    • By smusamashah 2026-01-2214:33

      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.

    • By davidivadavid 2026-01-2213:50

      "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.

    • By jbs789 2026-01-2214:441 reply

      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.

    • By TheAceOfHearts 2026-01-2213:462 reply

      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.

      • By mikhailfranco 2026-01-236:30

        Yes - notice, observe, focus, consider, judge, refine ... repeat ...

        - Photography, not to take better photos, but to see the world more continuously and deeply.

        - Architecture, not to build anything, but to be more aware of urban context, visual design, practical use and emotional response in the built environment.

        - Music, not to read a score or play an instrument, but to really hear the structure of music, appreciate melody, pattern, balance, pace, production, individual virtuosity and harmonious combination.

      • By yakkomajuri 2026-01-2213:54

        Yes this I agree with and was my whole goal with the book

    • By Brajeshwar 2026-01-2213:192 reply

      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.

      • By rytis 2026-01-2214:002 reply

        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)...

        • By wpm 2026-01-2214:27

          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".

        • By yakshaving_jgt 2026-01-2217:06

          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.

      • By WillAdams 2026-01-2213:351 reply

        $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?

        • By xandrius 2026-01-2213:541 reply

          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.

          • By WillAdams 2026-01-2215:02

            I would prefer to support the authors by the purchase of a dead tree/printed book.

    • By asplake 2026-01-2217:09

      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.

    • By elicash 2026-01-2214:181 reply

      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

      • By ctxc 2026-01-237:18

        Tangentially, happens to me with music. Some songs aren't _great_, but I still like listening to them for the associations it has.

    • By storystarling 2026-01-2323:17

      That point about rainbow tables seems to ignore how modern hashing works. We use salted hashes (bcrypt, Argon2) specifically to render rainbow tables ineffective. Since the salt is unique per user, pre-computing tables isn't feasible, so a strong password absolutely still matters against brute-forcing the specific hash.

    • By nemetroid 2026-01-2214:38

      I read it and thought it contained several good ideas, but was excessively wordy and would have benefited from being half as long.

    • By bschne 2026-01-2214:13

      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".

    • By kennyk37 2026-01-2213:41

      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.

    • By philote 2026-01-2213:39

      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.

  • By lefstathiou 2026-01-2214:401 reply

    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

    • By stevenhubertron 2026-01-2214:55

      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.

HackerNews