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)
More specifically there can be no separation between how something looks and how it works, they're bonded (and for good reason). There is no scenario where you can actually fully break the two apart. Any attempt to try harms one side or the other or both sides. How it works and how it looks go in tandem in all cases, they heavily influence eachother, either making the whole better or worse depending on how you go about creating for that reality.
Anybody telling you different is arguing from a pretty severe bias. If you're designing on the basis of how something works, and not also on how it looks at the same time, you're going to create a subpar outcome.
I'd also note that despite Jakob Nielsen's prominence nobody designs like he suggests. We should be open to the idea that beauty and delight may be more important than usability or features.
This reminds me of expert systems where use is so intense that discoverability is trumped by speed of input. Old DOS/ASCII based retail systems were often optimized for speed.
I imagine that because of the churn of people doing cashier jobs, there is little incentive for businesses to design pos systems that reward expertise over getting someone up to speed quickly.
Must be a complete and unfortunate coincidence then, that the richest tech company on the frickin planet rose to that prominence through "beauty", at least as their critics still like to call out.
If you’re selling a premium produce, then beauty can be justified by the premium price. But us should never be more important than the functionality. Never.
Even a Rolls Royce is a vehicle (and a damned fine one to boot) before it’s an art piece.
In B2B it's usually ease and speed of operation that's more important
SAP (everything), Workday (HR), Service Now (help desk), Archer (compliance), SailPoint (compliance), and other applications that have been inflicted on my miserable existence over the last 25 years of corporate IT; all B2B enterprise applications that I guarantee did not consider either speed or ease of use to be remotely important.
Your pain only proves my point. You know it is supposed to be better, regardless of how it looks. There are outliers who neglect the end users, usually because they are too big or well connected to be replaced.
I don't know if it actually does, maybe in theory, we would assume these companies would be incentivized to optimize for speed and experience but you can't use "the exception that proves the rule" when the majority would fall into the exception category. There have been countless diatribes about how in B2B the purchaser is not the user, so speed, user experience, and functionality are all at best second order priorities. The apps I name checked above all probably provide the base level required amount of functionality that covers the needs of a lot of large privately held and all publicly held US companies, they are looking for the corp equivalent of Wal-Mart shoppers not Nordstrom shoppers (this dove tails into penny wise/pound foolish quarterly earning mindset, corporate America is dumb AF.)
I wish more businesses would treat beauty as a function of a product just like all other “actual” functions of it, a valid part of the whole package. I know it won’t probably happen anytime soon, because “ROI when???”, just been thinking about it a lot after reading Beauty by Sagmeister and Walsh.
> How much of a premium are you, as a customer, willing to pay for the beauty?
Depends on the category of goods, but if I can afford it then I will probably choose something aesthetically pleasing to me most of the time. I can easily get by with an ugly screwdriver if it works well, but I would not like wearing bad-looking shoes.
Generally if I use something often, be it tools, clothes, guitars, utensils and whatnot, I try to find something appealing to my eye. Some people seemingly don’t care much about that, but it just so happens that I do. Paying a premium for the beauty relieves me from being very irritated about something I might not like.
Also, in my opinion, aesthetics, ergonomics and beauty sometimes all are side products of working hard on one of them. Beauty in tools and architecture and interfaces is not to be discarded since it makes our life more pleasing and tolerable. We could live in the holes in the ground, you know, if pure application of things to their intended purpose was all that mattered to us.
> How much functionality will you give up for the shinies?
I’m not sure something has to be given up at all, that’s the point.
If you've visited factories or other work places dominated by men, many of them go by the philosophy of zero attendance to neatness and cleanliness. Those are miserable places to work and even visit. Everybody working there are usually grumpy and miserable, including the boss.
Working all day in ugly software is like a mini version of this.
I don't think anybody considers beautiful software ad a premium, more that ugly software will not be considered at all because it can't be trusted.
Feel free to tease apart beauty and functionality to a roomful of engineers. I'm always up for the debate because everyone has their own perspective and it's usually interesting.
Everything has terrible ROI if you don't understand the "I" and aren't tracking the "R".
Alternatively, functionally doesn't matter if you miss a sale due to someone not liking the design. The first time someone uses/sees something is the most important time for them to like it.
It depends. For typical software and websites, beauty matters every single time: when you like something more and more and more every time you use it, to the point of increasing usage, recommending it, spending money and so on; and when you hate something so much that functionality is effectively reduced by avoidance, distraction, fatigue, rage quitting etc.
In all of this it's a matter of scale.
Products with 100 million users can amortize the costs over a much larger number of deployments. Even the smallest details become valuable at that point. Conversely, at a certain level of deployment, usability is not worth the time investment. Machine Learning researchers can frequently get away with a loose collection of Python scripts with a basic set of instructions that probably worked on their local setup.
Are they really an outlier, or just the best at what they're trying to do? I mean I guess you could always say that the best is an outlier since only one can be the best.
They're the best at what they aim to do. Again, if everyone did it or they were less unique then it would be less exceptional.
The point is, it's hard and rare to get into such a position. Yes, eventually there will be a new Apple, but not yet. So anyone *today* looking to perform well should probably be more practical.
How long is it since any vendor cared about usability and features? HCI is dead. The only thing that matters now is UX: optimising the software to maximise sales. And you're right. Beauty sells. But this is not an insight. It's been standard practice for years. And as an end user it sucks.
This is the first time I’ve seen someone on HN argue against usability in favor of aesthetics the form vs function design debate.
There is so much to say on the topic, books have been written arguing at length even. I would never argue for worse UX if I had a choice, there should be a baseline “good” visual design, but poor UX can and will sink your product in most metrics that matter in the business world.
> We should be open to the idea that beauty and delight may be more important than usability or features.
Oh, please no. We already have more than enough of that line of thinking. In software, especially, we see far too much pretty stuff that is horrendous to actually use.
I'll take the ugly thing that makes my life easier over the pretty thing that does the opposite every single time.
It was a long time I looked in that book but I hated it. Not because it was ugly, I like ugly. But the advice didn’t make sense. It’s been years sincy I thought of Nielsen, maybe I should give at a peek again.
Design like most words has a definition that’s generic so it can be applied as needed. There is no immutable rule when to use it.
The cone of shame my dog has right now “looks cool”; very sleek and streamline for a disposable thing, the designer surely was paid a premium, but the fasteners mechanics were poorly designed; vet tech said even she struggles with them and she puts them on dogs all week.
Design is how it looks and works as “designers” come up with both. The whole idea we can just put our foot down regarding definitions is not at all how reality works since nothing works on divine mandate. It’s relative.
"We talk about design often. At some point during any human lifetime, they will use the word design, and that's a big deal. Aside from 'the' and the 'a' and the 'an' in various languages, design is the fourth most popular word used. Before design was constructed we had the Mesopotamian era, and we all know how that was." -Reggie Watts, 2011
Conversely, A lot of time something looks good "because" it works well.
I had one old structural engineer spend a great deal of time trying to convince me that beautiful bridges were stronger than than ugly bridges. because our ideas of beauty are so tied to what works well. I am not entirely convinced, I have seen the sins some of these so called designers do in the name of "looking good" but I do see his point.
Many people (including me mostly) don't understand why their eyes feel something as "good-looking" or "beauty". It boils down to symmetry being a big part of it, and sometimes symmetry creates working solution. A bridge being the perfect example for that since you need to balance the weight between both sides of the bridge it's easy to get this while also "looking good". But I believe symmetry is not the only thing our brain accounts to beauty. I would love to know more about that topic.
I’d argue that the elegance of a design solution—engineers design things—is what the structural engineer was referring to. The next question is what is elegance in regards to a solution to a problem? Simplicity? Economy, both financial and technical? Aesthetic? The difficulty we have is that few people agree. When I studied industrial design in the early nineties, we were taught that design is merely the process of solving a problem. In fact, when dissecting a brief, the first goal is to establish the problem that needs solving is. The aim of a designer (or indeed an engineer) should be to incorporate all three elements that I mentioned. Sadly, those that struggle with the aesthetic, dismiss it’s importance out of hand.
People judge apps by how they look more than how they work.
If it looks professional and good looking they give it more credit and chances than it deserves. If UX is good but looks are not airbnb/apple wannabe they tend to distrust it.
I've worked as both a designer and developer and for the life of me I can't help but gravitate towards prettier looking applications even at times over more functional ugly ones.
It's a contradiction to what I "should" want as a developer and I'm very aware of this.
Form and function. The intersection is the qualitative property of subjective taste, an intelligence quality of designers who must balance engineering with art.
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.
Bold statement for something subjective. I think you are confusing design and art (from your own experience or misfortune). The processes of visual design have informed (or formalised) the design as a process in other fields. Artists have a style as a function. Designers (visual or not) have process. No one is great at everything. Mediocre designers are either too visual or not at all (especially the latter), in my experience. Good to great designers grasp both and have breath. Even the ones that don't have art as a function can direct, steer and brief the art of a project (or be resourceful with it.) But you can't have design without process.
My comments are based on experience working on projects where some designers (who went to art school) heard Steve Jobs say "design is how it works, not how it looks" and then decided that they own the "how it works" part. The result, from what I have seen, is disastrous.
Functional design (how it works) and visual design (how it looks) is really two different job functions. You don't need an art degree or even be good in art in order to design the functionalities or even interactions of a product. At the same time, being good in art and designing cool looking UI doesn't make you qualified to design the functionalities or interactions of the product. Not even close.
Both job functions are needed to build a good product. In rare cases one person may be able to do both.
"In most people's vocabularies, design means veneer. It's interior decorating. It's the fabric of the curtains of the sofa. But to me, nothing could be further from the meaning of design. Design is the fundamental soul of a human-made creation that ends up expressing itself in successive outer layers of the product or service."
Design is not just one thing or another. It happens at each layer. From deciding how many options you want to present to the user, to how they will be presented. Or deciding how to deal with errors in the backend, versus reporting them in the front end. Design decisions are made the whole way through.
I think this is visible with lots of Apple products because some people complain that they aren’t flexible enough. But reducing configurability is as much a design decision as the colour of the icons. (And sometimes more challenging)
> Design is not just one thing or another. It happens at each layer.
I think we are in agreement. "How it works" is design. "How it looks" is also design. Sometimes, but not usually, one person may be able to do both types of design.
UX often involves research and customer interaction. UI is more straight up visual design, informed by the UX research. The same person might not do both. Do you think they should?
Yes. Yes, they should. A person who does UI and doesn't have first-hand experience on what customers want and do is not a UI designer. That person is a dribbble illustrator.
I remember clearly the first time I ever heard the term “UX”. It was condescending explained by some guy from Google to a quite technical audience of telcos, many years ago. For reasons I couldn’t explain, it pissed me off.
Apple famously did many years of intense user testing to develop their HIG (and maybe still do?). I’m pretty sure xerox did too, and all the other UI researchers many years ago. Maybe even Microsoft did :)
In any case, it contradicts your claim, since all this user research was way, way before UX was a thing.
Honestly I just got the feeling that the phrase UI had become stale and UX was just seen as a way for a new generation to put their mark on the world.
The 1985 edition "includes e.g. case studies (useful!), and an extended discussion of Jung's theories of intuition and how they should influence your designs (!!)"
The dictionary says it means "a plan or drawing produced to show the look and function or workings of a building, garment, or other object before it is built or made."
So it is both "Look" and "function". Claiming looks aren't part of it is incorrect.
But if you skip the looks in your design, you'll end up with a product that works worse. It may not look rational, but then humans do not have a 100% rational behaviour.
Any product designer is expected to be knowledgeable about both visuals and ux. There are huge benefits to having people on the product team that can research, assess and design solutions.
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).
Well yes, and worse, after opening it on a desktop browser, it still looks pretty average, and the way the background brightens as you scroll down is very distracting.
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.
Honestly, I'd just once like to work with a designer that has heard of words longer than 5 letters.
Every. Single. Darn. Design I get completely ignores the fact that the texts inside them won't be built from nice little short words with EXACTLY the correct letter counts (especially when localized).
Which results in shit UIs like one I've just seen on Android where (in my language) the button literally just says "Tap to..." and every single label on a button is truncated and doesn't finish a word.
I agree, but would expand that to all parts of the design dealing with variable data, not just text (think thumbnails, avatars, etc). It’s too common for designs to that were beautiful on the canvas to fall apart once brought to life in the actual product.
Some designers also don’t have a good grip on what’s actually feasible to engineer, adding in various details that in aggregate can bloat the time and effort required to build the design multiple times over.
I always tell ppl to test their designs with German content. Usually the longest words, generally speaking, which breaks a very high % of "first passes" on designs.
> That is OK, if you know the rules you can break them, but often they don't know the rules either
And that's the problem with what I call "dribbble-raised designers" ("designers" of Material UI included): they work for the designs to look nice in static screenshots on presentation pages without much scrutiny, and that's it.
Yo I thought those tweets might be from a few years ago and "they must have resolved those by now"... no, the tweets are literally from TODAY and SIX DAYS AGO. What the hell?! Sad times...
I built a site using Material in 2018. Never again! I have to imagine that Google just leaves it as unmaintained, considering these issues are still happening.
> When there are 5 elements, they follow 5 different guidelines:
Pixel-perfect alignment is not a hard rule. It's only for a list of homogenous items would they need to be aligned perfectly.
But when the elements are heterogenous, as the screenshot in your link refers to, the human brain does weird thing to what we see, and alignment has to be adjusted for it to "look right".
This is particularly well-known in font design, with things like variable ascender height, cap height, and kerning.
>Note that due to optical illusion, round and pointed capitals (for instance the O and A) will extend a little above the cap height to make them appear as tall as the flat-topped capitals.
> Label text should be placed within the bounds of the text field box
And I'm perfectly fine with Google spending unreasonable amounts of their money so I can learn lightly-valuable facts like this... As long as people don't mass adopt their findings before they get repeated.
This one, I think, is them just not willing to admit their mistake. I wouldn't be surprised if the experiment went like this: "Here are the inputs with only underline. In one of them the label is inside the input". In this case sure, users will better understand it's an input if the label is inside.
every PM everywhere. They simply cannot leave good enough alone.
Eventually every site A/B tests its way until it becomes Reddit mobile site. No one asked for carousels but sites continue to use them. We are getting inundated with popups today. I don't want to say it's as bad as 1990s flash ad popups. But it's getting damn close now. Bullshit cookie popups. "This site is better on our mobile app" crap popups. Google sign in popup bullshit.[1]
I would say anti-UX and anti-accessibility is very much the point of many sites. "Dark patterns" help conversion and the bottom line. Every site you visit is engaged in psychological warfare with you.
Design is a field where there's no clear 'correct' answer, in a vast sea of opinions. Honestly UI design is surprsingly tame compared to other areas of design (interior, architecture, typography etc). If there's a uni near you, try go to a design critique where work is presented and discussed - it's intense. Debating work is a big part of being a designer.
Strategies to deal with disagreements, frankly a big part of it is being comfortable disagreeing. If you want to get more into design, know they're going to happen, and that there's not a clear answer, and it's not personal. A good designer should know it's about the work and the idea not where or who it came from. Source: am a UI designer.
One of my pet peeves in software development is not doing enough upfront R&D into feature and product design. User feedback is often only collected after the feature has shipped, landed and users are forced to deal with the "upgrade."
It's hard to take subjective matters, such as UI preferences, and draw objective conclusions from them ... but it can at least be done in the aggregate. Before "SaaS" took over software (and made modern computing mostly unappealing to me as an end-user), companies would have to spend quite a bit of resources doing focus groups and "beta testing" before that big product release. End users could be divided into the "early adopters" and the "review watchers", the latter group choosing to wait and decide whether or not it's worth "upgrading."
There is no reason that feature and product design in software can't go through an R&D phase except for cost. It's often cheaper to do your R&D in-house even though it often misses the mark because "real" customers rarely use a product like those who are intimately familiar with all of its quirks and oddities.
So, while you're correct that accessibility, usability and aesthetics will often vary from individual to individual ... I still think that companies could arrive at an objectively "right", or at least "best" design if they bothered to do more upfront R&D; soliciting user feedback and data from "real" end users very early on in the design and development process. Doesn't mean you will please everyone, but you can at least maximize the number of end users who are satisfied.
Hard agree. I've worked with specialised user researchers before and holy shit they're good. I've never ever once thought doing research was a waste of time. It's so worth the money.
It's just really easy to get trapped in your own biases - often the bias of "This isn't that complicated, I understand it so the customer can too", and the "I know what they want" one. So in the face of 'we need to deliver fast', a lot of people won't take the time to invest in it.
If anyones interested in research methods, highly reccomend this book.
I don't have any strategies, but I've had designers also want to add unnecessary steps to a gui-driven process. One designer kept arguing about the cognitive load of having a user simply insert their credit card into the reader to signal intent to pay. They wanted a flow where the user would touch the UI to indicate whether they wanted to tap or insert or scan a coupon. There was no reason to do it that way. I don't want to get into the specifics but it's a flow everyone uses every day without thinking and we were adding a new input device. It's not like we were inventing an entirely new system. The designer just wanted to make the work more than it was.
This could be tested with usability studies and a good user researcher. Make a prototype of the 'fast' way, and the 'lower cognitive load' way. Try it with 15 people per prototype, track metrics, and ask people about the experience afterwards. Make sure everyone on the team has an open mind and see what sticks.
Our "usability study" is the tens or hundreds of thousands of people who use our UI entirely without issue every day. Market validation is better than any usability study you could pay for.
That was exactly what the designer was trying to do. We kept telling her "people tell us what they want by presenting their method of payment." And she kept sending us articles about cognitive load for some reason. I just don't think she had any of the domain knowledge she needed to understand why that was a bad idea, and she didn't take the time to get it either before arguing with us.
The solution is to hire better designers, unfortunately. Savvy/wise/experienced ones know when to follow the rules, and when to break them.
Edit: That might not seem like the most helpful advice, and I'm sorry you have to deal with this – but it's the most effective, without having to write an entire book.
This book was written for industrial designers by an industrial designer, but I did find a lot of useful advice in here for designers on understanding the business mind, deferring to clients, embracing constraints and requirements, etc.
I think you deal with bad designers the same way you deal with bad developers.
Try not to hire them in the first place, fire them if you can, and if you're stuck with them try to make sure they are occupied with tasks that will not cause too much overall damage.
The horror stories I hear are usually when a Graphic Designer is given the role of a UX/UI designer. There is nothing that is going to quickly fix that situation other than getting them some much needed education and mentorship.
or use "ugly arm" method (I don't know if this is the correct English name of this). Ir, show to they two options. First a obviously ugly option that nobody would use. Then, show your desired option. They would use your desired option, perhaps with some minor changes, and they feel that did something.
Not quite the same thing but I've heard of people putting "A Duck" in their designs, which is a superfluous design element that is included solely for the purpose of letting a micromanaging superior remove it so that they can feel like they contributed to the design.
https://blog.codinghorror.com/new-programming-jargon/
But whether it's a duck, anchor, strawman, whatever you call it -- the risk with proposing an obviously bad solution to make the good solutions look better is that every once in a while they'll pick the bad solution. I think it was a talk by Mike Monteiro where he explicitly cautioned against using this approach because it tends to backfire hilariously at the worst possible moment.
> 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.
One option would be to use a premade design system or a component library/framework that gives you a consistent look and feel, most of those design decisions having a good enough baseline. Then just add a color theme and some branding on top of it and call it a day. It will also increase your development velocity and save you from some pixel pushing.
They have working components that are good enough (and support multiple themes, if need be), their own icon solution and also a CSS utility library, including stuff like layouts. For most projects it'll be enough to create something that works and looks okay.
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.
They used the same type of border over the first example, of course it doesn’t work. It’s “our genius design vs average nonexistent nonsense” type of move. Make table/list grid less pronounced, make the selection hint more saturated than a field bg, and now it looks better than #2.
Their selection looks like a hover hint in both cases as if they were afraid to tell a user that a row may have a selection on it.
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)
> How do you know when there is content to scroll then? You randomly scroll parts of the screen to see if they move?
Sometimes, but more often I press on page down to read more content until there's no more content to read, so having scrollbar is pointless: it eats screen real estate without providing anything in return
I loathe things "magically" disappearing and reappearing. I want a predictable, consistent interface. I can work faster when things are consistent. Scrollbars, besides allowing me to jump around in a document, give me an indication of where I am on the page. When I ask, "How much of this page/window/document is left? About where am I in it?" (a common question) the answer should be RIGHT THERE and not unhelpfully hidden/unavailable or difficult to see. I shouldn't have to waste time fighting to find out.
> I loathe things "magically" disappearing and reappearing. I want a predictable, consistent interface.
I do not want the trackbar to magically disappear. I want it gone for good, unless I ask for it, which is predictable and consistent.
> I can work faster when things are consistent. Scrollbars, besides allowing me to jump around in a document, give me an indication of where I am on the page.
I work faster with a good concentration, which is helped by a lack of UI clutter (FYI I use my browser in fullscreen mode because I find buttons and tabs distracting)
Hitting the touchscreen, doing a gesture on the trackpad (or the trackpoint), or pressing pageup then pagedown gives me context when I need it and if I need it.
The rest of time, I don't want no scrollbar.
> When I ask, "How much of this page/window/document is left? About where am I in it?" (a common question) the answer should be RIGHT THERE and not unhelpfully hidden/unavailable or difficult to see. I shouldn't have to waste time fighting to find out.
When I do any of the above, the scrollbar is here. The rest of the time, I shouldn't have to waste my concentration on a useless indicator nagging me on the right side of the screen.
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 miss those days... Everything now takes countable seconds to load or do anything... I'm running a 3090 with a decent processor, and 32GB of RAM yet even some of the simplest things take so long anymore.
I miss those ugly forms days specifically too haha I personally prefer UX over any amount of design so I remember being so disappointed when Microsoft started introducing everyone to the concept of flat layouts that don't differentiate sections and just generally don't even look conceptually usable half the time. Give me ugly fast forms over looks any day.
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.
I don't have to, and I'm not going to because it looks like crap. Why is "Cancel" just a word instead of a button? And while "Invite" is marginally better, a rounded rectangle is not much of a button either and doesn't immediately signify "oh, I can click this".
I know some people prefer flat and featureless design (and there are jokes we could make about that), but that is very personal and tastes can vary widely.
Though in the interests of fairness I will admit that there are people who do feel that kind of thing looks good.
That problem exists in both versions though - i.e. making it more "beautiful" hasn't obviously affected the usability. But I can see at least one way in which it could - if shown on a wide screen and there were a lot of entries, matching up the "Team"/"Member" signifier with the contact name would be quite challenging. The lines in the orginal version may look a little clunky but do serve a purpose.
Styling to make it look like a button which is jutting out would signify the option for interaction to anyone who's ever seen a device with physical buttons, like a keyboard, smartphone, television, remote control,...
There already exists a convention of visual treatment to establish the appropriate expectation and differentiate items that actually do something in the event of a click on them, and it's the one specified in the comment you replied to. HTH!
Everyone knows how a button looks, and in case you’re sure that that is a button, I invite you to explain every flat ui to my older relatives, using only words.
I have trouble distinguishing the two as an unusable design is usually automatically worse for me but you're not wrong in making the distinction that they specified beautiful. I guess I wish people would choose functional/usable over beautiful or merge them in a way that doesn't sacrifice the one I find more important!
To be fair, I also just generally don't like the look of it without borders and stuff.
> 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"
The line between "an advanced, niche concept" and "common sense" is very blurry. It's continuous, not discrete. What you think it common sense is probably not for a considerable proportion of other people.
Regarding the actual topic at hand though, I actually do agree with you (hence disagree with OP), since I do believe that mastering concepts like color theory and typography are indeed extremely low on the extensive priority list of things to master to create great UIs.
I've been building them, and convinced people to pay me quite handsomely for them, for quite a considerable amount of time, and never have I had to deep-dive into typography, color theory, or the like.
Well, color theory is a vast topic, especially when it comes to color reproduction and so on, but for UI design this is of lesser concern. However, basic stuff like the color wheel, complementary colors, perception of colors in terms of perceived contrast, "signaling" colors, knowledge of optical illusions etc. is pretty much 101 knowledge of anyone who wants to create really good designs. There are many traps you can fall into if you ignore this kind of knowledge. This goes even further with the entire field of cognitive psychology dealing with such things.
Typography also plays parts in human facing design, like being able to discern I and l and other such things. You may get by without all that, but I have seen too many cases of broken stuff, and that website from the OP is a big mess, pretty much counterexample of what I call "good design".
The contrast ratio for the body text is 7.57:1 (or 7.25:1 if the text is on the light grey background), which meets AAA accessibility standards (which is 7:1).
Body text isn't the issue I would think - it's various headers, downvoted and especially "dead" posts which are almost to read without selecting the text, even with perfect colour vision.
This is also in part because of human perception, i.e. it wouldn't be as bad if the rest of the page had the same level of gray for the text. Because it is not the case the darker parts suck your focus in. If you want people to actually read your text, that is a pretty stupid move and just shows how serious you can take all that spam on this page.
The only UI/UX newsletter I subscribe to[0] also has a a similar problem, but the advice is usually solid. Maybe the first and/or last rule should be ‘seek feedback’.
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?
I thought the same thing. As ugly as all those "WinForms"-esque 90s applications were, they presented dense amounts of information in a usable way, provided you had time to learn the application.
And the time it took was probably shorter, since you could just poke around menus full of text that says what the damn thing does, that might open modals or dialog boxes full of buttons that do what they say on the damn button, and icons that gasp, might have had text labels indicating what they do! You could hop in and if your task was reasonably simple, just hop the menus and click on stuff and see if it was what you needed.
But no, here's a smear of low contrast grey with some tiny, grey, unlabeled hieroglyphics for buttons/icons, isn't it nice? It's so clean! So pretty! So lacking in discoverability!
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.
You've basically just answered "with a brush" to the question "how do you think I should paint my wall". True, but irrelevant. You can make a ugly, unusable UIs with your listed frameworks. You can make amazing, smooth UIs with plain HTML+CSS.
> just a matter of actually thinking about how people will use the app
What I learned during my professional career is that this is exactly what 80% of engineers are absolutely incapable of. Do belong to the 20% and hit the jackpot.
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.
3) don't reply to threads obviously created with the intention of promoting some costly product, promising to surpass specialized knowledge, just by spending a few bucks.
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.
I definitely agree with this and I think it partly comes down to the fact that product design is always a negotiation between many concerns – all the interface pieces on the view, patterns across views, user expectations, user research, dev LOE, etc. etc. In many ways it's the art of the possible; I say UX is harm reduction b/c there's never a perfect solution for any problem. Work like this is very subjective and always a lot about "feel".
Seconded the Tufte books, especially to learn about the principles of visual communication. Though as a fan who has all his books and attended multiple lectures, I have to admit that his forays into interaction design were... underwhelming.
A pdf that seems to contain "high quality" examples like "use fewer borders" where the example made several commenters, including myself, say "That's worse." Not sure why I'd pay $100 for a PDF anyway but I'm sure as heck not doing it when the kind of advice breeds less usable pages.
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.
In many cases I like busy and cluttered; I enjoy https://dofsimulator.net/ , I use gmail in "compact" mode, etc.
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.
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.
I disagree on the aesthetics. Borders make it look nice and good. When in doubt, add another border.
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.
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.
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.
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.
Are you memeing or are you serious? Because I'm curious how you'd have a language model design a page for you. Just ask it for the HTML and CSS for a nice looking page?
ChatGPT is extremely good at writing HTML and CSS, yes - if you have a basic idea about what you want it to look like the bot can do the rest, including iterate on it.
It's weird what works. Eventually I asked it for just the body element in its response which categorically fixed the problem. I wish we could presence-penalty single tokens so it wasn't all so abstract.
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/