And a lot of developers just don't have an eye for it at all. I can look at a UI all day and tell that something is off but I couldn't even begin to tell you what or how to fix it. It doesn't mean I don't care.

It’s not just having an eye for it; UI design is an entire field, and human computer interaction (HCI) has existed since the 70s. I think that a large part of the problem is PMs / managers / tech leads not understanding that design has subjective elements but can also be objectively good or bad, and that they can’t tell the difference between a design that is correct and works well but might not look very flashy vs something that gets lots of likes on Dribble but is awful to use. This feeds into itself and leads to more people thinking that they know what good design is (pretty) and hiring other people who call themselves designers who have no idea about the actual science behind it.

As a developer who appreciates good design but doesn’t really know how to create it, can you suggest a good entry level resource that summarizes what we’ve learned over the last 50 years about HCI and how to make usable interfaces?

Don't Make Me Think be Steve Krugg,Grid systems in Graphic Design by Josef Müller Brockman, Designing with Grids by Mark Boulton, Any of Ellen Lupton's Type Design books. All light reads except Josef's.

Also, the classic Elements of Typographic Style by Robert Bringhurst, and probably just go and read everything on Smashing Magazine from about 2010 to now.

Pluralsight has a few nice courses.

cracks fingers I made a book for you! http://uxbook.io/

A sample would be nice.

The publishers have plans to do that apparently but not yet. I definitely want to do chapter excerpts.

I have the same problem. If you showed me two UIs I could probably identify the more aesthetically pleasing one.

But if you showed me a single UI, I highly doubt I could improve it.

I believe [0] the biggest trick is to avoid most of the things you can do.

[0] http://beza1e1.tuxen.de/slide_design_programmers.html

Tweaking that stuff early on is so effective that it could almost be thought of as a "cheat code" for development. User perception is greatly enhanced by a few hours of tweaking padding spacing etc., rather than a few months or years of deferring that tweaking.

> User perception is greatly enhanced by a few hours of tweaking padding spacing etc., rather than a few months or years of deferring that tweaking.

Some of us explicitly don't want the UI to give off the impression that the software is more finished than what it really is, so we sometimes intentionally keep the UI unpolished while we know that we have important things not yet implemented.

However I have come to realize that there are several downsides to this line of thinking;

1. If the app looks bad then it might permanently put off would-be users.

2. By not giving the UI enough attention early on, discoveries of UX problems that could have been caught early are not made until much later, delaying the project and potentially leading to more work as well because there will be more things that need to be rewritten or remade in order to fix the UX problems.

3. If you think feature X needs to be completed before you do the UI, then what is going to keep features Y and Z and so on to make you think the same way when you get there? Software is often never "complete". If you think it needs to be "complete enough" before you can give it the UI it deserves, how will you know that you've reached the stage of complete enough?

Furthermore, I have come to realize that often we don't know what we want exactly. We might think we know, but as we work on implementing our ideas things turn out to not be quite as we'd imagined them to.

But I also think that grand parent was on to something. When we build software, we should strive to implement features that are useful but not only that, the software needs to make the most common tasks as efficient for the user to perform as possible. And in order to find out what that means, we need to consider the UI from the very beginning.

First make it work, then make it correct, then document it, then make it efficient, then make it pretty.

Rarely all stages are reached, but in open source projects, anyone can cook their favorite dish for this dinner.

The problem with that is that “pretty” is implying simple visual beauty. It diminishes what design really is: the way something works not simply how it looks. “Pretty” should be integral to “make it work.” If your design is good, it’s more self-documenting, so pretty early in the process means less work documenting — it also reveals more of the essence of what exactly you are building which then helps drive the decisions on what to build next.

Design shouldn’t be an afterthought, it should be THE thought.

I disagree. If you make something, THE thought is that it fulfills its function correctly. I wouldn't pursue an excellent UX if the inner workings are buggy.

It is ok, we cannot be an expert on all areas.

My focus is on full stack, so I do care a lot about UI/UX, and improving my skills there.

However don't ask me to do anything related to NoSQL or Deep Learning, I would be a lousy contributor.

> It is ok, we cannot be an expert on all areas.

> My focus is on full stack,

I'm sorry, imo those are two contradicting sentences.

But it might be related to a personal pet peeve of "full stack" developers claiming to be expert in most moving parts of the stack.

Only to post on medium this amazing db hack they found, to be called out in hn comments for not reading the basic docs of one of the core items in their stack.

I always look at Doctors for a bad analogy; why full stack developer is a bad idea. Sure the heart surgeon will be able to diagnose your broken leg. Might even be able to assist you with a cast. But trust him to operate? There a specialist for that!

Is this not the same for dev work? Designer, Developer split into 4 fields(desktop, mobile, frontend, backend), database admin, sys admin. All possible to be done by a "full stack" developer.

But I don't see you become a specialist or expert in any of the fields of your stack, if you don't dedicate to a few.

Well, there is a reason why in some countries access to specialists is forbidden unless you are checked by a general physician first, the one responsible for being your official doctor throughout your entire life.

He knows best than having people searching for specialist by themselves.

As for myself, if you prefer a more descriptive example, I specialize in everything related to Java, .NET and Web (VanilaJS) stacks.

As a citizen of one of those countries, this fails spectacularly when your family doctor does -not- know best or just doesn’t care about his job, yet due to the huge scarcity of family doctors, will never lose any of his clientele.

I used to work for a company that put out thousands of site a year. I was fortunate enough to work with some really anal retentive designers. After a few months, I was able to pick up a 1 or 2 pixel difference in the photoshop docs, see how fonts did or didn't work and if color schemes were decent.

There's a ton of tools out there to help you with these, and as a developer, I like tossing around a lot of the design stuff that gets regulated until an app or site is totally functional, when I feel like most of the design work stuff should be done prior to getting your app working.

Design is the hard part, coding it? For me, that's the easy part. I feel like once I've got some decent font's paired, a color scheme worked out and other design elements nailed, the rest is easy.

I don't think that's a matter of priorities so much. I think most of them simply don't notice it or don't know what's exactly wrong when they do. At least that's what I noticed in some people I worked with.

Aesthetic and polish are over-prioritized in modern development. Which is more likely to anger the user -- a beautiful app sadly broken or an ugly one which does what it says on the tin?

It really depends on degrees. I've seen apps that were so bad, I couldn't even figure out what to do. It could be mathematically provable under the hood, but if I can't even figure out how to use it, or if the experience is bad enough, I won't care how well it is implemented.

They are one in the same. It’s not zero sum. You don’t sacrifice function for form nor should you sacrifice form for function. They should be the same thing. Form follows function — form shouldn’t be tacked on at the end.

We aren’t talking about the color of the paint, we are talking about the way the parts fit together.