Live data from Hacker News

UX clichés

uxdesign.cc

41–50 of 172 posts

Re: UX clichés

#42
post #27

These are overall really accurate depictions of what life in UX is like. I do have a comment on this one: > “Users don’t read” > An overly used argument to convince clients and stakeholders to cut copy length in half. If you made this far to this article, you’re living proof that this statement is untrue. The real principle here is that users don't read anything that doesn't look like it will help them do what they'r…

Honestly I skimmed the first part of the article and then checked the comments. It may be a design cliche, but it may be true. I didn't make it to that part.

Re: UX clichés

#43
I'm feeling that cliches is not the right word. To call something cliche generally means it's over-used, tired, boring, etc.

But the article itself is not saying that. Perhaps maxims or truths, would be better?

Re: UX clichés

#44
post #19
post #16

The quoted aphorisms, in my personal experience, aren't used for the reasons being imputed. It feels like forced satire. For example: > "Content is king" - A pretty strong argument to convince everyone to push the deadline because you haven’t received the content that will go on the page you are designing. I've heard this a lot, but never from a designer trying to push a deadline. It's used to say "stop wasting time…

It feels like forced satire. It could also be good old fashioned regular satire, too...

Could have been, yet isn’t. The first few were accurate and somewhat funny, but it quickly went downhill.

Maybe developers aren’t the audience; we are more factual and concrete whereas designers are usually more driven by emotion. The quotes in the article are not very accurate and seem made up, but the general emotion of “designers be like” is evident. Maybe designers respond to that emotion rather than bother with the accuracy of the anecdotes.

Re: UX clichés

#45
post #19

Earlier quoted context omitted.

It feels like forced satire. It could also be good old fashioned regular satire, too...

Could have been, yet isn’t. The first few were accurate and somewhat funny, but it quickly went downhill. Maybe developers aren’t the audience; we are more factual and concrete whereas designers are usually more driven by emotion. The quotes in the article are not very accurate and seem made up, but the general emotion of “designers be like” is evident. Maybe designers respond to that emotion rather than bother with…

yet isn’t.

You know better than the person who wrote this list, and directly said it in fact is satirical at the conclusion--or is it just a disagreement of what constitutes satire like a few other posters have expressed?

Personally I chuckled and grinned wryly at several moments in the piece, understanding completely where the author was coming from.

Re: UX clichés

#46
post #22

Earlier quoted context omitted.

Everytime my co-worker tries to mention the "Pareto-Principle" (a.k.a. "Please let's not waste time on this, because it's frontend and I don't care about frontend") and "Single Source of Truth" (a.k.a. "let's expose our DB as directly as possible"), my soul barfs.

I always thought single source of truth applied to documentation. It doesn't make sense used in terms of UI or anything beyond "I need info, where do I look?"

I can see it applying to UI when there’s two screens that display parts of the same information but are different due to caching. That’s maddening to an end user and then they don’t know what one to trust. Sometimes the first one is correct, sometimes the second.

Re: UX clichés

#47
post #27

These are overall really accurate depictions of what life in UX is like. I do have a comment on this one: > “Users don’t read” > An overly used argument to convince clients and stakeholders to cut copy length in half. If you made this far to this article, you’re living proof that this statement is untrue. The real principle here is that users don't read anything that doesn't look like it will help them do what they'r…

Honestly I skimmed the first part of the article and then checked the comments. It may be a design cliche, but it may be true. I didn't make it to that part.

That was my first reaction.

Though to be fair I didn't make it that far because the counterarguments to the cliches were not particularly deep or convincing.

Re: UX clichés

#48
post #14

I'd love to see a similar list for software engineering. - if your code isn't important enough to be tested, it's not important to be written - every function must fit a single screen

- if your code isn't important enough to be tested, it's not important to be written Does this rule cover all code? Do your tests, which are code themselves, not need their own tests? If not, what is special about a test that you know it's correct, when there is no faith in in non-test code? Is it possible to write your program entirely out of the special "test" code, so that it's always correct and doesn't need to b…

My tests run during tests, so they automatically have 100% test coverage. :D

Re: UX clichés

#49
post #33

Earlier quoted context omitted.

I’ve used “single source of truth” to explain what I like about Redux/the Elm Architecture. Yeah it shouldn’t mean anything about access or indirection but it’s still a decent idea, no?

Depends on what your designing. If you're working on highly distributed, microservice based backends then single sources of truth can quickly become a serious bottleneck. Check out Event Sourcing if you're not already familiar with it. This is essentially a pattern where each area of your domain maintains its own view of the data it needs through immutable "facts" (events). In this case you could say the source of tr…

Even worse in my case, we are using event sourcing, but the client reads the Eventstore streams indirectly. It's terribly uncomfortable being the only one on a team of 7 who thinks this is terrible.

Re: UX clichés

#50
I like this one:

> UX should be a mindset, not a step in the process

Mostly because it's not a UX-cliché, but a cliché for everything: security, accessibility, UX, localisation, etc.; advocates want them all to be an essential part of the process, but in practice, nobody manages to do all that.

Post reply on HN