51–60 of 164 posts
I love 101 Things I Learned at Architecture School. It's a very light, approachable book, dealing with surprisingly universal principles. Also it has very nice pictures. Most of it also applies to game dev, and to the design of experiences.
Earlier quoted context omitted.
My car has a staggeringly bad UI design choice - the cancel active navigation the control to do this only appears when you hold your finger close to the screen. Pretty much every time I want to do this I am flummoxed as to "Where did the button go" - before I eventually remember. The navigation system is good - I prefer it to using my phone and CarPlay but that design is terrible.
Is it a VW? I had a VW with a proximity sensor like that. I didn’t use the in-car navigation, but it did that for the favorites on the radio. They only showed as I moved my finger close to the screen.
I'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 inevitab…
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.
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…
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 inevitab…
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…
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.
Please don’t use Design Thinking. Design Thinking is a subset of Systems Thinking (this is the polite interpretation). Design Thinking does with its sole existence what Systems Thinking tried to avoid: Another category to put stuff into, divide and conquer. It is an over-simplified version of the original theories. Better: Jump directly to Systems Thinking, Cybernetics and Systems Theory (and if measurements are more…
Design Thinking (and more broadly, human-centered design) is a pragmatic framework for doing product design in an effective and productive manner. Systems Thinking is a massively more general superset. I'm not really sure how you'd operationalize that on a design project, except by following first principles, which would essentially get you to DT / HCD.
Taking a theory (Systems Thinking), a mental model which has the primary goal of holistically identifying, describing, and understanding wholes and reducing it down to a set of methods/framework out of ease of use (the pragmatism) is exactly the wrong approach in my opinion.
Systems Thinking and all of its applications scenarios are based on epistemology. To turn it into a recipe is a wrongdoing. The whole notion is that one size does not fit all.
The operationalization of Systems Theory for a given case at hand is the responsibility and the transfer function of the operator whose approach this is. The process itself yields understanding and should not be abbreviated.
Earlier quoted context omitted.
$99 for a 218 page PDF which, while it has a Goodreads page which rates it highly: https://www.goodreads.com/en/book/show/43190966-refactoring-... doesn't have a working "Purchase on Amazon" link, and searching there for: "Refactoring UI Adam Wathan , Steve Schoger" returns no results. One can get two "free" chapters in exchange for one's e-mail address. Book deal fall through? Why?
Either you want to support the authors and give them the price they ask or don't. You being on this platform gives me the assumption that you can definitely find pretty much any PDF on the Internet for free, in a way or another.
Earlier quoted context omitted.
Design Thinking (and more broadly, human-centered design) is a pragmatic framework for doing product design in an effective and productive manner. Systems Thinking is a massively more general superset. I'm not really sure how you'd operationalize that on a design project, except by following first principles, which would essentially get you to DT / HCD.
That is exactly the point. Taking a theory (Systems Thinking), a mental model which has the primary goal of holistically identifying, describing, and understanding wholes and reducing it down to a set of methods/framework out of ease of use (the pragmatism) is exactly the wrong approach in my opinion. Systems Thinking and all of its applications scenarios are based on epistemology. To turn it into a recipe is a wrong…
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
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.