I have long believed that the biggest issue here is that engineers and power users generally have a much higher “pain threshold” when it comes to poor or complex UI/UX. They are not always the best people to judge how or if less experienced users will tolerate or adapt to those patterns. It’s fine to have opinions but they must be prepared for them to be challenged. Even better if they can invite others to challenge them, which is essentially what talking to your users achieves.
> engineers and power users generally have a much higher “pain threshold” when it comes to poor or complex UI/UX
I don't think that's entirely accurate. We tolerate steep learning curves if the result is an increase to our power. That's why we are power users.
Vim, for example. Some of us put effort into learning it because it's a powerful and efficient editing language that will enable us to easily accomplish hard things.
Caring about the system itself and being willing to put effort into it are what separates power users from normal users. We don't do this because of masochism, we do it because we want to increase our power.
Normal users want the system to just do what they want without any thinking or effort at all, as though it was a highly specialized tool for their exact task rather than a powerful programmable general purpose computer.
Personally I don't care at all about how "less experienced users will tolerate or adapt". This unceasing focus on the wants and needs of normal users frequently hinders us. Developers typically reduce the complexity and feature set of a piece of software in order to turn it into something a normal user can deal with. We want more power, not less.
Normal users don't really matter unless they are directly paying our salary. We should all favor ourselves unless we're getting paid to focus on someone else.
The two biggest causes of major UI problems I see are:
1) Exactly what you wrote: power users don’t even realize they clicked through five things in ten seconds any one of which would have derailed a weaker user, because they’re so used to bad UI that it’s almost invisible to them.
2) Zero care given to what’s most natural for the platform, for cost of development & maintenance, or what’s easiest for the user, when (bad) designers and (bad) “product folks” get involved and are way too into the wrong kinds of “consistency”, especially brand and cross-platform consistency (yo, I’m not sure it’s worth spending extra money fucking up contrast and platform norms on your inputs so your fucking radio buttons are “on brand” or whatever, like, I’m deeply skeptical of the actual business value of that kind of thing, though I can see the PowerPoint presentation value… and that’s why it happens)
Every human has an opinion on practically everything. But has that human put in the effort to justify pushing that specific opinion?
In this case, is the opinionated engineer humble enough to realize that using software in their day to day life does not equal using software in our customer's context?
Ultimately, you need to decide who your target user is. Do you want to cater to the lowest common denominator, or do you want to want to make something power users can customize to fit their workflow?
Neither answer is necessarily wrong, you just need to make a choice.
This fallacy is at the heart of the failure of modern software.
Making things work for the median user is almost entirely about defaults and intuitiveness. If everybody is sending messages all the time, there should be a conspicuous button for sending messages.
Making things work for power users is about allowing those defaults to be changed. It's fine if this is five deep in a menu somewhere. It's fine if there is an option for "advanced mode" that opens up a bunch of menus that are otherwise hidden. It's fine if this requires you to write your own filter rules etc., as long as that's available. What's not fine is to make the limited interface the only interface.
Simple things should be easy and complex things should be possible.
If I use the product, I'd expect that feedback to get the same weight as any other customer. And not be dismissed because it came from a 'technical' person.
The issue is that software engineers most often strike a balance between passive aggressive and overly opinionated... Its a shit mix if you ask me- very frustrating personality to work with.
Isn't that the same as UI/UX people being generally clueless about how to build applications for the very platform for which they are designing? Designers and product managers constantly have to be guided about the logical and the structural constraints of their target platforms, to be given workarounds, to be taught how to logically divide their reusable components so that they can build their dream design system which, by the way, always fights the platform's native design system.
It's totally fine to have an opinion on UI/UX if it is informed by cognitive psychology and other relevant HCI subfields, in the same way that it's OK for UI/UX to push for designs so long as they are also informed by business and engineering.
I have long believed that the biggest issue here is that engineers and power users generally have a much higher “pain threshold” when it comes to poor or complex UI/UX. They are not always the best people to judge how or if less experienced users will tolerate or adapt to those patterns. It’s fine to have opinions but they must be prepared for them to be challenged. Even better if they can invite others to challenge them, which is essentially what talking to your users achieves.
> engineers and power users generally have a much higher “pain threshold” when it comes to poor or complex UI/UX
I don't think that's entirely accurate. We tolerate steep learning curves if the result is an increase to our power. That's why we are power users.
Vim, for example. Some of us put effort into learning it because it's a powerful and efficient editing language that will enable us to easily accomplish hard things.
Caring about the system itself and being willing to put effort into it are what separates power users from normal users. We don't do this because of masochism, we do it because we want to increase our power.
Normal users want the system to just do what they want without any thinking or effort at all, as though it was a highly specialized tool for their exact task rather than a powerful programmable general purpose computer.
Personally I don't care at all about how "less experienced users will tolerate or adapt". This unceasing focus on the wants and needs of normal users frequently hinders us. Developers typically reduce the complexity and feature set of a piece of software in order to turn it into something a normal user can deal with. We want more power, not less.
Normal users don't really matter unless they are directly paying our salary. We should all favor ourselves unless we're getting paid to focus on someone else.
The two biggest causes of major UI problems I see are:
1) Exactly what you wrote: power users don’t even realize they clicked through five things in ten seconds any one of which would have derailed a weaker user, because they’re so used to bad UI that it’s almost invisible to them.
2) Zero care given to what’s most natural for the platform, for cost of development & maintenance, or what’s easiest for the user, when (bad) designers and (bad) “product folks” get involved and are way too into the wrong kinds of “consistency”, especially brand and cross-platform consistency (yo, I’m not sure it’s worth spending extra money fucking up contrast and platform norms on your inputs so your fucking radio buttons are “on brand” or whatever, like, I’m deeply skeptical of the actual business value of that kind of thing, though I can see the PowerPoint presentation value… and that’s why it happens)
But is it an informed opinion?
Every human has an opinion on practically everything. But has that human put in the effort to justify pushing that specific opinion?
In this case, is the opinionated engineer humble enough to realize that using software in their day to day life does not equal using software in our customer's context?
Ultimately, you need to decide who your target user is. Do you want to cater to the lowest common denominator, or do you want to want to make something power users can customize to fit their workflow?
Neither answer is necessarily wrong, you just need to make a choice.
> you just need to make a choice.
This fallacy is at the heart of the failure of modern software.
Making things work for the median user is almost entirely about defaults and intuitiveness. If everybody is sending messages all the time, there should be a conspicuous button for sending messages.
Making things work for power users is about allowing those defaults to be changed. It's fine if this is five deep in a menu somewhere. It's fine if there is an option for "advanced mode" that opens up a bunch of menus that are otherwise hidden. It's fine if this requires you to write your own filter rules etc., as long as that's available. What's not fine is to make the limited interface the only interface.
Simple things should be easy and complex things should be possible.
1 reply →
Those goals are far less at odds than you seem to be implying.
One of UX principles is exactly trying to do both.
My mom can use gmail, but she doesn’t even know about its hotkeys and accelerators, or Labs and whatnot
If I use the product, I'd expect that feedback to get the same weight as any other customer. And not be dismissed because it came from a 'technical' person.
Using? Are you paying?
1 reply →
The issue is that software engineers most often strike a balance between passive aggressive and overly opinionated... Its a shit mix if you ask me- very frustrating personality to work with.
Isn't that the same as UI/UX people being generally clueless about how to build applications for the very platform for which they are designing? Designers and product managers constantly have to be guided about the logical and the structural constraints of their target platforms, to be given workarounds, to be taught how to logically divide their reusable components so that they can build their dream design system which, by the way, always fights the platform's native design system.
It's totally fine to have an opinion on UI/UX if it is informed by cognitive psychology and other relevant HCI subfields, in the same way that it's OK for UI/UX to push for designs so long as they are also informed by business and engineering.
That’s the attitude he’s talking about!