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.
Off the top of my head, some of the key ideas include:
* Affordances, that objects should have (often visual) cues that give hints as to how to use things * Mental models, that every design has three different models, namely system implementation, design model, and user model, and that the design model and user model should try to match each other * Gulf of Evaluation (the gap between the current system state and people's understanding of it) and Gulf of Execution (the gap between what people want the system to do and how to use the system to do it) * Kinds of Errors and how to design to prevent and recover from them, e.g. slips (chose the right action but accidentally did the wrong thing, e.g. fat finger) vs mistakes (chose the wrong action to do)
What's particularly useful about Norman's book is that these key ideas apply for all kinds of user interfaces, from command-line to GUI to voice-only to AR/VR to AI chatbot. I'd encourage you to think about this book in this kind of framing, that it gives you general frameworks for reasoning and talking about UX problems rather than specific practical solutions.
I was 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.
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.
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.
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.
The navigation system is good - I prefer it to using my phone and CarPlay but that design is terrible.
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.
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.
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.
- 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.
PS. Refactoring UI is from the guys who created TailwindCSS.
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?
I've never revisited the book and thanks to your comment I might not ever now ha
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".
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.
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.
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
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.
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.
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.
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.
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.
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.
- Gandhi
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.
"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.
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.
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.
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.
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.
> 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).
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 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.
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
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.
"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...
I've been curating (mostly design) books on a digital library: https://links.1984.design/books
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.
# "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
Here's their website for the book, along with some tools and useful instructional videos https://www.creativeconfidence.com/tools/
Probably means this article wasn't written by AI!
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.
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 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
Don Norman’s book covers a lot on human behaviour, which is the correct lens through which to view “design”.