Live data from Hacker News

UX clichés

uxdesign.cc

91–100 of 172 posts

Re: UX clichés

#91
post #79

While running a UX/UI design studio for B2B SaaS companies for 10+ years - I’ve seen the UX space evolve into a cult like crowd of designers with too many “gurus” and design research methodologies. Really, all you have to do is 2 things: # talk to your users. # look at your data/analytics It’s really not rocket science. These two metrics will take you minutes to find UX problems and opportunities in your product. The…

“UX” should go away. What everyone calls UX is just proper UI design. Too often the term “UX” is put on this pedestal. It’s thought of as more important or cerebral than visual design. The problem with that thinking is that UX _is_ very obviously visual. Those that try to distance UX and visual UI design often have terrible aesthetic taste and lack any creative skill. Which should give you some indication why the des…

I find your comment very similar in tone as the article: someone who is a interface designer that has had bad experiences with UX designers.

I think this is unfortunate, because I think UX design just a definition of the process that product (digital or physical) design was already doing, and now there is a common (though still evolving) language to be able to communicate the challenges of the full product design lifecycle.

To me UX is the superset for user centered design and User Interface design is a subset of it. They are both important. UX is not UI because they are not comparisons, but parts of the same thing.

Those are my thoughts and experiences at least.

Re: UX clichés

#93

I am not a designer nor a software engineer, nor a business person. I am just a (heavy) user of all sorts of software for a very long time. I am a competent coder, and I code for research and pleasure. I don't have a dog in this, let's say, professional race. Every time I spot "UX" in relation to something I use, I cringe. Not because I have anything against the idea of design, or good interfaces, or designing good i…

There are a few reasons -

The move to webapps meant that each app had to decide how their buttons would look like, what colors, fonts, and contrasts they’d use, how their workflows to do very similar things would be structured; when things were on the desktop the OS UI elements made all the decisions for you - it was the same gray buttons with black text in the same font on every app - the only difference would be whether the buttons were above or below the textbox...

Another reason is that apps need to look and behave roughly like what’s currently “in trend”, as users spend the majority of their time on the big players’ apps, and not “keeping up” will make your app seem outdated and untrustworthy; ie skeuomorphism was the thing when iOS first caught on, and then everyone had to make everything flat when material design caught on...

Re: UX clichés

#94
post #14

Earlier quoted context omitted.

- 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…

One finds a truly surprising number of bugs in tests and test frameworks. So yes, your tests need tests.

A classic case of this bug is "I don't think this test case is doing what you think it is doing". I've produced my share of test cases that were elaborate duds.

Re: UX clichés

#95
It seems fitting that I had to enable reader mode to be able to read a blog post about UX cliches.

Re: UX clichés

#96

My favorite “If Henry Ford had asked people what they wanted, they would have told him faster horses” Used as a counter-argument to the previous statement, when you start to realize you won’t have time or money to do enough user research.

Come to think of it, if Henry Ford could , he probably would design a faster horse. The idea would have a lot of both business and practical sense - it would be improving a known tool, necessary infrastructure and network of services already existed, zero fire hazard, self-driving of level 4 autonomy out of the box. He (and people before him) designed automobiles, because that was the only way we could get the speed…

>zero fire hazard

Didn't a cow start the Great Chicago Fire?

Re: UX clichés

#97
post #22

Earlier quoted context omitted.

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?"

It can be applied to pretty much anything. In most cases it's quite reasonable (there should be one and only one list of users of the system), but taken to the extreme (there should be only one list of messages your application may ever give to the user) can hinder the development a lot.

I think this appliesmostly to persistently stored data. Redundancy in your data model is dangerous because the copies of the data will eventually get out of sync, resulting in weird bugs. No matter how often and how many transformations you expose the data, make sure that it only exists once deep down in your model.

On one of my last jobs, I had to convince my teammates repeatedly that this is a good idea. I always showed them how this was simpler and more robust, yet a few weeks later, they were about to commit the same design errors.

Re: UX clichés

#98

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

How about fitting functions to the problems they solve, not the screens they're displayed on?

And do you mean a wide screen retina monitor with a tiny font? Or 24x40 Apple ][ screens of FORTH code, where you leave out comments and put everything on one line just to make it fit?

https://donhopkins.com/home/archive/forth/supdup.f

Trying to fit a function on one page is antithetical to so many other much more important goals, like readability and cohesiveness and documentation.

I prefer code that uses white space and blank lines liberally to group and align related things together, and break apart separate steps, with complex calculations broken apart using intermediate results stored in descriptively named variables, and as many comments as necessary, even if it doesn't all fit on one page.

https://donhopkins.com/home/archive/forth/alloc.f

Re: UX clichés

#99
post #48
post #14

Earlier quoted context omitted.

- 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

Always write recursive code. It tests itself!

Re: UX clichés

#100
UX is a by-product of the mess we have made of web development.

We made web development so overly complicated that vast teams are needed for the simple task of showing stuff on a page.

Part of the holdup has been CSS. To build out a responsive layout used to be phenomenally hard. Tim Berners Lee didn't think layout was needed, originally the web was to just link documents that people would open in other programs, so the complexity would have been in those other programs.

Need a spreadsheet? Then you would get the link and open it in your spreadsheet program, not an online Google Docs equivalent with its own special interface.

With the difficulty and lack of tools in CSS it meant that web pages had to be hacks. Along the way cruft such as frameworks came along to make it that bit more possible, but imposing more stuff to learn along the way. Therefore it meant that teams had to get ever more specialist, you could not just have 'webmaster' doing it all.

Things got increasingly siloed. Then this agile nonsense came along to slice and dice projects. This made frontend dev a painting by numbers exercise with designs handed down from on high. Those designs would be done by a designer who by definition did not know HTML, they would be cribbing from other stuff and not acknowledging their sources, meaning that frontend dev was an exercise in reverse engineering whatever was in the PDFs and imagining the way it was supposed to work.

Bringing on a UX person with the bullshit language about personas and other nonsense that went with the job took the dev team even further away from understanding the customer, the task overly specialised.

Along the way we moved to meaningless HTML, back to that early web stuff we were supposed to get away from. Instead of FONT tags in the markup we ended up with these silly divs and non-semantic class names on every element put there for layout hacks.

The thing is that anyone at the coalface of development is assumed to be useless at design, whereas the kiddo out of art school that can't code is assumed to be a genius at it.

If you have done 300 test orders of a checkout then you find the pain points of the process and can fix them (or ignore them). If you just do drawings in Photoshop of how it is supposed to work then you ain't gonna be having these insights.

So rather than trust the dev team and let them make decisions the designs are cast in stone and these UX experts (who can't code) call the shots.

We have developed these huge bloated teams and denied entry to people who want to code with Notepad and FTP. I don't use Notepad and FTP myself, but I don't think that people starting there need to be excluded from the web which should be for everyone.

Luckily a lot has changed.

We now know what works with UX, so there is no point in having a UI bod putting the menu in the bottom right because they need to 'design' something. Or changing the search icon to a pair of spectacles because they are an artist. Those things are now standardised, we have got that.

Equally devs who deliver the deliverables rather than mockups know these things.

Also changed is that browsers are standards compliant. No need to produce static mockups when you can do a mockup in HTML.

Also changed is CSS grid. There is now a layout engine in every browser that does all the things the hacks were needed for. This innovation means that layout is no longer a major job and real content without the useless div and class bloat can be directly styled in a quarter of the time it used to take with clumsy frameworks.

Another change is accessibility. There are laws coming in to make that a thing. So putting these pieces of the puzzle together I hope there soon comes a time when web dev teams get usurped by much smaller and more nimble teams that don't over-complicate the gig and keep it simple. After all web pages don't need to be that hard.

Post reply on HN