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.
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.
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.
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.
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.
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.
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.
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 suspect that they should be consulted by data science folks as domain experts.
That said won’t AI replace both? ;)
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?
- Gandhi
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.
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.
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.
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’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.
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.
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.
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.)
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 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.
Related… this is one of my favorite Far Side comics.
https://fifetli.wordpress.com/wp-content/uploads/2019/01/scr...
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.
PS. Refactoring UI is from the guys who created TailwindCSS.
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".
Thin, light grey text on a white background is not really very good design.
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".
# "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
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.
- 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.
Here's their website for the book, along with some tools and useful instructional videos https://www.creativeconfidence.com/tools/
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.
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).
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.
If you think using Design Thinking goes against Systems Thinking, I don't think you really get either.
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.
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.
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.
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.
Don Norman’s book covers a lot on human behaviour, which is the correct lens through which to view “design”.
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