Re: this earlier post: https://mastodon.social/@mhoye/110991950899025738

One of the things I'm most proud of in my last gig was adding notes to our getting-started docs saying explicitly "if this process fails for you, this is a bug and we want to hear from you."

Granting explicit permission to file bugs against the _get-involved process_, quickstart docs particularly, is another way of saying "we care about the details of the experience of getting involved in this project and community", and it is very powerful.

There is such a thing as community accessibility, of the ergonomics of getting involved. It is _extremely common_ for smart, determined people to hit failure after failure during an install process, and decide this project or community just isn't for them. Open Source projects often end up self-selecting for people who coincidentally have not just hardware or software but _cultural expectations_ identical to the primary developers, because all of those failures are completely invisible.

As one example - a bunch of our docs said "copy and paste this command:"

> command whatever blah

... and people were copy-and pasting "> command", with the caret and it was failing because of course it was.

Absolutely trivial to fix, but a completely invisible non-problem to anyone who's grown up in a console. But what designer, or technical writer, or translator or or or, would reflexively understand the problem wasn't them?

@mhoye I think about this all the time. What rarely if ever happens: the author of the doc is forced to watch a designer/writer/translator fumbling around making those mistakes. Or the creator of a web app is forced to watch people trying to enter phone numbers into forms. Or really any designer or builder of a product is forced to watch people struggling to use it.

I'm not talking about focus groups. I'm talking about chaining builders to chairs, gagging them, and making them actually watch.

@judell @mhoye At the risk of being a “reply guy”, the UX/UI design industry calls this “exposure hours” and it’s both been a fairly standardised process and common recommendation for improving UX for over thirty years. It’s almost always a non-starter with management, though.

Here’s a decade-old article that talks about this in terms of field visits. https://articles.centercentre.com/user_exposure_hours/

Probably easier to do today with modern tech. Still a non-starter for most managers, though.

@baldur @judell @mhoye one approach that is fairly lightweight is session recording. I interviewed a eng leader who started the week by having his team watch a few selected session recordings. Not as good as exposure hours (which I can corroborate as an established practice — learned about them 25 years ago). But still pretty good.
@baldur @judell @mhoye in game development, at the studios i've worked at the past 20+ years at least, not doing this would be considered foolish in the extreme. in software dev terms we're constantly making up new user flows and custom interfaces (while also juggling any number of subjective/aesthetic goals) and seeing how people (within the team, outside the team, outside the studio) interact with them for the first time is where your plans meet reality.
@baldur @judell @mhoye and i say that very much not to say "look at how smart we are" - game dev is a mess, haha - but because we live and die by everything that falls under the user experience umbrella, for any given game if we screw up badly enough our audience walks away forever.
@baldur @mhoye If any of the crappy business websites I've cursed at lately really did follow that recommendation, I shudder to think what they'd have been like if they hadn't!
@judell @mhoye Like I said. This is a standard recommendation and there’s tons of data to prove that it works, but you practically never get it past management so very few companies actually do it. At least, in my experience.
@judell @baldur @mhoye
Useability? Just try tuning in the ball game on the hotel TV.