Hacker News new | past | comments | ask | show | jobs | submit login

Whenever this question comes up, the usual suspects like "The Design of Everyday things" get mentioned and I can't help wonder what it would be like if someone asked for books about learning to program [websites] and kept getting "Godel, Escher Bach", "Zen and Art of Motorcycle Maintenance" or "Meditations" by Marcus Aurelius.



Unless you read The art of war you cannot possibly become a 10x ninja developer. /s

More seriously, I have read the design of everyday things about 10 years ago and it was one of the most boring books I have ever had to go through. I only remember doorknobs and something about affordances. Read refactoringUI as well, some vague shiny UI tips of which can't remember any but 'have decent spacing'. I still can't design even a simple form. I am starting to suspect that if one wants to be good at web design one needs to start doing lots of web design until one gets better. Reading books may come later to place that practical knowledge in some coherent mental framework.


That’s interesting. I went through that book not that long ago and I found it fascinating. I had a hard time putting it down.

I found that the concepts he covers in that book can even be applied for good software API design.

Also, he did spoil doors for me. Pretty much every building I go into now annoys me because of the stupid door handles they pick.


> I am starting to suspect that if one wants to be good at web design one needs to start doing lots of web design until one gets better. Reading books may come later to place that practical knowledge in some coherent mental framework.

This is true, but it's true for anything. Reading a programming book won't teach you to program unless it presents problems you can build on actively throughout the reading. You need applied reps, otherwise you'll at most get some vague inspiration or enjoy/hate it.

This is why I don't read practical books anymore unless I'm prepared to practice what I'm supposed to be learning about during the course of my reading. This is also true for videos.


That's quite interesting. I'm reading design of everyday things right now, and has been very valuable for my product (SaaS,drag/drop). Not actually to build it, but designing parts.(mockups etc)

A lot of it is common sense, but only in hindsight.


These books are a solid foundation for design education, but also design is its own deep field of expertise that you’re not going to learn after a a book or two. Both things can be true.


"Refactoring UI" won't make you a good UI designer on its own, but it's a great place to start. It's the perfect book if after making some software you feel like the design is amateurish and want to know how to start improving it.

And then if you're interested you can dig deeper into colors, layouts, types...


I’d love to learn about colors if you know any layman level books about it. I picked up something about color theory that was way over my head.


I can't remember most of the stuff I read. Doesn't mean having it on the bookshelf as reference is a bad idea. I think most books are like that anyway.


DOET is very helpful in getting you to understand how to think from a user perspective.

I found it to be one of the most useful books in my development as an application programmer.

It teaches you how to see UI


Yes. But he also spends plenty of time on the idea that behind the scenes there are always trade-offs, compromises, etc. That is, organization and personel impact design, often in ways that aren't obvious from the outside.


For websites at this point in time I’d recommend Mozilla’s Getting started with the web: https://developer.mozilla.org/en-US/docs/Learn/Getting_start...

I couldn’t get through Godel, Escher Bach, but can recommend I Am A Strange Loop by the same author! https://en.wikipedia.org/wiki/I_Am_a_Strange_Loop


This has to be the best HN comment in a long time.


I agree, but sorta in both directions—which paints a great contrast between product (design or management) and UI design.

I really enjoyed the book and think it's great entry to a design mindset. This is a mindset for how to make products that work well and people like or would actually use. Is that what we expect of a designer or a product manager? Important, but just a bit downstream of that is how it works and where the buttons/interactions are and whether people think its attractive. Most designers (we can confine this to tech [1]) consider themselves product designers rather than UI (or even UX) and often have that title and the bullet points in the job description to reflect it. That is, they want and are hired to understand users and design _products_. And then later, design _interfaces_—but only later because ofc the interfaces should derive from those things.

You can argue, for various reasons [2], a majority of today's tech designers would not be good at making product decisions (which includes the processes of understanding users or designing products); to which I would mildly agree, but find more pertinent to then immediately question why recruit and hire someone with that offer. You could hire directly a UI or visual designer.

In practice, because of power dynamics, most designers design UIs and some UX. There is indeed time spent on the product work that the designers feel they should be doing as part of a "real" process, but doesn't ever land in the product. That work is done genuinely, but frequently amounts to design theater—both internally to their own teams/companies (which "storytells" the work) and externally when they present their portfolio to others [3]. Most product (design) decisions are not made by designers because they're either not present for or can't win any of the upstream arguments. So even at the UI level, where there is more control, the design is based on "received" constraints.

Anyways, I think your comment is a real good provocation for what do we mean by designer or what should a designer be.

[1] I think this applies to plenty of folks called a designer pre-tech, say, industrial designers or architects.

[2] There are many, but one is simply that designers who are capable at this, find that design is not the place to impact them. They should perhaps become a PM (which is full of its own pitfalls) or found their own company. Or more commonly become a disinterested designer. I'm not sure either role, PM or design, is able to really do this well in the way most tech companies are organized, but the PM is in many cases the designer's real informal manager. And the informality is the problem. They have more power, but not any hard responsibility for/to the designer. And so you get a junior and/or apathetic pool of designers.

[3] Most portfolios, if you're not familiar, present designs as designed (what was made in the design tool) not as implemented (screenshots or the actual live app) for a reason. And further, most




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: