That Other Friction

or, “Why Some Players Think You’re Lazy, Dumb, and/or Incompetent”

“Friction” referring to “model mis-alignment” is well-established. I.e., when you develop an application, there’s a model for how users can/will use it. Users are unpredictable, so generally they’re doing something a bit (or a lot) different. The spikes of frustration and speed reductions those users experience when your app behaves unexpectedly are friction.

That’s my understanding of the typical usage, anyways.

There’s another thing we could call “friction,” though, and it draws its identity from the treatment in physics education of the actual force of friction. Iain Dooley discusses here how his team uses this meaning to give a name to all the confounding factors that we generally can’t see from outside the problem.

This is one of the big causes of that pernicious afflictor of gamers: ADS (Armchair Developer Syndrome). Because it looks simple from outside, everyone has an opinion on what you should do, how long it should take, and how hard it should be. They have no sympathy for bugs, schedules, or any of the myriad constraints you operate under. ADS is actually worse when players have studied programming themselves (especially if they’re in the Hand-Holding Honeymoon phase), commonly turning a little experience into an unquestionable authority on every topic. Every one of your favorite biases comes out to play.

I think no matter how talented/skilled/on-schedule your team is, you’re going to get bitten by this.

Is there a solution? Maybe something to at least somewhat mollify the vitriol-froth’d fans?

My first instinct is to move towards greater transparency. I suspect players would feel less frustrated with the things they don’t like if they knew that there was a timeline to address those things, though I can’t guess at the magnitude of the effect.

As transparency is costly, in the ideal case, it doesn’t need to be a regular thing. How much of the full effect would we get by occasionally offering a detailed bullet-by-bullet description of what needed to be done to fix a seemingly simple problem. It could help players understand the difficulty of some tasks.

Permit me here a moment of unguarded optimism: It’s possible that over time, such revelations would help some players second-guess their own knee-jerk reactions, and help others be your champions (1st paragraph).

If your character sheet is missing that “Lawful Good” designation, another option might be some harmless misdirection: Give players some say over what you tackle next. Here I’m imagining a public list of bugs (or imbalances?) that gets ranked by player votes. Some small part of your team tackles the highest-ranked items, perhaps offering more direct reporting to players about the process. (There are services/sites that do customer voting like this, though I won’t link to them here for various reasons.)

How is that “misdirection”? Simple: if there are multiple high-importance bugs, players will fight back and forth over which ones get priority. So then if ’s pet peeve isn’t being fixed, instead of yelling at the devs, some portion of the vitriol might be turned towards the community. It’s sort of like peer-to-peering your tender developer emotions and company PR.

This isn’t a bulletproof solution. It can easily be gamed, and there’s a risk that the misdirected vitriol causes damage to the community. However, there’s also a chance that the vitriol will turn into something different, something constructive. This approach can provide players with a sense of agency. This in turn gives players something they can do right this second to make that bug fix more likely: campaign for public support.

If SRG someday grows bigger than my stand-up desk, maybe I’ll get the chance to put these into practice and let Science tell me how wrong I am.

Want to beat Science to the punch? Comments: Leave you some!