It struck me recently that we pay far too little attention to the difference between novices and casual users. A novice is someone who has just embarked upon a course of study and whose intent is to become a master of that subject. A casual user is someone who just wants to get a job done and has no interest in mastery. Their information needs are very different.
Being a casual user is not the same thing as being an infrequent user. Most commuters are frequent drivers, but they have no interest in the art or science of performance motoring. They are casual drivers, even though they spend two hours a day behind the wheel. Many people are casual users of their cell phones, even though they use them daily. Being a casual user is not about how often you use something, but how interested you are in improving and perfecting your knowledge and use of that thing.
I have been a casual JavaScript user for a long time. When I needed something twiddly on a web page, I would scrounge the web for a free bit of JavaScript that was close enough to what I needed and stick it in. But for the SPFE Open Toolkit, I realize I need to be more adept and create JavaScript that is specific the the needs of the toolkit. Last night, therefore, I became a novice — by which I mean that I bought a book and sat down to study JavaScript systematically.
As a tribe, technical communicators don’t seem to be very keen on casual users. When we decide to classify content by experience level, we usually use terms like “novice” and “expert”. I have never seen any classification schema that use any synonym of “casual” or that made any kind of distinction between novice and casual.
The casual user does nothing to satisfy the technical communicator’s desire to teach, or their desire to be read. Novices are much more satisfying to write for. Thus we may fancy that when new users open their brand new widget, the first thing they are going to want to do is sit down and read an 80-page tutorial.
Minimalism, while it recognized that the new user probably is not going to read the 80-page tutorial, is also based on the assumption that the reader is a novice, not a casual user. It is, after all, based on university studies of adult learners, not university studies of adults doing everything they can to get a job done without having to learn anything at all. (That would be a cool study. Someone should do that.) Minimalism may be a more reasonable approach to novices, but it is still specifically aimed at novices.
This is not to say that there are no writers who write for casual users, because there certainly are many who do so. These writers often focus on very precise and detailed procedures for a fixed set of operations. They do not ask broader questions about the user’s task or purpose. They do not invite further exploration. They do not imagine that the user is going to learn this procedure, just do it and forget it. And if their users are casual users, and if they have enumerated the fixed set of operations correctly, these writers serve their readers well.
But it seems to me that we need to pay much more attention to whether we are writing for casual users or novices. As a novice, a procedure written for a casual user is very frustrating, because it does nothing to advance your knowledge or mastery. It gives you no way to go beyond the literal steps described in the text.
For a casual user, equally, being given a text written for novices is maddening. It tries to teach me stuff, when I just want to get my job done. It invites me to explore, when all I want to do is push the right button. It confuses me and wastes my time.
If you are producing consumer devices, chances are most of your users are casual users (no matter how frequent their use might be). If you are producing industrial tools, then your new users are likely always novices, not casual. If you are producing office software, experience suggests that you have something approaching a 90/10 ratio of casual users to novices. There is always that one person in the office who really knows how to make Excel sing. He began as a novice and became a master. Everyone else is a casual user and intends to stay that way.
What casual users like is a label on the object with precise instructions.
The Web does a great job of catering to novices. It creates a colloquium of novices and masters and preserves a record of their interactions so that novices who come later can benefit as well. The Web does not always serve the casual user as well, not so much because the answer they need is not available, but because it requires some qualifying work on their part to figure out whether to trust the procedure they have found, which is more intellectual work than a casual user is generally up for. What a casual user really wants is a label on the object itself with simple step by step instructions.
One thing the web does do well for the casual user is provide access to instructions for off-label uses of products. Want to know how to use your stereo speakers to excite non-Newtonian fluids. Sony’s manual is silent. The Web will tell you how.
Another audience that is not always well served by the Web is the master. In some ways the web is great for masters, because it lets them find and communicate with each other. But the Web does not seem to do a good job of producing the kind of good in-depth reference material that masters need. (For instance, the Web does not contain a single good XSLT reference. There are lots of crappy ones, but if you really want to program in XSLT you need to get copies of Michael Kay’s Programmer’s Guides for XSLT and XPath.)
Two thoughts then:
- Technical communications needs to pay much more attention to the difference between novices and casual users, and their very different information needs.
- Tech comm has traditionally focused mostly on novices. But novices are increasingly well catered for by the Web. Perhaps we need to turn our attention to serving those users the Web does not serve as well: casual users and masters.
Mark, I absolutely agree that not enough attention is paid to casual users. And I’m not too keen on the “expert” designation either. Especially when you have a product that’s used in many different ways by different people, it doesn’t make much sense to talk about a single category of advanced or expert users anyway. And unless you are actually writing a coursebook, it’s not helpful to imagine that users will start as absolute beginners, work through your materials, and end as bona fide experts.
Still, while the “course of study” approach is often not very helpful, I think it’s worth making a distinction between something that assumes you’re going to refer it every time you do the task (a job aid), and something that helps you learn the necessary knowledge and then gets out of the way. In many cases, the latter is preferable. We don’t need to maintain a reference guide in our heads, but it can be very helpful to internalize commonly used tasks.
And this leads us to minimalism, which is about enabling people to go from where they are now to where they need to be, and doing so in a way that encourages exploration and aids retention. (It’s *not* about patronizing, hand-holding procedures written in excruciating detail, nor about oversimplifying and dumbing down everything.)
As taught and practiced now (though it’s practiced less commonly than you might think!), minimalism starts with a look at who your various users are, what their roles are (where appropriate), and what they actually need in terms of guidance. Here’s a relevant passage from Carroll and van der Meij’s Ten Misconceptions about Minimalism:
“… the principle of getting started fast could suggest that minimalism is applicable only to the earliest stages of learning. But in fact one can get started fast anywhere along a learning trajectory. And the minimalism claim is that this indeed is what learners prefer to do…
Similarly, the minimalist principle of exploiting prior knowledge could suggest that minimalism is applicable only to domains people are already familiar with. But in fact, adult learners always have relevant prior knowledge and cannot help but engage it when they try to learn. The issue is not whether there is prior knowledge, but helping the learners to identify what prior knowledge is relevant, and how. Misinterpreting the principles along these lines could lead to the conclusion that minimalism is suitable only for instruction in simple (and known) domains and only for instructing the first-time user.”
Another misconception about minimalist writing is that it lacks conceptual and reference information. It doesn’t. For sure, tasks should not be broken up with *irrelevant* info such as asides on particular engineering approach taken lists of self-explanatory option labels. But when users land on a page, they need to know what the information on the page is about and how it relates to other aspects of the product and their tasks. They need very easy access to additional relevant information. This is all completely in according with minimalism not only as currently taught and practiced, but also originally theorized and researched.
Regarding the web not always serving masters very well, that’s an interesting point. While there’s a comparative lack of reference books on the web, there are certainly a lot of conversations between people at “master” levels of knowledge. This kind of information might not provide a sound conceptual framework, but it can certainly help fill in gaps.
As for the web catering well for novice users, yes and no. I have something coming up that you may find interesting.
Hi Joe,
In saying that Minimalism was aimed at novices, I was not intending to suggest that its was not also aimed at intermediate and advanced learners — it certainly is. My point was that it is aimed at learners, not do-and-forgetters. The do-and-forgetters do want patronizing, hand-holding procedures written in excruciating detail, and do want things simplified and dumbed down as much as possible.
I’m with you too, on not being particularly keep on the term “expert”, particularly as a metadata label for content. For one thing, people chronically overestimate their expertise.
For another thing, people consult docs because they have been assigned a task. They are not going to go back to their boss and say, “Sorry, I can’t do this, the manual says its an expert task, and I’m only intermediate.” They might decide for themselves that the task is too hard for them, but they certainly don’t need us telling them that it is. (Indications of the inherent difficulty of the task, however, such as are common in do-it-yourself car service books, can be a great thing, because they judge the task, not the reader.)
Finally, there is the question of what expert means. Does it mean expert in the craft, or expert in the tool? The expert-in-craft/novice-in-tool has different information needs from novice-in-craft/expert-in-tool. (Again, labeling the inherent difficulty of the task, rather than labeling the user, avoids this problem.)
I think we are also in agreement when it comes to the “coursebook” approach that some manuals take. Just because the user begins as a novice (and is therefore set upon a path of study) does not mean that they are looking to us to lay out a curriculum for them. One of the corollaries of minimalism is that adult learners prefer to chart their own course of studies.
Sometimes they may turn to a course or a textbook to shape their initial study, but in many cases they prefer to learn by doing and to gradually build up their overall knowledge and mastery. Even those who choose a text book to start do most of their real learning this way. (Real education, it is widely held, starts the day you leave college and start doing real work.)
Besides which, while experts may be similar in their knowledge and experience, every novice is different, starts from a different place, and has different information requirements. We serve them much better by providing a collection of Every Page is Page One topics that they can use as an when it suits them as they chart their own course of learning.
Of course, an Every Page is Page One topic for a novice will be different from an Every Page is Page One Topic for a casual user.
Hi Mark, thanks for the reply. I do agree about coursebook approaches too. Users choose how much or little they want to learn, and in what order. I know of only a very few non-tech writers who read right through the manual, and I suspect that some of them do it out of a sense of duty.
I also agree that many users want clear and unambiguous walkthroughs rather than being guided to figure things out for themselves. I think it would be fair to say that much minimalist documentation today is less exploratory and tutorial in tone than the original minimalist works such as the Smalltalk user guide, and hence more suitable for these users.
In addition, most users have a strong preference for procedures that are as short and simple as possible. They don’t like to plough through irrelevant verbiage, and that includes already known information. We have to look at the nature of the task, and the kinds of users who typically want to do that task, and make some good judgements about the level to pitch it at. That’s really what I meant by avoiding patronization. So this clearly relates to minimalism — the understanding of users and their goals, and the subsequent development of content at the right kind of level.
And there’s another thing that minimalism can contribute. Instead of assuming that users will follow a long string of steps exactly and their environment is the same as that in which the procedure was written, minimalism aims at smarter error correction. It aims to alert users to common mistakes as they happen, or shortly afterward, rather than giving a long list of undifferentiated steps and blaming users if they miss or misunderstand one.
The other thing I would say is that a single user may have different attitudes to learning, depending on the task at hand. If it’s a complicated one-off procedure, it obviously falls squarely into the do-and-forget category. But if it’s a frequent task, or a kind of template task that is repeated often with minor variations, many users are more interested in learning it. So here again, minimalism can play a role.
Hi Joe. You don’t have to sell me on minimalism. I’m a big fan, and a big booster. One of my mottoes for a long time has been “minimalism, modularity, and markup — in that order”.
So yes, I agree that compared to textbook-style documentation, minimalist documentation will serve the casual reader much better. Both styles, after all, are based on the assumption that the user’s task is to learn the system, so it’s not like minimalism looses something in this regard compared to text-book.
But my point remains that minimalism as a whole is based on the presumption that the user’s task is to learn. It is not specifically oriented to casual users. It is specifically oriented to novices. Of the two styles of documentation that are oriented to novices, it serves casual users far better.
But there remains a danger that a training in minimalism will encourage writers to always regard their readers are novices rather than casual users. In this there is a danger that they may produce documentation that, while it may support casual users better than textbook style documentation would, is nevertheless not optimal for casual users.
This matters, because a casual users is far more likely than the novice to be get frustrated quickly, and is far more likely to respond to frustration by abandoning the product altogether. A very small difference in the frustration threshold could make a massive commercial difference in terms of sales, up-sales, repeat sales, and word of mouth.
I intend no slight to minimalism then, when I say that sometimes we should look beyond is presumptions and its default techniques to optimize for the casual reader where appropriate. No tool or technique, however powerful and virtuous, is optimal in every situation.
Hello Mark,
It is really a well crafted article. In technical communication, we do categorize users in Novice and Experts, but I do agree with you that there are Casual users who are in majority. And, we must start thinking about these casual users before writing.
Regards
Hi Shivanjalee. I think it very probable that casual users are in the majority in the consumer products space — and that many writers may be incorrectly treating them as novices. The question becomes more murky in the tools space. Tool users may be either casual or novice users, which I think requires a degree of thought and research for people writing tools documentation.
Thanks for the clarifications, Mark. I agree that casual users are more likely than novices to get frustrated quickly, and if frustrated, abandon either the product, or at a later stage the brand. In fact I agree with most of what you’ve written. You don’t leave me much to argue about. 🙂 I’ve just had a response published to your review of “Too Big to Know” in the CIDM e-newsletter (http://www.infomanagementcenter.com/enewsletter/2012/201206/third.htm). If I’d written the response after this discussion, it might have been shorter.
I do think that minimalism as taught and practiced now is suitable for casual users, firstly because it lacks the overtly tutorial emphasis of early minimalism, and secondly because doing proper user analysis should result in catering for one’s actual users anyway. And minimalism can and should include the “why” (at least the relevant “why”).
But I think my main remaining quibble is on the extent to which “The Web Does Minimalism”, as you put it (/2012/02/06/the-web-does-minimalism/). I do agree with you that we’ve progressed from the paper era where information was scarce and authority was based on that scarcity, to a connected world where, as Weinberger puts it, “the richness of the overall web of content and links enables a healthy mix of types of content-based networked expertise.” But I don’t think that there are many cases in which good minimalist information design can’t make a positive contribution, alongside community content. It can play a very important role in filling in information gaps and hence reducing user frustration and driving loyalty. A large chunk of my CIDM piece was on this. I’d be very interested to hear your thoughts.