A sketch of Clar, sillily typing on a laptop.

The User

@ b.charr.xyz/the-user

I’ve always had a very hard time articulating why FOSS communities seem so openly hostile toward outside input, why the FOSS ecosystem is so segmented, and why not nearly as many people use FOSS when they should. One mentality I’ve seen especially in FOSS, the larger tech community, and honestly by anyone who’s half-decent at design, is that “users are stupid.”

Recently, I’ve personally been making a huge attempt to wipe the word “stupid” from my vocabulary. I genuinely can’t find any salvage for the concept of stupidity, because even ignoring its ableist origins, describing something as “stupid” is really just an excuse to avoid explaining why a “stupid” thing or person is actually bad. In that sense, “bad” is more apt than “stupid,” because at least then it’s obvious that you hadn’t really given it a lot of thought.

But, even though the phrase itself seems to imply that no one really put any thought into it, there’s actually a lot of important stuff from UX and design that gets attributed to this terrible phrase. And I plan to go over a lot of these points, to the point where this is going to be a series of multiple posts about design and user experience. Hopefully.

But before we begin, though, we need to first talk about why software exists in the first place. And I think that ultimately, software is just there to make something difficult or impossible to do by hand, easier. And if software doesn’t accomplish this goal of being easier, then there’s really no reason to use it. It sounds harsh, but it’s true, and it’s something that a lot of people in the FOSS community just don’t understand.

Being made from scratch, having a copyleft license, or simply having “more” features than another piece of software aren’t going to persuade most people to use it. These may persuade some people, but it all fundamentally boils down to what a person’s perception of “easier” means. And the question every designer has to ask themself is what they’re making easier. Because if you’re trying to do something without relying on proprietary software, or if the feature you’re looking for is only available in a particular program, that software really does make things easier. But if what your software sets out to do doesn’t match what the user had in mind, they’re not going to use it.

Users can’t know everything

Sometimes, users really don’t know what they’re trying to do, and that just makes finding out whether a piece of software is “easier” genuinely hard. For example, although Facebook advertises itself as “connecting people,” that itself is really vague, and a lot of people on Facebook often wonder what they’re truly getting out of the platform. Does Facebook make this “connection” easier? And even if the connection is easier, was that really the thing the user wanted to make easier in the first place?

While it might seem uncommon, I’d argue that a lot of kinds of software don’t, through their existence alone, give users a very clear-cut understanding of why it might be “easier” to use them. And while some parts are very obviously easier, like being able to undo mistakes in document editors and drawing tools, most aren’t, like the Facebook example.

Comments on the supposed “stupidity” of users sometimes refers to just how much users don’t know about these questions which are so fundamental to making decisions about what software to use. A good designer understands this and helps the user understand more about why they want to use a piece of software, while a malicious designer might exploit this lack of understanding to make a user use something they really didn’t want, like Facebook.

And I’ll note, not knowing exactly why you use a piece of software is perfectly fine and understandable. As a reminder, “intelligence,” something I won’t stop putting in quotes, is an ableist, garbage concept that we’d be better without. But because designers think that users are “stupid,” and society has a very specific definition of what this means, we’re going to have to talk about it for a bit.

How to be stupid, according to the experts

One big part of “intelligence” is the idea that knowing something makes you smart. That said, as George Orwell taught us, knowing some things makes you smarter than knowing other things. Because everyone thinks that whatever they’re working on is the best and most important thing in the world, in this sense, the users of whatever they’ve made are not smart. They just don’t understand the technical details behind what they’re using, which I’ll remind you is the best thing. I hate to break it to you, but not knowing these details, according to full-time pessimist Linus Torvalds, means that you’re stupid.

That said, the term “stupid” aside, there is a point to be made from all of this. Because users aren’t aware of all the technical details in general, and they shouldn’t have to be. There are huge differences in the way that even two different users think, and a designer has to account for all of them. Simply having the perspective of those who make a piece of software isF not enough.

For example, let’s take a look at four (hypothetical) people who end up using four different pieces of software for a similar task.

Four people, four programs

Ash is an author, and they use Google Docs to write stories. To them, this option is the best because:

Madhur is a mathematician, and they write documents in LaTeX. To them, this option is the best because:

Phoenix is a programmer, and they compose documents in text using Vim. To them, this option is the best because:

Riley is a recruiter at a company, and they use Microsoft Word to compose documents. To them, this option is the best because:

“Easy” doesn’t just mean easier

In design terms, these are four very different “user stories” for the concept of writing documents. And as you can see, all four people are happy with four completely different ways of doing things. That’s really normal, and it’s just a reminder that what might be better for one person is not necessarily better for another.

And “better” here really means “easy,” because what differs between these four users is not how they accomplish the task of writing documents, but what they set out to do in the first place. Ash, Madhur, Phoenix, and Riley are all “writing documents,” but Ash is trying to express themself in words, Madhur is trying to share knowledge with the world, Phoenix is trying to help others understand their work, and Riley is trying to hire people at a company. If you think that these four people are doing anything close to the same thing, you’re mistaken.

And that’s the fundamental disconnect that shows up when designing software. When we use a tool, we’re not using it because we want to use a tool, but because we have another thing in mind which can be accomplished by using the tool. For example, although a shovel is really good at digging holes, most people who use shovels aren’t just planning to dig a hole for the fun of it. They’re planting trees, searching for treasure, or ritually burying a corpse.

The creator of a piece of software cannot possibly know what every user is going to do with it, just like how shovel manufacturers can’t know whether their tools will be used for burying seeds, gold, or bodies. Designers are, I’d argue, obligated to help bridge the gap between the creators of a tool and their users, to help teach users why they want to use one thing over something else.

Traditionally, tools have taught their users how to use them not of themselves, but through instruction manuals, supplemental materials, and inspirational blog posts. And FOSS tends to adopt this mentality too; in the words of full-time broken record Linus Torvalds, “read the fucking manual.”

Throwing away the manual

In design, most people tend to polarise toward two different views on teaching their users. One camp, which was the mentality of the late Steve Jobs, is that design should be “intuitive.” That is, design should try as hard as possible to make its user understand without having to read a manual. And a shovel is, again, a pretty good example of this; you don’t need a manual for a shovel, which is why I use iPhones to plant flowers in my garden.

This camp is quite the opposite of gardening, actually. Taken to its extreme, some people argue that the best design is one that you already know how to use. And fundamentally, this means that you don’t need to build any kind of understanding in your users, because that understanding is already there. For example, the iPhone has one button, so that if you’re ever feeling off and need to press a button, you know what to do.

But jokes aside, this kind of design relies heavily on the idea of “guess and check,” where users will try things out rather than reading into what they need to do. And there is a lot of merit to this, because a lot of people fundamentally learn better that way. But there are also a lot of downsides, because design which incorporates this mentality often has to be very simple so that a user who’s guessing at what to do doesn’t have to make a whole lot of guesses.

Throwing a large, heavy encyclopedia at someone’s face

To be honest, the other camp really doesn’t get good rep at all. Because while I’m representing this as two sides of the metaphorical design coin, the previous mentality is so prevalent in “design” that the other camp is basically completely ignored. Almost literally, people who call themselves “designers” scoff at the idea of anyone thinking this way, and call them wrong without remorse. And I’d almost be inclined to sympathise, because a lot of the people in this camp really, really don’t know what they’re doing. But as I said, these are two halves of the same coin, and understanding both mentalities is crucial to understanding good design.

The other camp, which is most often adapted by programmers, pragmatists, and those without the job title “designer,” is that tools shouldn’t be made with the expectation that their users will understand them immediately.

Really.

People in this camp focus a lot on documentation. And if you’re a programmer, systems administrator, or tech-inclined person of any kind and just burst out laughing, I understand your pain. Because if you’ve ever tried to install Linux or use any kind of free or open source software of any kind, you’ve probably encountered the FOSS community’s favourite four-letter acronym: RTFM. Read The Fucking Manual.

You’ve probably noticed that I’ve mentioned Linus Torvalds three times in this post so far, not including this time. The truth is, he’s such a good example. If you’ve ever had the pleasure of reading some of the stuff he says on the Linux development mailing list, you’ll know that it’s quite an experience. Honestly, if Linus Torvalds wrote a dictionary, it’d probably just be 469 999 conjugations of the word “fuck,” followed by a short page on “you.” Literally, the system which virtually all programmers use to manage their source code was invented by Linus Torvalds, and it’s called Git. He often jokes that it’s named after its creator, and I’d be inclined to agree.

Frankly, the entire FOSS community spends more time asking people to read documentation than it does writing it. And ultimately, everything that people need to figure something out is there. But unless you want to be sifting through mailing lists, forum posts, tersely written blocks of text in a terminal, and other forms of various word vomit, there’s not necessarily a way for us to learn how to use one tool if you don’t already know how to use others.

One form of documentation that’s included with most tools on Linux and similar systems is called man, short for manual, and most man pages are terse at best, and unhelpful at worst. One tool, tar, which is used for creating file archives, has such notoriously bad documentation that most people (including myself) just search for what they’re trying to accomplish on the web.

One thing I like to joke about is the fact that every time I have to figure out how to do something on Linux, I have to consult a man. But honestly, this just turns the joke into a social commentary on how most man pages are actually useless, even though #NotAllManPages are.

Actually teaching the user

Despite all of the fun I make of Linus Torvalds and the entire FOSS ecosystem, documentation is necessary. Intuition, fundamentally, is not a concept that holds its own weight, by itself. Ironically, even though FOSS follows the mentality of RTFM, the tools that come out of the greater FOSS community are based on the intuition of programmers. And similarly, designers who lean heavily on intuition simply rely on things that users learned the old-fashioned way.

You see, good design reconciles both camps. Long-term, a user needs an intuitive understanding of a tool in order to continue use it. However, they can’t gain this intuition without first being taught. And teaching a user isn’t about showing them how to use a tool, convincing them why your tool is better, or anything like that. It’s about teaching them how to accomplish their own goals more easily using the tool.

And that’s the one, obvious thing the RTFM camp really gets wrong. If I buy a shovel and the instruction manual is just eight pictures showing me how to dig a hole, that’s basically worthless. Showing me how to use a shovel to plant a tree without breaking my back, or showing me how to bury that chest full of rare earth metals and jewels, is a lot more useful, because it helps me think about why I might want to particularly use a shovel as a tool over, say, my bare hands.

And sure, the shovel example is kind of silly, but it makes a good point. Most FOSS tools really feel like they’re telling me how to use a shovel. Git, for example, the tool that professional asshole [Linus Torvalds] created, has been incredibly notorious for its documentation. The git documentation itself is more like an exhaustive specification rather than an actual explanation of why someone should use git over something else. Even most tutorials don’t go that far, and just assume that because you’re viewing the tutorial, you know why you should use git. (You don’t.)

There are a lot of good lessons from design that FOSS really hasn’t learned. And I just covered a small portion of them, with a lot more to come. Next time, I’ll be talking a bit more about what exactly “teaching” means, and why all of the points in the previous section matter. After that, I’ll be elaborating on other interpretations of the misleading, loaded, and ableist phrase “users are stupid,” and how the term “stupid” really is just a sign of people looking down on their users, rather than trying to help them.

Until then, in the words of Bob Ross, “We don’t really know where this goes— and I’m not sure we really care.”