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're trying to do.
In the case of the article: Sure, I read the article, because I wanted to read the article. But notice I didn't read the titlebar, the subtitle, the author, the nav, the footer, the newsletter subscription form...
Someone reading copy probably wants to know something about your product. Depending on what they want to know, they might skim around the page looking for the most relevant thing – for instance, looking for a header named "Specs" when trying to find battery life.
Making your copy shorter will certainly make that task easier and save their time, and it'll probably make it less likely that they'll decide they didn't want to know things about your product that much.
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.
I also go to pre-release media screeners of movies - you wait in line for a while, and you get to see a movie a few days earlier.
Anyway, the most recent movie pass (Detective Pokemon, really good by the way) had some red text in the middle. You had to redeem the pass for tickets at the theater before the screening, not wait in line. A LOT of people, including my movie buddy, did not read that red text.
If you depend on your users to read something, you will be let down very often. If you depend on your users to read, you should back that up with some check.
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 interfaces. That is all great. The problem is that 99% of the time that the term "UX" shows up in connection with something I use, two things are going to happen:
1) I will have to relearn how to do something that I already was used to doing without even thinking;
2) Some feature or option is going to be removed.
The human brain is incredibly plastic and adaptable. Unless the interface is truly absurd, most people can get used to it and never give it a second thought again.
My number one (by far) request as a user:
DON'T FUCKING CHANGE THE INTERFACE
Unless there is a very good reason, and I bet there isn't.
I bought my first MacBook in 2007. Thankfully, Apple is one of the best behaved companies when it comes to not changing things for the sake of it, and part of the reason why I stick with them. I don't mention this out of some sort of fanboy-ism (I have no loyalty to corporations, I just buy shit I like). I mention it to make a more important point:
The UX of 2007 was absolutely fine, and if they would have made zero changes since then I would be perfectly happy. UX for laptops/desktops was solved in the early 2000. Everything else since then is just irrelevant bullshit.
This is not true: "The human brain is incredibly plastic and adaptable. Unless the interface is truly absurd, most people can get used to it and never give it a second thought again."
I've interviewed and observed enough users to know this is not true. There are a lot of interfaces that are suffer from issues with discoverability and understanding, and even when a user figures this stuff out one time (or is showed it), the interface is not memorable.
One huge mistake you are making is that you are a power user. You probably use computers more than most people and understand interfaces and paradigms better than most people. I implore you to actually observe real users using real products.
> There are a lot of interfaces that are suffer from issues with discoverability and understanding, and even when a user figures this stuff out one time (or is showed it), the interface is not memorable.
Oh, dear, God, yes.
The "hamburger menu" is one of the worst travesties of the modern age.
UX for laptops/desktops was solved in the early 2000.
In the early 2000, my music library was a few dozens GBs played back using mpeg123 or something. Nowadays it’s a Google Play Music subscription. Things have moved to the cloud, a lot. That’s a huge change in how computers work, requiring some serious UX changes. I too hate gratuitous UI changes, but things need to keep evolving.
Spotify and Google Play Music are a kind of worse version of UI of Foobar2000, with much limited features. There was a huge UX regression coming with the move to the cloud. I'm all for things evolving, but it's better if they don't devolve.
> I too hate gratuitous UI changes, but things need to keep evolving.
That's devolution in multiple ways. Your app is now tied to your subscription so there's no competition for best music app. The apps are now high latency bandwidth hogs that require a network connection. Your now held to ransom, stop paying us and you lose your entire music collection.
> I too hate gratuitous UI changes, but things need to keep evolving.
Do they? Once something is a tool that meets a need, should the default assumption be that any change can be justified by vague appeals to "evolving", or should there be some specific and defensible justification required beforehand?
In the 1950s, cars were made of steel and essentially designed to survive impacts by sacrificing the passengers. These days, they're identical fiberglass mice which fold up into a protective cocoon around their passengers on impact. You know how people drove cars in the 1950s? Steering wheels and some number of pedals. You know how people drive cars now? By calling an Uber, the drivers of which use steering wheels and some number of pedals.
So... why hasn't the fundamental UX of the automobile evolved in the past half-century?
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...
> DON'T FUCKING CHANGE THE INTERFACE
>
> Unless there is a very good reason, and I bet there isn't.
>
> I bought my first MacBook in 2007.
Apple changed one of the most common operations: double-clicking a folder to open it now (a) opens in the parent folder's window, and (b) rearranges the folder contents which I have carefully arranged for my own particular use of that particular folder ARRRRGGGGG.
They could at least have put an option somewhere for "Open folders the old way," but didn't.
Cmd-double-click does it the old way... unlike double-clicking on any other thing in the UI.
As a like-/counter-anecdote, I developed semiconductor CAD tools for 10 years, after spending 10 years using them. When they first started being developed with GUIs, GUI meant UI, and its oft-maligned sibling, UX, wasn't a term. In my learnings, Xt (XToolKit) started putting words and code behind the abstract patterns in the late 80's, but our tool usability suffered horribly as more and more (usually nonresizing) Athena widgets were crammed into every goddamn corner of the screen with microscopic b&w pixmaps. Because of the lack of distinction between UI & UX in the tool design process, tools were extremely challenging to navigate with each new feature-rich release.
One of my first tasks as a project manager in 2004 was to introduce the web concepts of UI/UX into what had become essentially commandlines converted to Tcl/Tk (after Xt we went to Tcl/Tk.. ugh).
First challenge was to convince the old timer CAD devs.
Once I was able to explain there the difference between UX and UI, it waslike a light went on over everyone's head: how you use it is different from what it looks like. I know, obvious now, but not 15 years ago. We spent 10 months really driving the new buzzword UX/UI in order to get buy-in for profiling how the top 3 existing CAD tools (formal verification, layout, and timing) were being used via instrumentation and interviews. We then proceeded to completely redesign the GUIs in Qt using a consistent set patterns, icons, and workflows.
Then we had to convince the old timer engineer users.
We put a lot of effort into classes to explain how to migrate, and holy shit did we get yelled at. So much "It worked fine before, why did you change it?!?!?!?" Uhh... because a feature you use 80% of the time required 5x more clicks to get to than a feature you used 20% of the time? FML. It got better, people liked it more on our follow ups months later. [The first product to use the new suite completed in 12 instead of 18 months and I personally believe it was due to the new tools being faster, but I'm biased, and it could have been a variety of factors.]
I agree with your point that it is frustrating as fuck when a UI/UX pattern changes, and it should not be done glibly. But I have also found myself getting angry at having to adapt to a new change that ultimately made me more productive, just because of my own inertia.
/shrugs/
PS. Ironically, as a sad end to this story: the GUI's my team made in the early/mid-2000's eventually bloated after 10 years in almost the same way the original AIX/Sparc GUI's I used in the early 90's did. New coders came on board, and new managers, and they just crammed new buttons into to the tools without thinking about the UX. That was ca 2010 when I left, so I don't know where they at today, but I did have a "the more the things change, the more they stay the same" moment!!
Fascinating! As somebody who uses that kind of software, old timer electrical engineers seem to be very very unforgiving to UI problems and even more unforgiving to any change for better or worse. I learned that while volunteering for UI/UX at horizon-EDA which aims to become a more usable kiCAD¹
I have never seen worse UX/UI than in electrical engineering tools and I worked a lot with 3D software. They are completely inconsistent with other software, often even with themselves. It often resembles the heating room of a 500 year old building were everybody added things but nobody deared to clean up the things that were already there.
My suffering as a user of such tools motivated me to change things for the better. I never got the idea behind resisting change in UI/UX. It seems to be rooted in the believe that change in UX always means change for the worse and never for good. Which is weird, because even someone like a carpenter is very much interested in the usability of their own tools.
Maybe the problem is that each change in the software means they have to adapt and this demands a certain adaptability, or a will to stay on top in a changing world. It certainly costs energy to do that.
> So much "It worked fine before, why did you change it?!?!?!?" Uhh... because a feature you use 80% of the time required 5x more clicks to get to than a feature you used 20% of the time? FML.
Well, they're not wrong because every other CAD tool simply rearranged the UI for no reason.
In addition, the problem with semiconductor CAD tools is that any feature which isn't used by everybody is effectively broken because it has zero users, to an engineering approximation. I wish my CAD tools had a "CAUTION: this feature was used N times in the last 180 days by all users of the tool where N < 10. Expect bugs".
Although, in terms of UX I've never understood why CAD tools don't use Pie menus--games adopted them eons ago. (Fusion 360 is the exception, and it's a wonderful breath of fresh air).
I'm really curious where you worked now, as I don't remember any of my VLSI CAD tools getting an effective UI makeover (and we used a lot of them). Although I'm pretty sure we skipped most Mentor tools.
> UX for laptops/desktops was solved in the early 2000. Everything else since then is just irrelevant bullshit.
Couldnt agree more. And yes this is part of also why i like using macOS. Things get changed for a reason - I may not agree but at least it is 'reason-able' changes.
had a good chuckle reading the OP article - some parts read like it was an article in TheOnion or a weekly read from The Register they were so funny.
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 dicking around with the design -- the content is what matters" or "it doesn't matter how beautiful it is if no one cares about you're saying."
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.
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. Then, try to solve them with the least amount of design possible.
“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 design industry is a shell of its former self. The homogeneous nature of modern web products is concerning, but it makes sense unfortunately.
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.
Ah, I think this is a bit simplistic, as it leaves out testing, which is critically important.
Too many UX people don't follow or even know what a proper user-centered design process looks like. Talking to users and looking at data is a lot of it. Testing is another critical component.
The other big part is to be methodical with how you do ideation, design, and prototyping.
Testing is important, absolutely. But it too can be summarized with exactly those two points. It’s part of the same cycle. The proper way to test anything is to launch it, talk to users.. and look at your data.
- 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 be tested?
This is the danger of dumb rules like this. Nothing's universally true. Part of what an engineer is paid for is knowing what should be tested to what extent.
You don’t necessarily need automated tests, but you absolutely do need to test your tests. With any new test, I always verify that 1) it passes with the fix 2) it fails without the fix. Many programmers skip step 2 and it’s a good way to end up with tests that don’t test what you think they do.
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’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?
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?"
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?
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.
> if your code isn't important enough to be tested, it's not important to be written
The majority of code that delivers this page to you (web server, OS's, browser, networks, drivers) in a readable way has no unit tests and most of it has very little QA. Presumably you think you shouldn't be able to read this page?
> every function must fit a single screen
A policy by assholes that don't do maintenance. Diving through a million little functions is a lot harder than fewer bigger ones (up to a point). Parroting this show a complete lack of understanding of why long functions can be bad, it's the state not the scrolling.
“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 and power people needed in useful form.
And I was going to say he delivered on that. Except now the horse poops carbon monoxide and eats gasoline instead of oats. But while cars also don't live forever except with great care, they do at least have a longer lifespan than a horse.
It's true. Asking users what they want is not that useful. Users don't know what they want and any suggestion they make probably won't scale to others.
On the other hand, understanding your users, how they work, what they hate, what their pain points are is incredibly useful.
Do those people think Ford invented motor vehicles? Before the Ford Motor Company ever existed we had a motion film of a trip to the moon, and they didn't go by horse!
Thanks for putting this into perspective, I'm going to start using this fact to refute this tired, cliche saying.
I think there is a particular book that tech company managers read where they are indoctrinated with this Henry Ford saying, anyone know what book it is?
Hand crafted artisanal RSS feeds. Each character of text and markup and every URL laboriously typed into Notepad as raw XML, without the use of copy-and-paste. Sorry if it doesn't validate!
My favourite business cliche is a diagram with three or four things in a circle.
I thought about it so much I know think the circular process is an inevitable consequence of reality. Still, the business ones are usually pretty vacuuous.
Readit News
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're trying to do.
In the case of the article: Sure, I read the article, because I wanted to read the article. But notice I didn't read the titlebar, the subtitle, the author, the nav, the footer, the newsletter subscription form...
Someone reading copy probably wants to know something about your product. Depending on what they want to know, they might skim around the page looking for the most relevant thing – for instance, looking for a header named "Specs" when trying to find battery life.
Making your copy shorter will certainly make that task easier and save their time, and it'll probably make it less likely that they'll decide they didn't want to know things about your product that much.
Though to be fair I didn't make it that far because the counterarguments to the cliches were not particularly deep or convincing.
I work on software, I read a lot.
I also go to pre-release media screeners of movies - you wait in line for a while, and you get to see a movie a few days earlier.
Anyway, the most recent movie pass (Detective Pokemon, really good by the way) had some red text in the middle. You had to redeem the pass for tickets at the theater before the screening, not wait in line. A LOT of people, including my movie buddy, did not read that red text.
If you depend on your users to read something, you will be let down very often. If you depend on your users to read, you should back that up with some check.
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 interfaces. That is all great. The problem is that 99% of the time that the term "UX" shows up in connection with something I use, two things are going to happen:
1) I will have to relearn how to do something that I already was used to doing without even thinking;
2) Some feature or option is going to be removed.
The human brain is incredibly plastic and adaptable. Unless the interface is truly absurd, most people can get used to it and never give it a second thought again.
My number one (by far) request as a user:
DON'T FUCKING CHANGE THE INTERFACE
Unless there is a very good reason, and I bet there isn't.
I bought my first MacBook in 2007. Thankfully, Apple is one of the best behaved companies when it comes to not changing things for the sake of it, and part of the reason why I stick with them. I don't mention this out of some sort of fanboy-ism (I have no loyalty to corporations, I just buy shit I like). I mention it to make a more important point:
The UX of 2007 was absolutely fine, and if they would have made zero changes since then I would be perfectly happy. UX for laptops/desktops was solved in the early 2000. Everything else since then is just irrelevant bullshit.
I've interviewed and observed enough users to know this is not true. There are a lot of interfaces that are suffer from issues with discoverability and understanding, and even when a user figures this stuff out one time (or is showed it), the interface is not memorable.
I put together a list of guidelines for thoughtful product design. Most products don't meet all of these. Really good design is hard work: https://uxdesign.cc/guidelines-for-thoughtful-product-design...
One huge mistake you are making is that you are a power user. You probably use computers more than most people and understand interfaces and paradigms better than most people. I implore you to actually observe real users using real products.
Oh, dear, God, yes.
The "hamburger menu" is one of the worst travesties of the modern age.
Earn my trust before asking me to get into bed with you.
This x100.
In the early 2000, my music library was a few dozens GBs played back using mpeg123 or something. Nowadays it’s a Google Play Music subscription. Things have moved to the cloud, a lot. That’s a huge change in how computers work, requiring some serious UX changes. I too hate gratuitous UI changes, but things need to keep evolving.
That's devolution in multiple ways. Your app is now tied to your subscription so there's no competition for best music app. The apps are now high latency bandwidth hogs that require a network connection. Your now held to ransom, stop paying us and you lose your entire music collection.
Do they? Once something is a tool that meets a need, should the default assumption be that any change can be justified by vague appeals to "evolving", or should there be some specific and defensible justification required beforehand?
So... why hasn't the fundamental UX of the automobile evolved in the past half-century?
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...
Apple changed one of the most common operations: double-clicking a folder to open it now (a) opens in the parent folder's window, and (b) rearranges the folder contents which I have carefully arranged for my own particular use of that particular folder ARRRRGGGGG.
They could at least have put an option somewhere for "Open folders the old way," but didn't.
Cmd-double-click does it the old way... unlike double-clicking on any other thing in the UI.
One of my first tasks as a project manager in 2004 was to introduce the web concepts of UI/UX into what had become essentially commandlines converted to Tcl/Tk (after Xt we went to Tcl/Tk.. ugh).
First challenge was to convince the old timer CAD devs.
Once I was able to explain there the difference between UX and UI, it waslike a light went on over everyone's head: how you use it is different from what it looks like. I know, obvious now, but not 15 years ago. We spent 10 months really driving the new buzzword UX/UI in order to get buy-in for profiling how the top 3 existing CAD tools (formal verification, layout, and timing) were being used via instrumentation and interviews. We then proceeded to completely redesign the GUIs in Qt using a consistent set patterns, icons, and workflows.
Then we had to convince the old timer engineer users.
We put a lot of effort into classes to explain how to migrate, and holy shit did we get yelled at. So much "It worked fine before, why did you change it?!?!?!?" Uhh... because a feature you use 80% of the time required 5x more clicks to get to than a feature you used 20% of the time? FML. It got better, people liked it more on our follow ups months later. [The first product to use the new suite completed in 12 instead of 18 months and I personally believe it was due to the new tools being faster, but I'm biased, and it could have been a variety of factors.]
I agree with your point that it is frustrating as fuck when a UI/UX pattern changes, and it should not be done glibly. But I have also found myself getting angry at having to adapt to a new change that ultimately made me more productive, just because of my own inertia.
/shrugs/
PS. Ironically, as a sad end to this story: the GUI's my team made in the early/mid-2000's eventually bloated after 10 years in almost the same way the original AIX/Sparc GUI's I used in the early 90's did. New coders came on board, and new managers, and they just crammed new buttons into to the tools without thinking about the UX. That was ca 2010 when I left, so I don't know where they at today, but I did have a "the more the things change, the more they stay the same" moment!!
I have never seen worse UX/UI than in electrical engineering tools and I worked a lot with 3D software. They are completely inconsistent with other software, often even with themselves. It often resembles the heating room of a 500 year old building were everybody added things but nobody deared to clean up the things that were already there.
My suffering as a user of such tools motivated me to change things for the better. I never got the idea behind resisting change in UI/UX. It seems to be rooted in the believe that change in UX always means change for the worse and never for good. Which is weird, because even someone like a carpenter is very much interested in the usability of their own tools.
Maybe the problem is that each change in the software means they have to adapt and this demands a certain adaptability, or a will to stay on top in a changing world. It certainly costs energy to do that.
--- ¹: Check it out here: https://github.com/carrotIndustries/horizon or watch the FOSDEM19 talk:https://www.youtube.com/watch?v=13xmFwgikh8
It is quite usable already, but there is no 1.0 release yet so useful things like installers and documentation are still lacking.
Well, they're not wrong because every other CAD tool simply rearranged the UI for no reason.
In addition, the problem with semiconductor CAD tools is that any feature which isn't used by everybody is effectively broken because it has zero users, to an engineering approximation. I wish my CAD tools had a "CAUTION: this feature was used N times in the last 180 days by all users of the tool where N < 10. Expect bugs".
Although, in terms of UX I've never understood why CAD tools don't use Pie menus--games adopted them eons ago. (Fusion 360 is the exception, and it's a wonderful breath of fresh air).
I'm really curious where you worked now, as I don't remember any of my VLSI CAD tools getting an effective UI makeover (and we used a lot of them). Although I'm pretty sure we skipped most Mentor tools.
Couldnt agree more. And yes this is part of also why i like using macOS. Things get changed for a reason - I may not agree but at least it is 'reason-able' changes.
had a good chuckle reading the OP article - some parts read like it was an article in TheOnion or a weekly read from The Register they were so funny.
That's why it's important to have good UX people to help you get it mostly right the first time
> Touchbar
Dead Comment
Deleted Comment
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 dicking around with the design -- the content is what matters" or "it doesn't matter how beautiful it is if no one cares about you're saying."
Except good satire uses exaggeration to lampoon things that are (at least partially) true in reality.
Whereas for half the examples here my reaction was, "No one has ever said that for that reason."
Good satire is a form of pointed commentary. If you use it to say , "I didn't mean any of what I wrote", then you defeat the purpose of it.
It could also be good old fashioned regular satire, too...
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.
# 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. Then, try to solve them with the least amount of design possible.
Repeat.
Which should give you some indication why the design industry is a shell of its former self. The homogeneous nature of modern web products is concerning, but it makes sense unfortunately.
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.
Too many UX people don't follow or even know what a proper user-centered design process looks like. Talking to users and looking at data is a lot of it. Testing is another critical component.
The other big part is to be methodical with how you do ideation, design, and prototyping.
- if your code isn't important enough to be tested, it's not important to be written
- every function must fit a single screen
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 be tested?
The problem is that, like all other cliches, it sounds very convincing and it may take quite some time for the young inexperienced mind to rebuff it.
The tests of the tests is your original code. They are testing each other.
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
The majority of code that delivers this page to you (web server, OS's, browser, networks, drivers) in a readable way has no unit tests and most of it has very little QA. Presumably you think you shouldn't be able to read this page?
> every function must fit a single screen
A policy by assholes that don't do maintenance. Diving through a million little functions is a lot harder than fewer bigger ones (up to a point). Parroting this show a complete lack of understanding of why long functions can be bad, it's the state not the scrolling.
Imperative languages are the best match for the underlying hardware
Use the right tool for the job
A language is just another tool in your toolbox
Dead Comment
“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.
Didn't a cow start the Great Chicago Fire?
I don't buy that, many people probably would have said that they wanted a horse that doesn't poop
And I was going to say he delivered on that. Except now the horse poops carbon monoxide and eats gasoline instead of oats. But while cars also don't live forever except with great care, they do at least have a longer lifespan than a horse.
On the other hand, understanding your users, how they work, what they hate, what their pain points are is incredibly useful.
I think there is a particular book that tech company managers read where they are indoctrinated with this Henry Ford saying, anyone know what book it is?
A carefully curated collection of resources
Translation: a list of links
Even better if you can shoehorn “hand-picked” in there (A hand-picked collection of curated resources to help you learn [technology])
Presumably the hand-picked links are always preferable over the, er, robot-picked ones.
I wonder what a real museum curator must make of it all (I presume they don’t really care).
I thought about it so much I know think the circular process is an inevitable consequence of reality. Still, the business ones are usually pretty vacuuous.