The user stance

I recently read an old article by Joel Spolsky which is actually a review of The art of Unix Programming by Eric S Raymond. Its title, “Biculturalism” made me think immediately of The Two Cultures by CP Snow.

Unix culture

Joel is a developer who understands the Windows culture very well. He worked on Microsoft Excel and is one of the founders of Stack Overflow. He really understands the needs of users, but it also seems like he “gets” the Unix virtues. I have spent a long time absorbing these virtues, so it was refreshing to see a different take on it.
In short, he says “Unix culture values code which is useful to other programmers, while Windows culture values code which is useful to non-programmers”. I have migrated away from Windows for this reason as I find myself on the programming side more than I find myself on the user side. Said differently I don’t program much for end-users.

It’s a stance, not an identity

I think the most important thing to understand about users is that the tools they are using are a means to an end not an end in themselves. The most successful tools allow users to feel like they are simply solving the problem themselves, with the tools fading away and just supporting the user. Even physical tools have this tendency to become extensions of our bodies.
I won’t want to create the impression that I do not consider myself a user. When I want to get things done, I also value tools which allow me to get those things done with the minimum of effort and low cognitive load. It is, however, useful to distinguish between the user mindset, which I will call the user stance and the identity of a particular individual. It is more accurate to say someone is approaching a tool in the user stance than to say that a person is a user. This also makes it clear that the same person can approach different tasks differently.

What is a stance?

I’m borrowing the word stance here from Daniel Dennet’s three stances:

• Physical stance – which makes predictions from some physical law or model of how the parts work (what is it made of/how is it put together)?
• Design stance – predictions are made from knowledge of the purpose of the system (what is it designed to do)?
• Intentional stance – predictions involve attributing intent to the system (what is it trying to do)?

The design stance allows us to reason about the function of an object by knowing it is designed to solve a particular problem or behave in a particular way. This is what allows us to predict the position of a clock’s hands at a particular time of day.
I would say that taking the user stance implies additionally supposes that the designer was good enough that the problem the tool was designed to solve will be easy to solve using this tool.
I’ve spent lots of time reasoning about these stances during teaching, especially the overeager way in which people fall into the intentional stance when interacting with complicated systems like computer software. Even though software is basically a deterministic system, it is often easier for people to reason about its actions by ascribing intent: “The system is trying to do X, so it will try to do Y”.

Misapplication

The key insight that I had while reading Joel’s article has to do with noticing that the user stance can be adopted like a strategy. The article is pretty astute in recognizing that commercial software is mostly built in service of users. The goal is to remove friction in service of getting a job done. This leads to beautiful and intuitive user interfaces which can be picked up quickly. Most Windows (and Mac) programs are “interface first” – there will be a sketch of the interface before there is any actual functionality.
I find my students (who were by now all born after Windows 95 came out) have signficant difficulty even imagining a computer program which doesn’t have a (graphical, on-screen) interface. Being “user-friendly” means rewarding people for adopting the user stance.
I made the journey across the computing landscape coming from command-line interfaces and somehow I fell in love with them. There are plenty of people in my office who are as old or older than I am who jumped ship as soon as graphical interfaces became available. I suspect that this is because most of them approach the computer from the user stance.
I think the user stance is inappropriate in a couple of settings, where it mostly leads to frustration:

When you are trying to learn how something works

An excellent way to find out how a thing works is to take something apart or try to build one yourself. I have learned a great deal by implementing computer programs which solve problems I have encountered in my life. A nice side-effect of this approach is that you end up building tools for yourself. I used to believe that making the source code of these tools available to my students would help them to see what they look like inside and understand them better. What I have found is that most of my students are stuck in the user stance – it is hard for them to see these notebooks as anything other than a tool for solving these particular problems. Even though the parts are exposed, they work even when you don’t understand them and if you are just trying to solve a problem, you don’t care how it works (this is a key part of the user stance).

When you’re trying to build tools for tool-makers

Developers or tool-makers have different needs from users. In many cases, they value modularity and re-usability above immediate usefulness. I’m not sure, but I think there may even be a correlation with the novice-expert spectrum here. When you watch cooking shows you find out that single-use tools (a single thing that only slices avocados for instance) are frowned upon by chefs in favour of multi-purpose tools which perhaps require more learning and skill but allow for broader application.
This attitude spills over to tool creation when you try to build tools which do one thing well and can be used in multiple applications – just like the Unix tools. By contrast, graphical applications tend to be like the avocado slicer.

When you’re trying to work collaboratively

I have often made the mistake of building systems for what I had imagined would be a collaborative activity and made it too easy to adopt the user stance in designing the interface. My experience has been that as soon as the interface treats you like a user, you fall into the user stance. The symptoms of this is that people log a support call instead of fixing things, even when they have the power to do so. A specific failure has been building out our departmental wiki. Wikis are collaborative by nature, but strangely most of my colleagues are users of this resource. I’ve seen this even with Wikipedia. People are vaguely aware that they could edit the content, but they seldom do.

Final word

My exploration of this idea has led me to approach the way I design things differently. It has also allowed me to understand my own and other’s behaviour better as I now have words to distinguish between different strategies.