Paul Cantrell
Hey fellow developers! Do you have a preferred term of art for software that:
• has captive users
• is designed primarily for the org’s needs
• can frustrating as long as it works
…versus a term for software that:
• people can choose not to use
• must not be frustrating
• requires user-centered design
There are plenty of terms like “enterprise software” and “consumer software” that come close, but say too much (specifying who users are, biz model, etc). Any terms that capture just the above?
Paul Cantrell
My working terms are “user-centered software” and “org-centered software,” but if there’s a good term of art out there, I’d prefer it.
Paul Cantrell
@rvr In the context where I’m using the terms, it’s all internally developed software for a nonprofit, so there’s no “buyer.” I’m trying to help them see the difference between the dev they’re used to (making internal processes work) vs what they’re struggling with (“Why doesn’t the public engage with our clunky, irritating software even though it has all these features?”).
Talk’o’belle
@inthehands “buyer-centered” might be better than “org-centered”? Not sure. It’s a tough one to label.
Paul Cantrell
@rvr Captive vs non-captive user is the core distinction here, yes.
Talk’o’belle
@inthehands ah, very interesting… so it’s internal vs external? So inside- be outside-oriented… or captive vs non-captive user base?
Paul Cantrell
@jgys
I was tending somewhere similar:
https://hachyderm.io/@inthehands/110675707484995630
jgys
@inthehands user-centered versus system-centered, maybe?
Exandra
@inthehands the first I call "vendorware"
Paul Cantrell
@xcorvis One of the core ideas I’m trying to communicate to this particular audience is the relationship between what I think are your two spectra: when you don’t have captive users, your org’s needs have to take a back seat to the users’ experience.
xcorvis
@inthehands maybe instead of a single term you're looking at a grid of 2 competing spectrums. Usability vs necessity, with a "frustrating" quadrant and a "happy" one.
Nathan Vander Wilt
@inthehands @xcorvis I don't quite get this though — if the software is "clunky and irritating" as you said elsewhere, isn't that in some ways *also* working against the org's needs?
like I get that there's distinction between learn-as-you-go interfaces (a bumper car, say) and requires-training-or-even-certification interfaces (like operating a high-rise crane) but if the interface for the latter is needlessly user-hostile just out of poor design I don't see that working in **anyone's** favor…!
Paul Cantrell
@natevw @xcorvis
Yes, in a perfect world, all software is built in a user-centered way. (I’m the one usually beat the drum of “All software impacts people! Know who they are, and be good to them.”)
Still, in our world of tradeoffs, sometimes there’s a hard choice between “check functionality box X even though it compromises the experience somewhat” vs “cut functionality X to keep the experience polished.” And the best choice there very much depends on context.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.