As a designer first turned developers in the early 2000, I beg of you to learn the gestalt.
Frameworks, languages, computers, come and go, but the human body doesn't change and the knowledge I have in design, I carry every day and have barely changed over the years. Sure there are new patterns now... "hamburger buttons" and swiping, but the logic remains the same. Human's don't change quickly. They discover things the same way.
Learn about visual hierarchy, visual rhythm, visual grouping, visual contrast, visual symmetry; the golden rule; the theory of colours etc. Think "subject" first, like in photography. Design for first glance & last glance.
Go beyond "do these align".
Think in the eyes of your user as if it's their first visit, there is no content yet, etc; as well as if it's their 1000th visit; cater for both cases; first and power users.
Understand the gestalt, understand the psychology behind design... Why does bright-red jumps at you, at a visceral level?
Feeling that something feels right is great, but understanding deeply why it feels right is a superpower.
Understand the human brain, its discovery process (how do babies discover the world), "why do westerners look top left first"? And you might innovate in design, instead of designing to not offend anyone; or worst, copying dribbble and other sources because "they spent the money".
Trust me if you can learn React or Kubernetes, you surely can learn the gestalt and understand "the design of everyday things"! That knowledge won't expire on you, you'll start seeing it everywhere and you'll carry it for the rest of your life.
I work on a desktop PC and "hamburger buttons" frustrate me beyond reason, in the same way that many other "modern" designs. I understand that cost benefit of having just one implementation for mobile and desktop. But it is still annoying.
> Frameworks, languages, computers, come and go, but the human body doesn't change and the knowledge I have in design, I carry every day and have barely changed over the years.
This is the part that adapting interfaces for the small tactile screen of a phone and then using them on big desktop screens seems so wrong. The design is probably fantastic but it is applied to the wrong interface. The people that designed the desktop interface were good at it and should not have changed. I wish UI designers went back to desktop interfaces for big screens. But mobile has economy of scale on its side so probably it is not going to happen.
I love "The Design Of Everyday Things", the book doesn't talk much about computer UI, yet the 7 design principles it introduces allow to make much more informed design decisions, where design is not just the matter of taste and aesthetic, but of achieving well-specified goals. For example, if the user has no way to figure out what a button in the UI does, and needs to click the button to check it, and even then can't figure out what has happened, it is a more prominent design failure than misalignment of the button.
Designers who remove scroll bars and window borders so you can’t click and drag are computing’s version of a terrorist. It’s an active assault on performance.
The problem with designers is I have to google words like "gestalt" and perform some sort of sacred incantation to "learn" it, all while forcing my eyes to roll back forward.
Who can afford to think like this though? FAANGS? Every designer I've worked with loosely knows some design theory that is impossible to question beyond a quick "hmm maybe a few more pixels on the padding?" and is largely a pixel pusher due to pressure. If I started to talk about visual grouping and the golden rule my boss would have blown a gasket.
I can't name a single well-designed app off the top of my head. I can name a million good-looking ones though. The problem with design is people have to eat. The UI reaches an ideal point but is never frozen, it lasts a limited amount of time before they start shaping the hedge down to a stump. Linear comes to mind. Spotify too. How are you going to reach a good design for a music player when there's 7000 people that need to put in 40 hours a week?
A little lighter on the "gestalt" and a bit heavier on the "will this design murder the weekends of my dev team and scramble the brains of my users" please.
Your advice is completely un-actionable. "Learn the gestalt?" Do you mean the principles of gestalt design? Because half of those are entirely about designing clever logos, not about making useful UX. If designers spent less time gooning over the FedEx logo, everyone would be better off. The remaining principles are good to understand, but all the challenge is in applying them for specific cases.
Or do you mean: simply understand all of human psychology and design UIs that work for everyone? That seems to be what you're saying, but both are impossible. Nobody really understands human psychology, especially those who think they do. Show me a psychology finding that is applicable to UI design and I'll show you a study of 30 college freshman that doesn't replicate. And you cannot design a UI that is intuitive for everyone; people are too different, and the "average person" literally doesn't exist.
So what exactly is your advice? Know everything and apply that knowledge appropriately for your specific situation? React and Kubernetes have clear documentation, tutorials, and canonical ways of doing things. UX design has a couple of clever books. The analogue of "just learn good UX design" is not "just learn React", it's "just learn how to write readable, maintainable, clear, performant code everywhere." It takes decades.
> This system is about achieving the best possible design with the least amount of effort. There’s no need to know about the psychological impact of colors, which fonts are best for which purpose, golden ratios, etc. This is expert-level design knowledge that is just distracting if you’re not on that level. The key is to focus on the few important aspects, and not try to optimize every tiny detail.
>Trust me if you can learn React or Kubernetes, you surely can learn the gestalt and understand "the design of everyday things"!
I understand and share the underlying sentiment, but it seems to me like quite a lot of people are suspiciously satisfied with how learning React or Kubernetes has entirely blinded them to the fact that the everyday things do indeed have a design.
How do you become good at this? Is it simply practising doing UI/UX interfaces over and over and over and over until you get it? Do you have some specific advice on how to get "there" faster? I recently stumbled across this Refactoring UI book[1], heard it's sort of popular, know if it's any good?
This does not strike me as a way one should go about making "good-looking user interfaces" as described in the article. What you are describing is UX, and UX doesn't necessarily imply an aesthetically pleasing UI. I can make things that are very useable but don't look very nice.
What you've called out is meaningful, but it includes an implied requirement that you're not spelling out: the time and effort and attention to detail, along with the history of experience, to really apply the principles you are talking about to a project.
When I read the main article, I interpreted it from my perspective. I'm mostly a systems person. I can appreciate the points you mentioned, but I don't have those other implied things that are prerequisites for applying those concepts effectively.
Without rules of thumb like these, the UIs I design end up looking like grade school collages. Building UIs that make people _feel good_ when using them is not my core competency. I'm just looking for a baseline level of quality.
I believe there are two cohorts here: the people who want to make UIs that are beautiful, and the people who need to make UIs that are not hot garbage.. and we're reading the article from our respective perspectives.
"This system is about achieving the best possible design with the least amount of effort. There’s no need to know about the psychological impact of colors, which fonts are best for which purpose, golden ratios, etc."
Translation: I don't need to know why I am doing anything but hey, it looks okay to my eye, and I didn't spend a lot of effort on it. Now I have more time to write a blog post about it that mostly advertises my app.
"Dark mode was one of the most requested features for Lighthouse. I refrained a long time from adding it because it adds additional work to every UI task."
This reveals a lot about the regression in OSes. Way back in the early '90s, Windows provided a color-scheme editor. Users could set up any color scheme they liked, and all properly-written apps would inherit it and work fine.
I think the major Unix GUIs offered something similar. Meanwhile, Apple's vaunted UI was crippled by hard-coded colors everywhere.
Fast-forward what, 20 years? Everyone finally realizes that inverse color schemes (black text on a white background) SUCK. But what does Microsoft do? REMOVE the color-scheme editor from Windows.
We're still running around trying to deal with a "problem" that was solved 25 years ago. And, as a developer, I can tell you it has been pretty shambolic on Apple platforms. I guess you can say they never understood proper color management, but... damn. So many broken controls in iOS after "dark mode" was first added. A massive design and QA failure.
> ...in the early '90s, Windows provided a color-scheme editor. Users could set up any color scheme they liked, and all properly-written apps would inherit it and work fine.
The color scheme editor actually worked quite nicely up until the release of Windows 2000 [0]. After that, Windows XP introduced the "Luna" visual style (Uxtheme.dll) with inflexible, hard-coded colors. Most software developers stopped caring about color palettes, and almost all applications started using hard-coded colors in their GUIs. They tested their apps with the few skins preinstalled with Windows XP: Blue, Olive Green, and Silver.
>Way back in the early '90s, Windows provided a color-scheme editor. Users could set up any color scheme they liked, and all properly-written apps would inherit it and work fine.
It was barely usable. Many developers used the colors of the default theme no matter what. Others used the Windows-supplied colors for the background color and maybe the main foreground color, then used fixed, non-customizable colors for everything else, making everything invisible or hard to see if you used anything but a white-ish background. Trying to use what we now call dark mode was a big no. At best you could replace the wallpaper by an all-black screen so you feel a little less irradiated by your crt.
Most of the world consists of dark objects against a light field. Written letters made with a pen were dark on light for a couple of thousand years. Your scheme is the inverse one.
> This reveals a lot about the regression in OSes. Way back in the early '90s, Windows provided a color-scheme editor. Users could set up any color scheme they liked, and all properly-written apps would inherit it and work fine.
Windows has a high-contrast settings, it turns applications and websites to black-on-white, it works reasonably well (I have it being turned on for some days now), although there are menu items and switch states that are not visible :/
Also the default themes all use black text on bright background for selection which is bad. White text on a dark color is much better but you can change that.
It's not necessarily true, especially if you have a component library and "swappable" themes.
After an upfront investment of setting up the dark and light themes, you can just use your component library and rely on the themes. It's still an investment, but the investment is "constant" and doesn't scale with the number of UI tasks linearly, you don't need to reinvent the wheel, and come up with colors for every feature.
Of course it's a good idea to switch the themes every once in a while, to make sure you didn't miss something, but it's not a huge issue.
> properly-written apps would inherit it and work fine
It's nice when there's only a handful of UI controls and they're all system-native. Visual Basic was a godsend.
Want a custom control? Draw one using the shape tool, but then you're in for a world of pain maintaining it and handling edge cases.
Want a shadow around it? Draw a second shape and offset it a bit below and a bit to the right of your first shape. Just don't forget when the window gets resized to move/resize not only the first shape but also its shadow separately.
I would argue that the second screenshot with redesigned Lighthouse is slightly worse that the "old" design
- the vertical ruler between the sidebar and the content is gone, making page structure less pronounced
- the redesigned dropdown menu has no borders or shadows and blends with the primary background
- the redesigned dropdown menu lost the little dot which highlighted currently selected option, replacing it with a folder icon, but now it's not useful, because it's the same folder icon for each option
- the old design had really nice and noticeable "Add URL" button. I suppose, it was removed in favor of the "plus" button in the sidebar, but it's not nearly as noticeable and without the label it's not clear what it actually does
Sure, the issues in the old version are valid, but I think the redesign introduced more severe usability issues instead of mostly aesthetic issues
It's also far more difficult to read the numbers relating to the items in the drop down menu. You have to make an effort to track to the right with your eyes to make sure you are in the same row, whereas before the number was right next to the item. There is no need to have the numbers aligned because they are not for comparison.
Starting from 'what looks good' is putting the cart before the horse. Making a UI usable and well laid out first is key. Practical UI and Refactoring UI are great resources, as long as you read them through a lens of 'what works well?' instead of 'what looks pretty?'. The author is absolutely right in that alignment and consistency are important, but that should really be your starting point.
Building a good user interface is fundamentally an engineering challenge. I see roughly two camps in building UIs, one designing a pretty picture and then tweaking the CSS until it looks like the picture, the other treating the CSS as rules of how the UI should behave. A simple example would be using display: flex; gap: 32px; on a parent of two elements instead of margin-right: 32px; on the left-most element. While the end result is identical, specifying the gap on the parent is better, because it puts the responsibility for spacing in the correct place. This also goes for the way you define CSS classes and rules, if two values are linked, like the height of your buttons and the height of your input fields, then try and capture that in a single rule, or extract it out to a variable.
A lot of building good UIs becomes much easier once you adopt the engineering approach. Consistency is almost built-in at that point, and that automatically makes your UIs better and easier to understand. It keeps your CSS more maintainable too.
While I'm sure there are ways to achieve this with Tailwind, generally I tend to see developers do the exact opposite when they use tools like that: just define everything with atomic classes inline, and forget all about the relations of styling rules to eachother. Tailwind has some great concepts, like defining a limited set of values to choose from, but be careful to keep the engineering, rules based way of building UIs.
There are so many times we've gone a direction in our products only to figure out that while we could make the page look pretty, it never would work well. It always ends up being some version of 'if we go direction X, then features Y and Z will have to be shoe-horned in and it'll look ugly'. When you get that feeling, take a step back, come up with some different approaches, and go with a better one.
The "make it pretty"-step should really be the last thing you do. If you design your UI with heavily visually simplified components and in black and white, it should still work and feel right. Make it work right, and the pretty will come.
> The "make it pretty"-step should really be the last thing you do. If you design your UI with heavily visually simplified components and in black and white, it should still work and feel right. Make it work right, and the pretty will come.
Totally agree. I’ve fallen into the trap of chasing “cool” or fancy visuals first, but the most beautiful UI is the one that actually solves the user’s problem. A slick-looking interface that doesn’t work well isn’t really beautiful at all.
I don't understand when people see Tailwind as anything other than a syntax for CSS.
> forget all about the relations of styling rules to eachother
This is a hot take, but the more cascading your styles are, the harder they are to read and debug. I've never been upset to find classes that just correspond 1:1 with DOM elements. And that's what Tailwind is doing.
"Starting from 'what looks good' is putting the cart before the horse. Making a UI usable and well laid out first is key." This is first principles yet is so often ignored.
The notion that the sidebar icons should be aligned with the firm brand logo doesn't make sense to me, these things are not the same. On that point, the before looks better than the after, to me, as the difference is differentiated.
The "what good looks like" example provided, HeroUI, avoids aligning these:
I think the after looks better, it feels more in control, but at the same time, even the before was completely functional and users would be completely happy with it.
I am not sure what is going on with that screen, but the whole page seems to be "vibrating" in a very distracting way, never encountered that on another site before!
It appears to be related to my display settings on Mac OS. When the text size for the display is set to the "Larger text" it shows this vibrating. When the text size is set to one of the smaller sizes the shaking/vibrating does not appear.
The top level icon misalignment is super small and looks like a mistake. The counts for the message list also renders partially renders outside the row for each message for me. So that's a bit of a fail.
I believe what OP refers to as design is largely styling. Design goes much deeper and starts from a position of close empathy with the user. As a dev working on a team that now has professional designers, the difference is night & day. UI design is the most underrated part of our industry IMO. Good design produces happy users far more often than the choice of framework or platform.
Note that good-looking doesn't necessarily translate into well-usable. The examples of alignment and icon weight are more on the side of aesthetics. If there's too much consistency, e.g. everything aligned in the same color with same weight and similar icons, it gets hard to quickly orient on the page and find things. This seems to be a common oversight, even by large companies.
Visual "breaks", such as color changes, spaces, or variation in contrast can help a lot (and still look good). A good example are paragraphs in text: A large chunk of text is more difficult to go through, or re-discover some section, than one divided into paragraphs.
This is true. Also, over time, well-usable but not exactly the best looking can become the "standard" for good-looking after a while because the design becomes so ubiquitous. You could easily make a beautiful or good looking suite of airplane controls (call it a "rebrand"), but most pilots would probably call it disgusting because it violates the common standards and aesthetics that they rely on.
For engineers doing UIs once in a while, I can recommend Refactoring UI [1]. It has a bunch of practical tips for making your life easier: Picking a color palette, font sizes, margins/padding etc.
I came to suggest this (also mentioned in the article). Not just engineers, I would suggest this to designers and managers too. A few of the books I always suggest to people involved in Product (the manager, engineers, and designers) are “Good Enough Design” (List Apart), “Refactoring UI” (this is actually a pretty recent addition), and the classic “Don’t Make Me Think.”
For anyone in the trenches long enough will know that most of the facts, such as the ones from “Refactoring UI” are common sense. Unfortunately, I’ve realized that it is NOT, even for many designers.
This stuff is of course subjective, but a lot of the "improvements" on that page involve adding a bunch of extra whitespace everywhere, the exact trend a lot of people are complaining about nowadays. I'm not saying it's bad per se, but I would not present the design choices on that site as broadly good either.
The first example on that page ("Contacts" box) looks way better in the "before" style. Turns me off their entire proposition because it's obviously incredibly subjective.
This article presumes that the usage scenario has been defined already
(by a PM) and the designer is just creating visual representations to enact the said scenario. In that sense, the article seems to attempt to answer what should a developer do, in the absence of designer. In such situations(ideally you'd avoid them), it might be better to defer to the defaults of a framework such as Tailwind which has basic accessibility concerns addressed.
Such checklist/rule based approaches do not help anyone. Trying to understand why the said rules work from the standpoint of visual perception is much more beneficial in the long run. Designing with the Mind in Mind by Jeff Johnson (of Xerox PARC) is an introductory book on the why behind UI design guidelines that I often recommend to entry level designers.
It's such an irony that for such a topic, website content is actually overflowing on a mobile safari and gets out of the container so the website appears broken.
Exactly my thought! I didn’t even read the article because if you’re holding yourself out as an arbiter of good design but let something that basic slip through your net then in highly skeptical of your claimed authority.
Underrated comment; way too many designers still approach software design as a visual exercise similar to designing a static composition that looks beautiful in marketing materials; but software is all about data structures and what operations people are going to want to do on them.
So much software these days doesn’t let me do things like “do Z on all Xs matching Y”, instead forcing me to repeat the same slow sequence of actions over and over (swipe, tap button; wait for animation to finish. Go back, swipe, tap button; wait for animation to finish. Go back, swipe, …)
I also think "good-looking" user interface is of lesser priority than "good-functioning" UI. Form follows function. I'd much rather have boring or primitively designed UI that works well and intuitively - meaning, I can find the functions I need when I need it - than a beautiful or modern/trendy interface that I have to struggle with to get work done.
So much of modern UI seems to be created by people whose focus is on "looking good" and less about actually using it daily. For example, YouTube has awkward details that make certain common actions painful, or even impossible. Like a modal window that covers up part of the screen where selection is being made, and it can't be moved or closed without losing all selections. Whoever designed it clearly had not used it enough (or at all) because it's impractical and infuriating as a user. I don't care how good it looks if I can't get it to do what I need.
It is absolutely funny that he's talking about alignment, and then you see the chevron in the "better" example :)
But, kidding aside, it's a mechanistic view patterned on avoiding egregious missteps. It's rules for creating not-bad-looking user interfaces.
And... I take that. It's better than a lot of what's built. But I encourage every developer to ask "why" when looking at these rules, or when looking at components in a component library. It's a valuable exploration. It will also teach you the most important thing - and understanding when you can break the rules.
Because without an occasionally broken rule, the design will be lifeless and flat.
> Now I’m in a different camp. I use the components the library provides as much as possible, even if they don’t fit perfectly, even if I’d like to have something different. This makes the UI consistent across all pages and elements.
I've seen a lot of developers feel like they have to write their own components as much as necessary and the results are very, very often underwhelming, especially when they have a bunch of deadlines - underdocumented, not as good looking as something dozens of people have polished over months or years and more often than not buggy.
That's why I think that for most developers (myself included, I can describe myself as a full stack developer, but definitely not someone who specializes in UI design) grabbing something that can be used off the shelf will be the more sane thing to do, personally I quite like PrimeVue, PrimeReact and PrimeNG for this, alongside PrimeFlex and PrimeIcons, they all fit okay well enough. Maybe some of the others + Tailwind for the brave.
That's what I do today for small apps. Grab bulma and add just a sprinkle of CSS on top, mostly page specific spacing. Bootstrap, Foundation,... would just work as well.
The design might be great on your app, but I just had a look at the features page https://lighthouseapp.io/features and it looksquite messy. Too many of colors and information in the feature tiles, colors of icons in the section headers are off, alignment is odd.
As a newcomer, understanding the features on this page takes a lot of efforts.
I honestly don't care at all about "good-looking"; I care more about "functional". Far too many apps seem to be aiming for the former instead of or at the expense of the latter.
I think the only place left for consistency are Emacs, TUI (but 256 colors and 24 bit enthusiasts are encroaching that), desktop environments like GNOME and KDE.
The most sensible approach is one by mpv. Ship the core logic of your app in a bundle/library. And everyone can build the environment specific UI for that.
I agree with the principles discussed here, but am not agreement with the rules based approach. Great looking design isn't about UI 'rules' - it's about making the users of your application love what you're presenting and the application users being able to easily use the features which you're providing without having to think. You can find out more about the principles I follow here: https://photonlines.substack.com/p/an-intuitive-guide-to-int...
For what it's worth looking at the resulting UI, both the before and after screenshots do not look visually attractive. Whether or not that's a problem for this product, I don't know.
Here is a much better rule: Make it look like everything else.
E.g. making a bad looking Qt App takes a lot of effort. If you use the things everyone else is using, the same frameworks, the same layouts and standard components, then users will be immediately familiar and know how your interface works. No, you aren't special, no you do not need to reinvent UX with your SaaS product.
> The logo is further on the left than the other icons.
But why the logo of the website/app should be aligned with the icon of the actions?
> The icons are thin, compared to the text, which is bold.
Why this is an issue?
I can somewhat agree with the other points, but I wouldn't call this "bad design." Just because the information can sometimes be presented better doesn't mean the previous way was bad.
Whenever I read some of these design articles, I usually see this same glaring issue. Without any distinction, they'll present together a grab bag of objective facts, best practices, and simple conventions.
There's nothing objective about using ctrl+s for save, but it's an obvious best practice. So not following can be considered bad design fairly uncontroversially.
The two you mentioned are obviously not in that category. I take issue with the logo one especially, because I find the style of the "bad design" better and more functional.
>[...] I’m probably the only one who noticed that it’s calmer.
The books referenced in the article look great, but mostly seem to cost around $100 each which seems a lot to me compared to reference books in other areas (the O'Reilly one being the obvious exception since it just costs the same as other O'Reilly books)
Anyone have recommendations for UI/UX books for a more modest budget?
I think as long as <ui element> looks like and feels like what they should be, that’s fine. I absolutely hate designers who try to hide elements from the users or require a mouse swipe to reveal them. Mac and everything on Mac seem to be the worst offenders. ChatGPT website comes into mind too.
>> It takes an immense amount of effort to implement the functionality of a component library and make sure all components work well together, from a design (colors, sizes, etc.) and behavior (animations, states like disabled, etc.) perspective.
>> It’s best to build on top of a good component library, and not develop your own.
This, so much this. Suffering greatly at work right now because my predecessor decided to go with ShadCN as opposed to using a full-blown, fully-featured component library. Their reasoning: it's better to have "lego blocks" with which we can build our own components because that would give us full control.
Yeah, no. In 99% of cases, you ain't gonna need that level of granularity. Just take something that exists and tweak it until it looks the way you want.
As an FE dev, I despise the work "consistency". Consistency is in the eye of beholder, and when you have a designer, QA, product manager and other people who chip in, that quickly goes out of hand. Wherever you have to find a balance, that something becomes a point of contention.
keyle|5 months ago
Frameworks, languages, computers, come and go, but the human body doesn't change and the knowledge I have in design, I carry every day and have barely changed over the years. Sure there are new patterns now... "hamburger buttons" and swiping, but the logic remains the same. Human's don't change quickly. They discover things the same way.
Learn about visual hierarchy, visual rhythm, visual grouping, visual contrast, visual symmetry; the golden rule; the theory of colours etc. Think "subject" first, like in photography. Design for first glance & last glance.
Go beyond "do these align".
Think in the eyes of your user as if it's their first visit, there is no content yet, etc; as well as if it's their 1000th visit; cater for both cases; first and power users.
Understand the gestalt, understand the psychology behind design... Why does bright-red jumps at you, at a visceral level?
Feeling that something feels right is great, but understanding deeply why it feels right is a superpower.
Understand the human brain, its discovery process (how do babies discover the world), "why do westerners look top left first"? And you might innovate in design, instead of designing to not offend anyone; or worst, copying dribbble and other sources because "they spent the money".
Trust me if you can learn React or Kubernetes, you surely can learn the gestalt and understand "the design of everyday things"! That knowledge won't expire on you, you'll start seeing it everywhere and you'll carry it for the rest of your life.
Frieren|5 months ago
I work on a desktop PC and "hamburger buttons" frustrate me beyond reason, in the same way that many other "modern" designs. I understand that cost benefit of having just one implementation for mobile and desktop. But it is still annoying.
> Frameworks, languages, computers, come and go, but the human body doesn't change and the knowledge I have in design, I carry every day and have barely changed over the years.
This is the part that adapting interfaces for the small tactile screen of a phone and then using them on big desktop screens seems so wrong. The design is probably fantastic but it is applied to the wrong interface. The people that designed the desktop interface were good at it and should not have changed. I wish UI designers went back to desktop interfaces for big screens. But mobile has economy of scale on its side so probably it is not going to happen.
> "the design of everyday things"
Great book.
mixedbit|5 months ago
mtillman|5 months ago
CrulesAll|5 months ago
MarcelOlsz|5 months ago
Who can afford to think like this though? FAANGS? Every designer I've worked with loosely knows some design theory that is impossible to question beyond a quick "hmm maybe a few more pixels on the padding?" and is largely a pixel pusher due to pressure. If I started to talk about visual grouping and the golden rule my boss would have blown a gasket.
I can't name a single well-designed app off the top of my head. I can name a million good-looking ones though. The problem with design is people have to eat. The UI reaches an ideal point but is never frozen, it lasts a limited amount of time before they start shaping the hedge down to a stump. Linear comes to mind. Spotify too. How are you going to reach a good design for a music player when there's 7000 people that need to put in 40 hours a week?
A little lighter on the "gestalt" and a bit heavier on the "will this design murder the weekends of my dev team and scramble the brains of my users" please.
feoren|5 months ago
Or do you mean: simply understand all of human psychology and design UIs that work for everyone? That seems to be what you're saying, but both are impossible. Nobody really understands human psychology, especially those who think they do. Show me a psychology finding that is applicable to UI design and I'll show you a study of 30 college freshman that doesn't replicate. And you cannot design a UI that is intuitive for everyone; people are too different, and the "average person" literally doesn't exist.
So what exactly is your advice? Know everything and apply that knowledge appropriately for your specific situation? React and Kubernetes have clear documentation, tutorials, and canonical ways of doing things. UX design has a couple of clever books. The analogue of "just learn good UX design" is not "just learn React", it's "just learn how to write readable, maintainable, clear, performant code everywhere." It takes decades.
stefs|5 months ago
> This system is about achieving the best possible design with the least amount of effort. There’s no need to know about the psychological impact of colors, which fonts are best for which purpose, golden ratios, etc. This is expert-level design knowledge that is just distracting if you’re not on that level. The key is to focus on the few important aspects, and not try to optimize every tiny detail.
balamatom|5 months ago
I understand and share the underlying sentiment, but it seems to me like quite a lot of people are suspiciously satisfied with how learning React or Kubernetes has entirely blinded them to the fact that the everyday things do indeed have a design.
cheshire_cat|5 months ago
Is this the book you recommend people read to learn about "the gestalt"?
Are there any other resources/books/courses you can recommend?
Valk3_|5 months ago
[1] https://www.refactoringui.com/
derangedHorse|5 months ago
whitepoplar|5 months ago
lainzhow|5 months ago
KolibriFly|5 months ago
j45|5 months ago
kannanvijayan|5 months ago
What you've called out is meaningful, but it includes an implied requirement that you're not spelling out: the time and effort and attention to detail, along with the history of experience, to really apply the principles you are talking about to a project.
When I read the main article, I interpreted it from my perspective. I'm mostly a systems person. I can appreciate the points you mentioned, but I don't have those other implied things that are prerequisites for applying those concepts effectively.
Without rules of thumb like these, the UIs I design end up looking like grade school collages. Building UIs that make people _feel good_ when using them is not my core competency. I'm just looking for a baseline level of quality.
I believe there are two cohorts here: the people who want to make UIs that are beautiful, and the people who need to make UIs that are not hot garbage.. and we're reading the article from our respective perspectives.
3abiton|5 months ago
card_zero|5 months ago
Fire-Dragon-DoL|5 months ago
dimitrisnl|5 months ago
64d032fe|5 months ago
Translation: I don't need to know why I am doing anything but hey, it looks okay to my eye, and I didn't spend a lot of effort on it. Now I have more time to write a blog post about it that mostly advertises my app.
fedeb95|5 months ago
VerifiedReports|5 months ago
"Dark mode was one of the most requested features for Lighthouse. I refrained a long time from adding it because it adds additional work to every UI task."
This reveals a lot about the regression in OSes. Way back in the early '90s, Windows provided a color-scheme editor. Users could set up any color scheme they liked, and all properly-written apps would inherit it and work fine.
I think the major Unix GUIs offered something similar. Meanwhile, Apple's vaunted UI was crippled by hard-coded colors everywhere.
Fast-forward what, 20 years? Everyone finally realizes that inverse color schemes (black text on a white background) SUCK. But what does Microsoft do? REMOVE the color-scheme editor from Windows.
We're still running around trying to deal with a "problem" that was solved 25 years ago. And, as a developer, I can tell you it has been pretty shambolic on Apple platforms. I guess you can say they never understood proper color management, but... damn. So many broken controls in iOS after "dark mode" was first added. A massive design and QA failure.
thw_9a83c|5 months ago
The color scheme editor actually worked quite nicely up until the release of Windows 2000 [0]. After that, Windows XP introduced the "Luna" visual style (Uxtheme.dll) with inflexible, hard-coded colors. Most software developers stopped caring about color palettes, and almost all applications started using hard-coded colors in their GUIs. They tested their apps with the few skins preinstalled with Windows XP: Blue, Olive Green, and Silver.
[0]: https://imgur.com/a/sXSETJC
ghssds|5 months ago
It was barely usable. Many developers used the colors of the default theme no matter what. Others used the Windows-supplied colors for the background color and maybe the main foreground color, then used fixed, non-customizable colors for everything else, making everything invisible or hard to see if you used anything but a white-ish background. Trying to use what we now call dark mode was a big no. At best you could replace the wallpaper by an all-black screen so you feel a little less irradiated by your crt.
card_zero|5 months ago
bmacho|5 months ago
Windows has a high-contrast settings, it turns applications and websites to black-on-white, it works reasonably well (I have it being turned on for some days now), although there are menu items and switch states that are not visible :/
Also the default themes all use black text on bright background for selection which is bad. White text on a dark color is much better but you can change that.
serial_dev|5 months ago
It's not necessarily true, especially if you have a component library and "swappable" themes.
After an upfront investment of setting up the dark and light themes, you can just use your component library and rely on the themes. It's still an investment, but the investment is "constant" and doesn't scale with the number of UI tasks linearly, you don't need to reinvent the wheel, and come up with colors for every feature.
Of course it's a good idea to switch the themes every once in a while, to make sure you didn't miss something, but it's not a huge issue.
KolibriFly|5 months ago
unsupp0rted|5 months ago
It's nice when there's only a handful of UI controls and they're all system-native. Visual Basic was a godsend.
Want a custom control? Draw one using the shape tool, but then you're in for a world of pain maintaining it and handling edge cases.
Want a shadow around it? Draw a second shape and offset it a bit below and a bit to the right of your first shape. Just don't forget when the window gets resized to move/resize not only the first shape but also its shadow separately.
guappa|5 months ago
renerick|5 months ago
- the vertical ruler between the sidebar and the content is gone, making page structure less pronounced - the redesigned dropdown menu has no borders or shadows and blends with the primary background - the redesigned dropdown menu lost the little dot which highlighted currently selected option, replacing it with a folder icon, but now it's not useful, because it's the same folder icon for each option - the old design had really nice and noticeable "Add URL" button. I suppose, it was removed in favor of the "plus" button in the sidebar, but it's not nearly as noticeable and without the label it's not clear what it actually does
Sure, the issues in the old version are valid, but I think the redesign introduced more severe usability issues instead of mostly aesthetic issues
naich|5 months ago
superice|5 months ago
Building a good user interface is fundamentally an engineering challenge. I see roughly two camps in building UIs, one designing a pretty picture and then tweaking the CSS until it looks like the picture, the other treating the CSS as rules of how the UI should behave. A simple example would be using display: flex; gap: 32px; on a parent of two elements instead of margin-right: 32px; on the left-most element. While the end result is identical, specifying the gap on the parent is better, because it puts the responsibility for spacing in the correct place. This also goes for the way you define CSS classes and rules, if two values are linked, like the height of your buttons and the height of your input fields, then try and capture that in a single rule, or extract it out to a variable.
A lot of building good UIs becomes much easier once you adopt the engineering approach. Consistency is almost built-in at that point, and that automatically makes your UIs better and easier to understand. It keeps your CSS more maintainable too.
While I'm sure there are ways to achieve this with Tailwind, generally I tend to see developers do the exact opposite when they use tools like that: just define everything with atomic classes inline, and forget all about the relations of styling rules to eachother. Tailwind has some great concepts, like defining a limited set of values to choose from, but be careful to keep the engineering, rules based way of building UIs.
There are so many times we've gone a direction in our products only to figure out that while we could make the page look pretty, it never would work well. It always ends up being some version of 'if we go direction X, then features Y and Z will have to be shoe-horned in and it'll look ugly'. When you get that feeling, take a step back, come up with some different approaches, and go with a better one.
The "make it pretty"-step should really be the last thing you do. If you design your UI with heavily visually simplified components and in black and white, it should still work and feel right. Make it work right, and the pretty will come.
dzungfz|5 months ago
Totally agree. I’ve fallen into the trap of chasing “cool” or fancy visuals first, but the most beautiful UI is the one that actually solves the user’s problem. A slick-looking interface that doesn’t work well isn’t really beautiful at all.
tkzed49|5 months ago
> forget all about the relations of styling rules to eachother
This is a hot take, but the more cascading your styles are, the harder they are to read and debug. I've never been upset to find classes that just correspond 1:1 with DOM elements. And that's what Tailwind is doing.
CrulesAll|5 months ago
Terretta|5 months ago
The "what good looks like" example provided, HeroUI, avoids aligning these:
https://www.heroui.pro/components/application/layouts
matusp|5 months ago
travem|5 months ago
It appears to be related to my display settings on Mac OS. When the text size for the display is set to the "Larger text" it shows this vibrating. When the text size is set to one of the smaller sizes the shaking/vibrating does not appear.
boxed|5 months ago
kitd|5 months ago
blauditore|5 months ago
Visual "breaks", such as color changes, spaces, or variation in contrast can help a lot (and still look good). A good example are paragraphs in text: A large chunk of text is more difficult to go through, or re-discover some section, than one divided into paragraphs.
beezlebroxxxxxx|5 months ago
scary-size|5 months ago
[1] https://www.refactoringui.com/
Brajeshwar|5 months ago
For anyone in the trenches long enough will know that most of the facts, such as the ones from “Refactoring UI” are common sense. Unfortunately, I’ve realized that it is NOT, even for many designers.
Fraterkes|5 months ago
wackget|5 months ago
rishi_rt|5 months ago
rishi_rt|5 months ago
oleggromov|5 months ago
saaaaaam|5 months ago
Biganon|5 months ago
wseqyrku|5 months ago
gyomu|5 months ago
So much software these days doesn’t let me do things like “do Z on all Xs matching Y”, instead forcing me to repeat the same slow sequence of actions over and over (swipe, tap button; wait for animation to finish. Go back, swipe, tap button; wait for animation to finish. Go back, swipe, …)
lioeters|5 months ago
So much of modern UI seems to be created by people whose focus is on "looking good" and less about actually using it daily. For example, YouTube has awkward details that make certain common actions painful, or even impossible. Like a modal window that covers up part of the screen where selection is being made, and it can't be moved or closed without losing all selections. Whoever designed it clearly had not used it enough (or at all) because it's impractical and infuriating as a user. I don't care how good it looks if I can't get it to do what I need.
groby_b|5 months ago
But, kidding aside, it's a mechanistic view patterned on avoiding egregious missteps. It's rules for creating not-bad-looking user interfaces.
And... I take that. It's better than a lot of what's built. But I encourage every developer to ask "why" when looking at these rules, or when looking at components in a component library. It's a valuable exploration. It will also teach you the most important thing - and understanding when you can break the rules.
Because without an occasionally broken rule, the design will be lifeless and flat.
watersb|5 months ago
You can find PDF versions of the old Apple HIG online; I just found a GitHub repo that has them:
https://github.com/gingerbeardman/apple-human-interface-guid...
It was a design movement, with zealots and influencers.
Was comparable to Jeffrey Zeldman's "Design with Web Standards".
The books go into reasons for the design decisions they made.
As such, it's still worth reading, more concrete than Norman's "Design of Everyday Things".
KronisLV|5 months ago
I've seen a lot of developers feel like they have to write their own components as much as necessary and the results are very, very often underwhelming, especially when they have a bunch of deadlines - underdocumented, not as good looking as something dozens of people have polished over months or years and more often than not buggy.
That's why I think that for most developers (myself included, I can describe myself as a full stack developer, but definitely not someone who specializes in UI design) grabbing something that can be used off the shelf will be the more sane thing to do, personally I quite like PrimeVue, PrimeReact and PrimeNG for this, alongside PrimeFlex and PrimeIcons, they all fit okay well enough. Maybe some of the others + Tailwind for the brave.
Here's a concrete example of why something like that is a decent example: https://primevue.org/datepicker/
skydhash|5 months ago
plonq|5 months ago
HenriTEL|5 months ago
userbinator|5 months ago
giveita|5 months ago
guappa|5 months ago
2d8a875f-39a2-4|5 months ago
I weep for our field, because this should be true beyond the confines of each app.
Instead even on the desktop we have hoards of local "optimisations" - one in each bloated Electron POS.
There's a place for novelty UI - entertainment.
Productivity should have no place for it.
skydhash|5 months ago
The most sensible approach is one by mpv. Ship the core logic of your app in a bundle/library. And everyone can build the environment specific UI for that.
KolibriFly|5 months ago
photon_lines|5 months ago
presentation|5 months ago
unknown|5 months ago
[deleted]
oneeyedpigeon|5 months ago
https://imgur.com/a/p9mzrRG
eps|5 months ago
constantcrying|5 months ago
E.g. making a bad looking Qt App takes a lot of effort. If you use the things everyone else is using, the same frameworks, the same layouts and standard components, then users will be immediately familiar and know how your interface works. No, you aren't special, no you do not need to reinvent UX with your SaaS product.
wdroz|5 months ago
But why the logo of the website/app should be aligned with the icon of the actions?
> The icons are thin, compared to the text, which is bold.
Why this is an issue?
I can somewhat agree with the other points, but I wouldn't call this "bad design." Just because the information can sometimes be presented better doesn't mean the previous way was bad.
Cordiali|5 months ago
There's nothing objective about using ctrl+s for save, but it's an obvious best practice. So not following can be considered bad design fairly uncontroversially.
The two you mentioned are obviously not in that category. I take issue with the logo one especially, because I find the style of the "bad design" better and more functional.
>[...] I’m probably the only one who noticed that it’s calmer.
Ugh.
benrutter|5 months ago
Anyone have recommendations for UI/UX books for a more modest budget?
ChrisMarshallNY|5 months ago
https://www.amazon.com/Design-Everyday-Things-Revised-Expand...
seaotta|5 months ago
[deleted]
markus_zhang|5 months ago
precompute|5 months ago
pembrook|5 months ago
zahlekhan|5 months ago
enraged_camel|5 months ago
>> It’s best to build on top of a good component library, and not develop your own.
This, so much this. Suffering greatly at work right now because my predecessor decided to go with ShadCN as opposed to using a full-blown, fully-featured component library. Their reasoning: it's better to have "lego blocks" with which we can build our own components because that would give us full control.
Yeah, no. In 99% of cases, you ain't gonna need that level of granularity. Just take something that exists and tweak it until it looks the way you want.
65|5 months ago
Etheryte|5 months ago
tpoacher|5 months ago
devops000|5 months ago
- Refactoring UI
- UI Pedia
And all video courses from Tailwind CSS team
lloydatkinson|5 months ago
mwkaufma|5 months ago
amelius|5 months ago
Don't let your boss add features one at a time. It creates terrible UX.
npn|5 months ago
bbbbbenji|5 months ago
Klaster_1|5 months ago
wackget|5 months ago