5 ms·

Lots of exclusively technical types don't understand why people are confused by heavily documented but awful interfaces. That's why HFE became a field and why U

Lots of exclusively technical types don't understand why people are confused by heavily documented but awful interfaces. That's why HFE became a field and why UX practices should inform software development from the get-go. Documenting a lousy interface is not a solution— it's a mitigation strategy and usually a lazy one. Most people find git's interface to be confusing, arbitrary, and frequently astonishing in destructive ways. Maybe you're exceptionally gifted in keeping a large bank of seemingly arbitrary commands in your head, or maybe you speak git frequently enough to have native proficiency. Unfortunately, you can't generalize that to all other users, and it doesn't invalidate their difficulty. Since most folks new to git are likely new to CLIs— having a tutorial two levels deep in man pages makes it nearly useless. If you draw two barely touching circles on a page and label one "people confused by git enough to need a tutorial," and the other "people who know what man pages are, how to access and read them, and think to look there for tutorials,"— that's your usability Venn diagram for that documentation. Beyond that, many organizations require non-developers to use git now— copywriters, designers, project managers, etc. We're not talking about sendmail or clang here. That lack of developer empathy for less technical end-users is why software projects, especially FOSS ones, marginalize UX input. Usability is the one thing commercially-sold software consistently does better than FOSS, and one of the reasons commercial offerings so frequently trounce FOSS equivalents in everything but developer and system/network tools used by people with bad UI Stockholm Syndrome. When monetary incentives and non-developer input inform product decisions, "it's in the docs" just doesn't cut it. I've primarily worked in tech for the past 25 years, been a full-time developer for 10 (exclusively writing FOSS,) and have recently moved towards design because I see a lot of unmet needs there. So I understand the frustration in user needs precluding the most elegant/interesting/efficient technical solution to a problem. But, if you aren't actively working to meet end-user needs, frustration about end-user confusion isn't particularly justified. As an aside, I believe Firefox's comparative success among end-user-visible FOSS projects stems from the Mozilla Foundation's commitment to product usability. Check out https://firefoxur.github.io https://firefoxur.github.io

yarky 5y ago
> Lots of exclusively technical types don't understand why people are confused... It's not that they don't understand, it's that non-technical people often proactively avoid carefully reading the few lines of relevant documentation. That's something a technical person can tell from the second the non-technical tries to ask a question. > When monetary incentives and non-developer input inform product decisions, "it's in the docs" just doesn't cut it. Obviously, you have the right to ask any question if you're paying for someone's time: you become a "client". Otherwise, yes please read the docs.
- Aeolun 5y ago
  To be fair, I’m fairly technical and I also proactively avoid reading the documentation. In the ideal scenario the interface to whatever I’m using is self explanatory, and I don’t run into any issues. It’s only if the product has a less simple interface that I have to fall back to the documentation (and I dislike doing so).
  - chefandy 5y ago
    Even then, you can kill a lot of seemingly inevitable interface complexity by thoughtful application of common idioms, hiding elements (ideally automatically) that are really never useful in that part of a workflow, consistent meaningful layout among work screens, communicating commonality and intent with color, proximity, shape, size, etc., good use of labels when necessary, and moderate use of animation to convey how the interface is changing so a user can stay oriented. You can really only make these decisions by carefully studying user workflows. How many enhancement request issues have you seen in issue trackers where a project maintainer makes an off-handed declaration that users don't really want/need that functionality? How often do you suppose it was entirely based on the way they use the software and nothing else? I've spoken to many developers whose workflows have been stymied by oversimplified interfaces and they associate designers with pretty looking but defanged interfaces. Those are poorly designed interfaces. Usually they're put together by someone whose goal is to get featured on Dribbble where functionality is secondary. Those designs have their place as aesthetic inspiration for other designers, but they should not be seen as formal goals. “Everything should be made as simple as possible, but no simpler.” The reason why the interface design and graphic design degree programs are very similar at the college I'm attending is because many of the goals are exactly the same— using layout, text, graphics, animation, and other elements to communicate complex ideas as clearly and efficiently as possible. The semiotic analysis common in higher-level design has just as much application in interface design. The denotation of two separate save buttons might be exactly the same, the connotation might change drastically depending on what it's next to, what it's the same color of, the weight of the font, the weight of the stroke of the button compared to other elements, if there's an animation when your cursor gets close to it, etc.
WalterGR 5y ago
I’ve never heard of HFE. Is this what you’re referring to? https://en.m.wikipedia.org/wiki/Human_factors_and_ergonomics https://en.m.wikipedia.org/wiki/Human_factors_and_ergonomics
- chefandy 5y ago
  Yep!
- chefandy 5y ago
  Oh, sorry— I read too quickly. I was specifically thinking of Human Factors Engineering, though I'm sure Human factors and ergonomics is quite related.
bluepoint 5y ago
What resources do you recommend for starting to learn more about design?
- chefandy 5y ago
  I’ve made a note to get back to you on this. Personally, I started a BFA in graphic design, then switched to interaction design which has a heavy UX/User Research… the programs are very similar at their cores because the thought process is very similar among different design disciplines. That’s probably not feasible for most, however, and I should have a better answer for this excellent question.
- chefandy 5y ago
  As a quick answer because it popped into my head, The Design of Everyday Things by Don Norman is an obvious first stop on that trip. Introductory courses on LinkedIn Learning (formerly Lynda.com) are an excellent place to get a foothold for how it's done today. I believe many public libraries will give you remote access to LinkedIn Learning! I think "Don't Make Me Think" is a bit overrated, but many people find it very useful.

yarky 5y ago

> Lots of exclusively technical types don't understand why people are confused... It's not that they don't understand, it's that non-technical people often proactively avoid carefully reading the few lines of relevant documentation. That's something a technical person can tell from the second the non-technical tries to ask a question. > When monetary incentives and non-developer input inform product decisions, "it's in the docs" just doesn't cut it. Obviously, you have the right to ask any question if you're paying for someone's time: you become a "client". Otherwise, yes please read the docs.

Aeolun 5y ago
To be fair, I’m fairly technical and I also proactively avoid reading the documentation. In the ideal scenario the interface to whatever I’m using is self explanatory, and I don’t run into any issues. It’s only if the product has a less simple interface that I have to fall back to the documentation (and I dislike doing so).
- chefandy 5y ago
  Even then, you can kill a lot of seemingly inevitable interface complexity by thoughtful application of common idioms, hiding elements (ideally automatically) that are really never useful in that part of a workflow, consistent meaningful layout among work screens, communicating commonality and intent with color, proximity, shape, size, etc., good use of labels when necessary, and moderate use of animation to convey how the interface is changing so a user can stay oriented. You can really only make these decisions by carefully studying user workflows. How many enhancement request issues have you seen in issue trackers where a project maintainer makes an off-handed declaration that users don't really want/need that functionality? How often do you suppose it was entirely based on the way they use the software and nothing else? I've spoken to many developers whose workflows have been stymied by oversimplified interfaces and they associate designers with pretty looking but defanged interfaces. Those are poorly designed interfaces. Usually they're put together by someone whose goal is to get featured on Dribbble where functionality is secondary. Those designs have their place as aesthetic inspiration for other designers, but they should not be seen as formal goals. “Everything should be made as simple as possible, but no simpler.” The reason why the interface design and graphic design degree programs are very similar at the college I'm attending is because many of the goals are exactly the same— using layout, text, graphics, animation, and other elements to communicate complex ideas as clearly and efficiently as possible. The semiotic analysis common in higher-level design has just as much application in interface design. The denotation of two separate save buttons might be exactly the same, the connotation might change drastically depending on what it's next to, what it's the same color of, the weight of the font, the weight of the stroke of the button compared to other elements, if there's an animation when your cursor gets close to it, etc.

WalterGR 5y ago

I’ve never heard of HFE. Is this what you’re referring to? https://en.m.wikipedia.org/wiki/Human_factors_and_ergonomics https://en.m.wikipedia.org/wiki/Human_factors_and_ergonomics

chefandy 5y ago
Yep!
chefandy 5y ago
Oh, sorry— I read too quickly. I was specifically thinking of Human Factors Engineering, though I'm sure Human factors and ergonomics is quite related.

bluepoint 5y ago

What resources do you recommend for starting to learn more about design?

chefandy 5y ago
I’ve made a note to get back to you on this. Personally, I started a BFA in graphic design, then switched to interaction design which has a heavy UX/User Research… the programs are very similar at their cores because the thought process is very similar among different design disciplines. That’s probably not feasible for most, however, and I should have a better answer for this excellent question.
chefandy 5y ago
As a quick answer because it popped into my head, The Design of Everyday Things by Don Norman is an obvious first stop on that trip. Introductory courses on LinkedIn Learning (formerly Lynda.com) are an excellent place to get a foothold for how it's done today. I believe many public libraries will give you remote access to LinkedIn Learning! I think "Don't Make Me Think" is a bit overrated, but many people find it very useful.