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.
After over a decade of people jumping into these discussions with this line, I’ve gotta push back: Design is also how things look, and how things look can be important.
Consumers care about how things look. If we dismiss presentation and drive people towards UX stuff every time it comes up, then the people we talk to are going to end up having good ideas that no one buys because the packaging is a mess.
Yes: If you have a pretty modal but it can’t be dismissed by clicking outside of it, that’s Bad Design. But when you’ve hammered in all those errant nails and built something that works well, often you look at it and go “I wish it weren’t so ugly”. And we do need books/resources to give people the building blocks they need to make an app that people will agree is “basically good-looking”. (And then hopefully more advanced books/resources about particular styles so people can develop their own stylistic voice)
This criticism feels fairly ironic, since the first guideline at lawsofux.com is the “Aesthetic–Usability Effect: “Users often perceive aesthetically pleasing design as design that’s more usable” (https://lawsofux.com/aesthetic-usability-effect/).
No, it is not. If you're Steve Jobs then yes, but otherwise how it looks and how it works are usually two different job functions. People who are good at visual design are not usually knowledgeable enough to do functional design, and people who are good at functional design are not necessarily good at visual design.
Odd, when I first clicked that second link it opened a page that was virtually unreadable on a mobile device (Android Chrome) - the text literally curved off the left hand edge of the screen. Which made the first sentence "The following principles are fundamental to the design and implementation of effective interfaces[...]for[...]mobile devices..." suggest there was little point reading on. But on reloading in another tab it was basically fine (though I'd argue still not optimal).
I think it's both. Interior designers are primarily interested in aesthetics. Same for the majority of famous fashion designers, who are usually not focused on making utilitarian clothes. It seems like most peoples' definition of design would include the work in those fields. UX is a better description of the aspect of design that cares about functionality and not aesthetics.
I think we're getting confused by fuzzy and overlapping definitions of different scope.
Absolutely, design is also how it works. However, how it works is also very much engineering. In fact, I'd argue that the overlap is even stronger there.
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.
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.
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!
I think this is probably somewhat a pitfall of using this example as a lead.
Design rules like "fewer borders are better" don't tell the story well, but they're easy to teach people. It's harder and less grabby to say something like:
Over reliance on borders to separate types of content can lead to designs where contrast between elements is too sharp and it's harder to read through information. Designers should have a sense for information hierarchy and follow that through in their application. Have a point of view and use the visual design to express that. Tools you can use to create that hierarchy are things like borders, shadows, fills, scale, and space. Using all in concert, you can make a design that feels harmonious, but also allows users to freely navigate through the interface.
That advice is probably harder to grok, and isn't as punchy because it can't be used as a simple diagnostic (do we have fewer borders?), but it is realistic.
It seems like this page/preview conflates interaction design with aesthetic/cosmetic design.
Interaction design is like “which buttons even exist?”, “should this input be represented by a radio or a drop down?”, what is the navigation hierarchy?
You won’t automatically be good at interactions even if your sense of aesthetic is good.
Indeed. In the "correct" version the search field looks almost like a highlighted item in the list. With many modern user interfaces you really need to be trained in the current conventions to see which elements you can interact with. Compare this with the typical unstyled HTML.
I get where you're coming from, but I don't think they are saying to never use borders, but instead use them intentionally. They explain better than "Use less borders" below:
> 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
The example screenshot on the page shows a use case where they want to highlight a single row from a table, and using less borders is great for that. However, if they were trying to increase readability of the table overall, they may choose to keep the borders in place for contrast.
I came to the comments specifically to talk about this first example. I also think the left design is not a bad design. It's just a different style, but both are valid. Maybe the one on the right is more trendy but that's it.
The other examples are more sensible, but this specific one is just the author forgetting about subjectivity.
OTOH, I'm using full screen apps without decorations, and I'm fighting with edge to forcefully remove all the scrollbars on every website automatically (I want 0 scrollbar unless I'm actively scrolling)
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
It's also important to contrast the information density. Both the "bad" and "good" examples are quite readable but the one on the left is going to be more useful for larger lists of things.
I think you could apply their principles to add centered grayed dividers between the lines that don't go through the entire width of each row, maybe 80% or so
This or just alternating the background of each row between light and slightly darker colors
The goal was beautiful design, not good usability.
You gotta admit that it looks good, and eye candy is usually extremely effective for user retention, even if the alternative handles better, technically.
> 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
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
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
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, even without knowing it, you are the designer.
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.
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.
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.
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.
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?
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.
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.
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.
(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.
In my experience, bad UIs are a product of laziness more than know-how.
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.
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.
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.
The code portion of the book can be found at Tailwind UI. I personally have the Application UI license, and I'm going to upgrade to full access soon. It's 100% worth the cost if you are building out component libraries and repeatable work.
Even worse, too much “beauty” can end up being distracting, and thereby reduce usability. Good UI is like good film music — you don’t notice that it’s even there.
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.
The things I have seen...
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.
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.
[+] [-] pazimzadeh|2 years ago|reply
More like this:
https://lawsofux.com
https://asktog.com/atc/principles-of-interaction-design/
https://www.nngroup.com/articles
I recommend prototyping the flow/feel of the app before working on the polish, or the functionality:
https://principle.app/
[+] [-] Uehreka|2 years ago|reply
After over a decade of people jumping into these discussions with this line, I’ve gotta push back: Design is also how things look, and how things look can be important.
Consumers care about how things look. If we dismiss presentation and drive people towards UX stuff every time it comes up, then the people we talk to are going to end up having good ideas that no one buys because the packaging is a mess.
Yes: If you have a pretty modal but it can’t be dismissed by clicking outside of it, that’s Bad Design. But when you’ve hammered in all those errant nails and built something that works well, often you look at it and go “I wish it weren’t so ugly”. And we do need books/resources to give people the building blocks they need to make an app that people will agree is “basically good-looking”. (And then hopefully more advanced books/resources about particular styles so people can develop their own stylistic voice)
[+] [-] BalinKing|2 years ago|reply
[+] [-] petilon|2 years ago|reply
No, it is not. If you're Steve Jobs then yes, but otherwise how it looks and how it works are usually two different job functions. People who are good at visual design are not usually knowledgeable enough to do functional design, and people who are good at functional design are not necessarily good at visual design.
[+] [-] wizofaus|2 years ago|reply
[+] [-] eschneider|2 years ago|reply
[+] [-] phaedryx|2 years ago|reply
[+] [-] chadash|2 years ago|reply
I think it's both. Interior designers are primarily interested in aesthetics. Same for the majority of famous fashion designers, who are usually not focused on making utilitarian clothes. It seems like most peoples' definition of design would include the work in those fields. UX is a better description of the aspect of design that cares about functionality and not aesthetics.
[+] [-] mpweiher|2 years ago|reply
I think we're getting confused by fuzzy and overlapping definitions of different scope.
Absolutely, design is also how it works. However, how it works is also very much engineering. In fact, I'd argue that the overlap is even stronger there.
[+] [-] wst_|2 years ago|reply
[+] [-] sprkwd|2 years ago|reply
[+] [-] canadianfella|2 years ago|reply
[deleted]
[+] [-] clumsysmurf|2 years ago|reply
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.
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.
[+] [-] chillbill|2 years ago|reply
[+] [-] thelogicguy|2 years ago|reply
Design rules like "fewer borders are better" don't tell the story well, but they're easy to teach people. It's harder and less grabby to say something like:
Over reliance on borders to separate types of content can lead to designs where contrast between elements is too sharp and it's harder to read through information. Designers should have a sense for information hierarchy and follow that through in their application. Have a point of view and use the visual design to express that. Tools you can use to create that hierarchy are things like borders, shadows, fills, scale, and space. Using all in concert, you can make a design that feels harmonious, but also allows users to freely navigate through the interface.
That advice is probably harder to grok, and isn't as punchy because it can't be used as a simple diagnostic (do we have fewer borders?), but it is realistic.
[+] [-] gretch|2 years ago|reply
Interaction design is like “which buttons even exist?”, “should this input be represented by a radio or a drop down?”, what is the navigation hierarchy?
You won’t automatically be good at interactions even if your sense of aesthetic is good.
[+] [-] augustk|2 years ago|reply
[+] [-] BiteCode_dev|2 years ago|reply
[+] [-] ssgodderidge|2 years ago|reply
> 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
The example screenshot on the page shows a use case where they want to highlight a single row from a table, and using less borders is great for that. However, if they were trying to increase readability of the table overall, they may choose to keep the borders in place for contrast.
[+] [-] thiht|2 years ago|reply
The other examples are more sensible, but this specific one is just the author forgetting about subjectivity.
[+] [-] csdvrx|2 years ago|reply
different tastes for different people
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] chankstein38|2 years ago|reply
[+] [-] munk-a|2 years ago|reply
[+] [-] jasmer|2 years ago|reply
Most workers today don't remember the old Windows forms: they were good UI. Just ugly.
In fact, those 'Windows Forms' were also fast - it was back in the days when almost everything was fast.
[+] [-] nextaccountic|2 years ago|reply
This or just alternating the background of each row between light and slightly darker colors
[+] [-] 411111111111111|2 years ago|reply
You gotta admit that it looks good, and eye candy is usually extremely effective for user retention, even if the alternative handles better, technically.
[+] [-] hulitu|2 years ago|reply
> 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
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
A very long time ago there was something called "Style guide". But who needs such outdated staff anymore ?
[+] [-] eviks|2 years ago|reply
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"
[+] [-] karaterobot|2 years ago|reply
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.
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.
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.
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.
[+] [-] joebiden2|2 years ago|reply
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?
In my mind there is a bot army upvoting this article at work right now.
[+] [-] kungfufrog|2 years ago|reply
[+] [-] wruza|2 years ago|reply
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.
[+] [-] plaguepilled|2 years ago|reply
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.
(also the no borders version looks very silly, but that's just my taste)
[+] [-] owlbynight|2 years ago|reply
In my experience, bad UIs are a product of laziness more than know-how.
[+] [-] asoneth|2 years ago|reply
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.
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.
If you can do those two things you will be ahead of most consumer products and vastly ahead of most enterprise products.
[+] [-] xk_id|2 years ago|reply
[+] [-] hoofhearted|2 years ago|reply
https://tailwindui.com/
[+] [-] jimmytidey|2 years ago|reply
[+] [-] layer8|2 years ago|reply
[+] [-] shakow|2 years ago|reply
[+] [-] samhuk|2 years ago|reply
The things I have seen...
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.
[+] [-] itronitron|2 years ago|reply
[+] [-] gwbas1c|2 years ago|reply
[+] [-] temp_account_32|2 years ago|reply
The one with borders looks better to me than the one without, it's subjective.
Also the whole post is literally an advertisement to sell some book.
[+] [-] max_streese|2 years ago|reply