Design is how it works, not how it looks. This article seems to mainly be talking about the "polish" of a design. There are more important principles which don't have anything to do with polish, such as not putting the Cancel button next to the Ok button.<p>More like this:<p><a href="https://lawsofux.com" rel="nofollow">https://lawsofux.com</a><p><a href="https://asktog.com/atc/principles-of-interaction-design/" rel="nofollow">https://asktog.com/atc/principles-of-interaction-design/</a><p><a href="https://www.nngroup.com/articles" rel="nofollow">https://www.nngroup.com/articles</a><p>I recommend prototyping the flow/feel of the app before working on the polish, or the functionality:<p><a href="https://principle.app/" rel="nofollow">https://principle.app/</a>
Often the bad designs come from the designers themselves. Just as software developers often fall prey to "NIH", many designers feel the established design systems like Material are insufficient for some reason. That is OK, if you know the rules you can break them, but often they don't know the rules either (grid system, typography, color for accessibility) and want to make "their own mark" with some new creation that is highly idiosyncratic. This doesn't help much, but as in software, it seems to come down to "taste" which is nebulous.<p>In the landing page for this book, there is an example of good (right) / bad(left) design. I have seen designers simply not know what to do with empty space, so they had to fill it with dividers, outlines, and doodads like the left design.<p>I'd like to hear any strategy one has to deal with that. I have taken up Figma and Sketch so I can meet them "where they are" but still, plenty of disagreements can happen.
Looking at the first example given I think this book is the one missing the mark. I genuinely have trouble when things have less borders! I don’t care about things designed to seem nice, I want them to be usable!
Honestly their first concrete example, with fewer borders, is something that bothers me a lot on the internet today. Cool everything looks flat and like part of everything else. That's not hard to go down through a giant list of or anything... /s
> Use fewer borders.<p>> Borders are a great way to distinguish two elements from one another, but using too many of them can make your design feel busy and cluttered<p>Of course. Who needs to know where a GUI element starts and where it ends ? Why not click everything until you discover that the label on the lower left has an action assigned to it. /s<p>A very long time ago there was something called "Style guide". But who needs such outdated staff anymore ?
> [design courses] focus so much on high level principles like color theory and typography which, while important, never helped me make instant improvements<p>Strange, making the very low contrast text more visible on this site is an instant improvement, and it's right there in the "color theory"
As a designer (and former developer) my objection to this is semantic. It's not possible to design beautiful UIs without a designer. The reason is: the designer was you all along. If you are doing design, even half-heartedly, <i>even without knowing it</i>, you are the designer.<p>The relevant questions when it comes to "beautiful UI" are: do you give a shit, and do you have the skill to execute on giving a shit. Most people don't, thus the profession.<p>This book seems to assume the former is true, and wants to give some quick tips on how you can fake the latter. I'm skeptical of this approach, in the same way I'd be skeptical of someone who said "here are 10 tips to make a good program without learning to program". Skeptical, not offended.<p>I'm interpreting the word "beautiful" generously. Beautiful in the same way an equation or algorithm can be beautiful: not just — or even primarily — esthetic, but beautiful in the sense of doing what it's meant to do about as well as can be done. Beauty, truth; truth, beauty, etc.<p>Design is very interesting. I always saw it as a part of engineering: both are interested in finding the optimal solution given a set of constraints and requirements. The tool chain is different, granted. To me, it's fun, and not something I'd want to skip over. See giving a shit, above.
One of the rare moments I simply don't understand how something gets upvoted that much on HN.<p>Edit: this is like "get rich by just following this". It's not wrong, but so much facepalm-inducing, and it's just 100 bucks. Sorry, but: WTF?<p>In my mind there is a bot army upvoting this article at work right now.
I must be a philistine because with the primary example used on the landing page I actually prefer the bordered version. It seems clearer/cleaner to me. Maybe it's a vestige of growing up in the 90's writing Access applications on the side for dosh when I was a teenager?
<i>Use fewer borders.
Borders are a great way to distinguish two elements from one another, but using too many of them can make your design feel busy and cluttered.
Instead, try adding a box shadow, using contrasting background colors, or simply adding more space between elements.</i><p>Everything I hate in UI right from the start. To the point that I have to re-add #0004 borders in settings.json - workbenchColorCustomizations to make it look decently delineated instead of looking like one muddy blob. Most real world objects have distinguishable 3d borders and we are trained to detect and follow them. I know your designer soul doesn’t like it, but deal with it please. Use a normal amount of borders.
A lot of the examples on their front page I flat out disagree with, both because I hate the aesthetics, and because it represents user experience issues that I or my peers have frequently run up against.<p>For example, borders: I would argue the "more borders" example has it the wrong way around. For users with poor "computer familiarity" (e.g. elderly) the difference in tone isn't always as obvious as it might be to others as their eyesight is already poor. The use of borders then allows a clearer division of shapes without having to commit to a fully high-contrast solution.<p>(also the no borders version looks very silly, but that's just my taste)
Skeleton UI (Svelte + Tailwind) is how I go about it. The developer experience is very good. As for the UX, that's mostly just a matter of actually thinking about how people will use the app and taking the time to account for it.<p>In my experience, bad UIs are a product of laziness more than know-how.
Most products don't need a whole book:<p>1) Use a mature, well-designed GUI framework. Especially if you don't have a designer it's unlikely that novel interactions or an unusual visual design will be a key selling point for your product.<p>2) Find a half-dozen folks from your target user audience or proxies who are as similar as possible. Give them a task to do with your product/prototype while you watch. Let them talk aloud without interrupting. Do this early and often.<p>If you can do those two things you will be ahead of most consumer products and vastly ahead of most enterprise products.
This book has been posted on hn before and it’s worth reposting. Highly recommended as a pragmatic and comprehensive guide for principles of UI design. Note that it doesn’t contain any code; it’s purely focused on conceptualising the interface design process.
This could perhaps come off as excessively brutal, but it really is just my true experience in the industry - the worst UIs I have seen (both in terms of UX quality and internal code quality) have been made by that particular kind of developer has has never bothered to go a single inch outside of their little Java/C# box that they were given by their CS undergraduate course, and then, due to some reason like the company doesn't want to hire or move devs around, becomes the senior lead on some big UI piece.<p>The things I have seen...<p>Personally, I think that creating great UIs is not something that can be taught overnight. There is a certain kind of "feel for it" that I think that I have gained through my years of making them; something that I feel like cannot be taught, at least not in some "bootcamp"/"crash-course" way.
Just read the Tufte books for guidelines as well as inspiration. <a href="https://www.edwardtufte.com/tufte/books_ei" rel="nofollow">https://www.edwardtufte.com/tufte/books_ei</a>
> Use fewer borders.<p>The one with borders looks better to me than the one without, it's subjective.<p>Also the whole post is literally an advertisement to sell some book.
Is it just me or do prices for a lot of UI/design resources seem high compared to prices of resources on other parts of IT? 100 $ for a 218 page PDF seem quite steep to me.
> Borders are a great way to distinguish two elements from one another, but using too many of them can make your design feel busy and cluttered. Instead, try adding a box shadow, using contrasting background colors, or simply adding more space between elements.<p>In many cases I like busy and cluttered; I enjoy <a href="https://dofsimulator.net/" rel="nofollow">https://dofsimulator.net/</a> , I use gmail in "compact" mode, etc.<p>The example listed as "bad" is also interesting; it is busy, which may be unappealing, but it also means higher contrast. Also being "cluttered" lets me simply see more information at once. So if I had to deal with large amount of data, I'd prefer that "bad" design.
If you want to design high quality UIs, read this book (Macintosh Human Interface Guidelines)[0] and ingest the concepts it explains. Even though it's not 100% applicable to a brand new software product, it may as well be -- most of the principles are totally applicable, and if you grasp the concepts from this book you will hopefully understand how to design a clearly-understandable user interface.<p>[0] <a href="https://dl.acm.org/doi/book/10.5555/573097" rel="nofollow">https://dl.acm.org/doi/book/10.5555/573097</a> (click "PDF")
There are waaaay too many comments here hung up on the border example. This book changed the game for me, I consider myself a much more talented UX/UI designer. I can actually make stuff that doesn't suck now. highly recommend.
I guess articles like these are why everything seems bland, flat and unfinished.<p>I disagree on the aesthetics. Borders make it look nice and good. When in doubt, add another border.<p>I think it's an interesting perspective, I've heard it before "you're a developer, so what you think looks good does not look good: Your sense of beauty does not count. It does not matter what you prefer, because you're a developer, and your sense of, your preferred aesthetics are to be disregarded-"
Hands down the best book I've read to level up my UI game. Highly recommended to developers who want to get better at UI design with no bullshit and a lot of practical examples.
When it comes to design, I find organizing and structuring content particularly challenging compared to things like font size, spacing and color choice.<p>eg. Given a list of items to display - should I create a grid of cards, a list, or a table? I feel like you could do any of them, but they have different trade-offs that I can't really articulate.<p>Does this book provide guidance on stuff like that? If not, are there other resources out there?
In my experience, the worst designers I've ever worked with are the ones who tend to be more artsy and care more about aesthetics than functionality/usability.<p>Usable is wikipedia, old reddit, etc. Modern design generally sucks as everything is not information dense and involves a ton of navigation to find what you want to do.
This is Design not UX also you can actually get quite far by following those 'rules' you still want to have the meta issues sorted out first before getting to the tweaks. But yes, the notion of practice over art actually does apply - you can make things better in a pedantic way.
I, for one, liked the book and refer to it semi-frequently when I'm working on a project. It's good for nudging things in the right direction, even if it can't turn me into a designer.
For those who missed it back in the day (this is from 2018): the guys who wrote this later created the Tailwind css library.<p>The book/website is one of the major reason why Tailwind was so successful.
Shoutout Steve Schoger!<p>If you don’t already follow him, you probably should.<p><a href="https://twitter.com/steveschoger" rel="nofollow">https://twitter.com/steveschoger</a>
I've read this book cover-to-cover and learned a ton of actionable advice so I recommend it.<p>My only complaint is that they don't offer a physical book.