Not My Best Work

User Manuals are Maven Traps

2008-12-27T09:24:00.002-05:00

In his afterward to The Tipping Point, Malcolm Gladwell writes about maven traps, "a way of efficiently figuring out who the Mavens are in a particular world." He says that "how to set Maven traps is one of the central problems facing the modern marketplace."

I think user manuals are Maven traps. How often have we heard that no one actually reads user manuals? Compare that sentiment to this from Gladwell:

In the midst of all the product information [on the back of a bar of Ivory soap], there is a line that says: 'Questions? Comments? Call 1-800-395-9960.' Who on earth could ever have a question about Ivory soap? In fact, who on earth would ever have a question about Ivory soap so important that they felt compelled to call the company right away? The answer ... [is] the soap Mavens, and if you are in the soap business you had better treat those soap Mavens well because they are the ones whom all their friends turn to for advice about soap.

The people who read user manuals are the rare software users who want to know everything about how an application works. They read Word's help to find out in complete detail how tables work in Word; then when a colleague calls them over because a table is misbehaving in a Word document, the Word Maven can help. They love to help—at least, according to Gladwell. They love to soak up as much knowledge as possible in an area and then share it with others.

This means a few things for technical writers creating user manuals.

First, and most commonplace, it means that even though most users will never look at the manual, the information in the manual is nonetheless the primary means of dissiminating information about the software to users. It just doesn't happen directly. It happens through the intervention of Mavens, who will read the manual in detail and then pass the relevant info along when a friend or colleague has a question. This isn't a new idea, many others have mentioned something similar before.

Secondly, it means we should reconsider who we're really writing manuals for. Often technical writers bemoan the fact that "no one" reads the manuals, and work to broaden their appeal so that more users turn to them more often. These efforts might include omitting obscure features, making manuals increasingly task-based so users can get out of the manual and back to work more quickly, including more videos or more attractive, brochure-like graphic design. All of which makes the manual less appealing to Mavens. These are people who subscribe to Consumer Reports magazine and write detailed product reviews on Amazon. They want detail. They want to understand. They're our core audience and we should cater to them first and foremost.

Finally, it means we have a new way of justifying the importance of technical writing in an organization. This is the "trap" aspect. In The Tipping Point, Mavens play a crucial role in the spread of social epidemics, including the success of products in the marketplace. One of the challenges organizations are faced with is identifying the Mavens among their customers and getting in touch with those people. Technical writers are doing that every day; we're doing it better than anyone else in the organization. Our user manuals are one of the few things put out by our company that Mavens will gravitate towards and trust. We have a direct line to these people, and the better we treat them, the more likely they will be to recommend our products to their friends. (And as Gladwell points out, when a normal person recommends a product to ten people, maybe 2 or 3 of them listen and try it out. When a Maven does the same, all ten people try it because the Maven is usually right about these things.) That's a powerful reason for a company to invest in technical publications.

Another unnecessarily confusing interface

2008-07-28T21:30:00.005-04:00

I checked in for a flight last week using a self-serve kiosk. When I first approached it said "Touch screen to begin," so I poked the screen. It beeped and displayed a second screen that said something like "Choose an option" and listed five methods for identifying myself—swipe a credit card, swipe my passport, scan a printed boarding pass, and two others I can't remember. Each of the five options was displayed inside a large square box that looked like a button or a three dimensional frame. I wanted to use my passport so I poked the screen inside the passport area. The screen beeped and nothing happened. I assumed it was just slow. I waited but still nothing happened. I poked the screen again. Nothing. I poked it again. Still nothing.

Eventually I decided to try swiping my passport. I opened it up and found a bar code type area and swiped that, but it didn't work. I swiped it a couple more times, varying the speed and direction, but still nothing.

I poked the screen again. Beep, and then nothing.

I studied the picture inside the button more closely and tried to orient my passport the same way as in the picture, and swiped it again. Finally the machine recognized my passport and a new screen was displayed. From there things went smoothly.

But that was needlessly frustrating. Why make the options look like targets if I wasn't supposed to touch them? Why hide the list of options behind a "Touch screen to begin" page, priming me with the idea that I interact with this device by poking the screen, instead of just listing the options on the front screen so I can swipe my passport before interacting with the screen? It was like the interface was designed to lead me astray.

Perhaps the best redesign would be to go with the perceived affordance of touching the option you want to use, and show a second page saying "Swipe your passport in the slot above." Then there would be enough room to show a video of a passport being swiped and a picture calling out the part of the passport that the machine wanted to read, so I wouldn't have had to try to guess from a tiny iconograph how I was supposed to do the swiping.

How do you test what someone doesn't expect to be able to do?

2008-07-07T17:35:00.004-04:00

Interpreting the results of a usability test is tricky at the best of times, but in a study I recently conducted I found that it's even more difficult when the feature you're testing is something your users don't expect the software to be able to do. In this type of situation, the interface has to reveal the software's capabilities to the user in addition to making those capabilities easy to use. That's an additional constraint on the design. (Normally the user expects to be able to accomplish something with the software, and the interface's task is to match the user's mental model—their expectation of how the feature should—as well as possible, or to bridge the gap between their mental model and the system's implementation. In this case, the user has no mental model, or their mental model doesn't extend that far.)

So how do you test something the user doesn't expect to be able to do? And how do you interpret the results?

I can't discuss the details of my test but I can use a roughly parallel example. Imagine you were testing the Smart Playlist feature in iTunes (the ability to create a playlist that automatically fills with songs based on criteria you set, like genre, artist, rating, or any combination of attributes). Many iTunes users I know have never heard of this feature. If you were testing it, what would you do?

What we decided to do was give them a scenario that we thought would supply the expectation for them. In the iTunes example, this might be something like: "Create a playlist that automatically includes all of your Rock songs from the 1980s."

Now imagine that all of your test participants immediately tried searching for 1980s Rock songs in their music library and then looked for a way to add these to a playlist. And when you informed them that there was another way to complete the task, they tried creating a playlist and calling it "1980s Rock."

In this case, the scenario seemed to prompt the participants to imagine capabilities the software doesn't have (saving search results as a playlist, filling a playlist based on its name), instead of the one it does have that they didn't expect.

Does that mean the Smart Playlist feature is difficult to use?

I don't think so. It seems like anyone who discovered Smart Playlists would bypass the confusion that was uncovered during the tests, and discovering it in context would do a better job at setting their expectations about it than the scenario did.

In short, it seems like the scenario created the confusion, and thus the difficulties encountered in the task really tell us little to nothing about the usability of the feature we set out to measure.

I'll have to try something different next time.

A glimpse behind the walls at Cooper

2008-07-04T18:46:00.006-04:00

This video shows how Cooper uses Adobe Fireworks to do their interface design. It also provides a glimpse into how they divide the design tasks between an interaction designer and a visual designer.

I don't know much about Fireworks, but it looks like it might allow you to prototype interactive designs. One of the things I find most difficult about designing in Visio is that the screens are all static; it's very difficult to document a more complex in-page interaction with a tool like this. It's also difficult to work out the interaction in the first place without a tool that lets you quickly build it and try it.

I also like how they've divided the work involved in designing and developing software into discrete specialties. I think the level of polish and sophistication they're able to obtain as a result is the best answer to 37signals' argument that Web designers should also be web developers.

Is reading changing?

2008-06-30T17:07:00.006-04:00

Allegedly people are learning a new way of reading, thanks to the internet, which would better be described as skimming. Tony Karrer defends this change:

Yes, we need opportunities to reflect, but for me that's blogging. I'm reflecting on his article as I write. But, indeed, I skimmed through passages.

I’m skeptical that skimming + blogging is as good as careful reading in the first place. I suppose with blogging there’s no accountability to master the material, so you can get a way with skimming and take away whatever you like from a piece without needing to accurately grasp the author’s arguments or position. Perhaps skimming is good enough, then, for what Mr. Karrer is trying to accomplish.

Bit if reading does change to skimming, should writing change to accommodate? Where does that leave the types of writing that aren’t amenable to skimming, like the development of a complex argument or a narrative?

Experimental Philosophy?

2008-06-25T21:13:00.005-04:00

A post over on the Mind Hacks blog discusses the possibility of an "experimental philosophy." What would make this philosophy, they argue, is that that it would seek new empirical data that could weigh in on questions philosophers care about.

That's not philosophy. Academic disciplines are defined by their methodology, not the topics of interest to current practitioners. That's why you can have a philosophy of science and a sociology of science and distinguish between them.

This reminds me of a story one of my philosophy professors once told. He was at a party and got into a conversation with a physicist who, upon learning that his conversation partner was a philosopher, asked with some consternation, "What do you take as you data?" Maybe you have to be a philosopher to find that funny, but that's just my point.

An answer to the Easterlin paradox

2008-05-21T08:07:00.005-04:00

In Stumbling on Happiness, Daniel Gilbert writes about a study where:

[R]esearchers telephoned people in different parts of the country and asked them how satisfied they were with their lives. When people who lived in cities that happened to be having nice weather that day imagined their lives, they reported that their lives were relatively happy; but when people who lived in cities that happened to be having bad weather that day imagined their lives, they reported that their lives were relatively unhappy.

This seems like a good answer to the Easterlin paradox. If today's weather has a big influence on my assessment of how satisfied I am with my life overall, then obviously asking people how satisfied they are with their lives is not, in fact, a good measure of how good their lives actually are. So a failure to find a correlation between people's self-reports of their overall life satisfaction with their level of wealth proves nothing. Maybe driving an Audi R8 does make your life happier, you're just not always cognizant of it. Like, for example, when it's raining, and you just got back from walking your daughter-in-law's dog who you're dog-sitting for the weekend, and you get a call from a telephone research person asking how happy you are about your life as a whole, and your hair is still wet and it's dripping on the floor, and you're cold.

Disentangling some ideas about personas

2008-04-27T10:21:00.006-04:00

I've been reading a lot of debates and discussions around personas lately—whether they're an effective tool in interface design or not, and what is the right way to create them. I think when people write about personas they often blur together two ideas that are in fact separate. Personas are really a technique for synthesizing research data and presenting it in a sticky way. This is separate from the research methods used to gather the data.

Normally we use techniques like field studies, site visits and other qualitative research methods to gather data about how our users will interact with our products, what their needs and goals are, the environment they work in, etc. But there's no reason why findings from this sort of research need to be presented as personas. They could be presented in a number of other ways depending on the audience, purpose, skills of team members, etc.

The advantage of personas is that they present information in way that is clear, memorable, and actionable. Here's the important thing: you would get these same benefits regardless of the source of the information behind the personas. Normally people associate personas with the types of research mentioned above in order to get accurate or correct information about users, but getting correct information is really separate from presenting information in an effective way. Often people advocate for personas on the grounds that they are a good antidote for the elastic user and the "featuritis" that results from a lack of clear focus during design and development—but you get the benefits of increased focus regardless of whether the personas are backed by thorough qualitative research or by the hunches of front line staff.

So when people argue in favor of personas they're often really arguing several separate things:

That a certain type of information about users is needed to develop good products (namely information about goals, needs, attitudes, etc.)
That a certain type of (usually qualitative) research is the best way to obtain that information
That personas are the best way to synthesize the information after it's obtained and present it to the team working on designing and developing the product

Someone could reasonably object to any one of these points. By blurring them together under the concept of personas, it makes it difficult to understand that objection. It also makes persona adoption an all-or-nothing sort of thing, which may be harder to implement in an organization, and may also lead to missed opportunities (for example, an organization might miss out on the benefits of qualitative research because it is turned off by the idea of presenting that research as a persona).

Defending the book

2008-04-19T13:24:00.006-04:00

Jay Cross (no relation to this author) recently posted some disparaging comments about The Book to explain why he won't be writing books anymore and will instead work on something called The Unbook. Like so many writers advocating for things like "Learning 2.0" and other shifts in the way we work, think, and learn based on Web 2.0 technologies and the ideas behind them, Cross makes a straw man out of the current way of doing things—in this case the humble book.

I'll pick one of his characteristics of The Book as an example: Passive Readers. Of course, passive readers is a bad thing and The Unbook is supposed to have "participants, not readers," which is a good thing. Nonsense. The fact that readers aren't involved in authoring a book doesn't mean that they're passive. We highlight passages, dog-ear pages, and write notes in the margins where we agree or disagree or just think of something else triggered by what we've read. We write reviews, or give talks, or write papers, or even write our own books in response to what we've read—not just in one book but in many different related books. Which also, actually, calls into question Cross's claim that The Book is "unlinked" and not "networked." Books are actually quite thoroughly networked through references and foot notes and bibliographies going back in time, and by being referenced and mentioned by other works going forward.

What a book provides is the time and space for an author to develop a complex, nuanced, subtle, sweeping connected series of thoughts and arguments to create a whole that is more than the sum of its parts. Some thinkers—and Cross doesn't say this but it seems to be lurking in the background—seem to believe that this whole can be equally well created through a series of evolving thoughts expressed in smaller doses all over the place, by multiple people working in multiple media. I just can't see it. Think of the scale of something like Jared Diamond's Guns, Germs and Steel. Whatever you think of the arguments in that book, there's no denying the monumental amount of work involved in tying together so many ideas from so many distinct areas to create a consistent, comprehensive whole that expresses a theory that simply didn't exist in the individual parts. We have no medium for the creation and transmission of something like that other than the book.

Emotionally Intelligent Tech Writing?

2007-09-17T20:03:00.000-04:00

I recently watched Dan Pink's pecha kucha presentation about emotional intelligence in signs. An emotionally intelligent sign is one that expresses empathy toward the reader. It made me wonder if we could have emotionally intelligent technical writing—writing that expressed empathy toward the user.

This might be easiest to imagine in the interface itself, maybe in an error message. When Word crashes, perhaps the message could say, "We're sorry, we made a mistake in our code and you've just stumbled into it. Word will have to close, but we'll do everything we can to protect your data. We'd like to fix this so it doesn't happen again, and it would help a lot if you could send the data Word captured just before it crashed." That's probably too long, but maybe that's what it would look like, more or less. It feels refreshingly honest, doesn't it?

What about in a message that isn't an error? Take empty search results. Usually we write something like "No files [or records or web sites or whatever] match your search criteria." That's fine—it's clear and polite, and that's what we usually strive for—but it isn't very helpful. If I'm looking for something, and whatever criteria I use don't turn up any results, I'm probably frustrated. Getting a "no results available" message is like getting a Game Over in the arcade. Drop in another quarter and try again. What if the message said "We can't find any files that match all of your search criteria, but there are 12 files of other types that match and 23 files without the word vacation." Maybe that would show some empathy with my situation by trying to offer help and also showing me that I might be close to finding what I want. It's also closer to what I would expect from a helpful librarian if I asked whether her collection contained any items that matched a certain description.

(Writing this message also lead me to think of providing extra functionality in the form of search results for similar queries. As is often the case, the writing and the design can help one another.)

What about external documentation, like an installation guide or user guide? I've mentioned my Seagate external hard drive previously; the package contains one short setup guide with just four words on the cover: "This won't take long." That's empathy. Think about it, by the time I get my new piece of hardware home and unpacked, my biggest anxiety is will I be able to get this working and if so how long am I going to have to spend on it? The cover puts me immediately at ease.

But it's probably too cute for most situations. What about something like Word's help for using Styles? The help system for my copy of Word XP has a topic called About formatting text by using styles that begins, "A style is a set of formatting characteristics that you can apply to text, tables, and lists in your document to quickly change their appearance." That seems okay, but it doesn't really express any empathy with how I might be feeling. I'm probably feeling frustrated, strapped for time, and anxious to know whether what I'm reading about is worth my time and whether it will solve my problem. Maybe an opening like this would work better, "If you haven't worked with Styles before, it will seem counter intuitive and it will take some time to learn. It will also take time to set up the Styles you want to use. But if you regularly create documents that share the same formatting and you want to make sure a document's formatting is consistent throughout, styles will do the trick and save you time in the long run."

Again it feels cutesy and it's longer, but maybe it has more warmth and maybe readers would respond well to that.

There's one other situation where we could express empathy: where we're forced to describe a feature that is awkward or obviously compromised. As technical writers writing on behalf of a company, we generally think we have to put the best face on a feature as though it made perfect sense and worked just how the user wanted it to. But maybe we lose credibility that way. Maybe we should just say, "It would be cool if you could save your search criteria. For now the best way to do that is to copy the text from the search field and save it in a text file. That's why the search field supports copying. It's not elegant, but it gets the job done for now."

Would that be so bad? What's wrong with a user guide—or a company—that sounds like a human being?

Handling Suggestions

2007-09-08T11:35:00.001-04:00

I'm the sort of person who always has ideas about how things could be better—or at least different. Most of them I can't do anything about, except to pass them along to someone else in a position to consider them.

On the flip side, as a technical writer, many of the best suggestions for how to improve the work I'm doing come from other people. I lose sleep at night sometimes thinking about the suggestions that go unsaid, the great ideas that never make it to my inbox.

So I think the way we handle the suggestions we do receive is tremendously important. And from what I've seen, as someone who makes a lot of suggestions, most people don't know how to handle them.

Think of it from the perspective of someone offering a suggestion. When you pass along a suggestion to someone (something you don't have to do, and there are always other things you could be doing), what do you want?

Validation – the sense that your idea wasn't completely silly
Appreciation – a little thank you or some recognition that you didn't have to take the time to articulate the idea and pass it along
A clear hand off – the feeling that you've done your duty and got the idea into the right hands so you can forget about it and get back to your own work

What does it take, then, to reward someone for passing along their suggestion and to encourage them to do so again? Just a simple thank you with some indication that the idea's worth considering and that you will in fact give it consideration. "Thanks Bob, what a great idea! I'll bring that up at the next team meeting."

Simple, right? But hardly anyone does this. Some people respond quickly with a detailed explanation of why the idea won't work. Ouch! If the explanation's correct, you've basically just told the person their idea sucked and thanks for wasting your time. But if the explanation's not correct, and you've missed the point of the suggestion by dismissing it too quickly, then the other person will either get drawn into a debate about the merit of their idea or they'll believe that you're incompetent. In any case, you're not likely to hear from them next time.

Some people respond with detailed instructions about how these sorts of suggestions are supposed to be filed—forms to be filled out, additional information to be provided, process to be followed. Hey, wait a minute, I'm doing you a favor here and you want me to invest a bunch of extra time? Like I'm not busy? No thanks.

Some people don't respond at all, or they say "Hey great idea" but you know they don't know what to do about it. In any case you feel like you've just tossed your suggestion into a bottomless well.

Finally, some people follow up diligently but continue to involve you in the process because it was your idea. They send updates and ask if they've understood correctly and ask what you think of the result. How are you supposed to know? If you had the skills or expertise to implement the idea, why would you have passed it on in the first place?

So next time you get an unsolicited suggestion from someone, thank them for taking the time out of their schedule to pass it along, show some appreciation for it, and let them know (firmly but politely) that you'll take it from here because you've got a system for handling these sorts of ideas.

And if you don't have a system for setting aside new ideas and reviewing them regularly, you need to make one. You're missing a hell of an opportunity.

The Importance of Packaging

2007-08-28T22:00:00.001-04:00

The last time I went grocery shopping I bought a new type of muesli. I wasn’t shopping for cereal. I was crossing through the cereal aisle and this series of unusual boxes caught my eye. The boxes are each roughly the size and shape of a Kleenex box, have a matte finish and die cuts on the front and side that show you the real cereal inside (not an enlarged idealized photograph of the cereal as with most boxes). The cereal is made by Dorset Cereals, and the product lives up to the packaging.

But it’s the packaging that really delighted me. I bought the product for the packaging—I admit I’m always looking for a good muesli, but I wasn’t looking for one that day.

The copywriting on the box perfectly complements the design. Take the weight, for example, which is labelled as “750g of unadulterated breakfast pleasure.” Cute, whimsical, without being cliché or saccharine. Something about the writing combined with the window into the contents convinced me that the packaging was sincere, that this company cared as much about making a good breakfast cereal as I cared about eating one.

I wish more companies paid as much attention to their packaging. The author of the Desi Geek blog writes about the packaging Seagate uses for the Simple Drive external hard drive. I bought a Simple Drive after reading this blog, again largely for the packaging. So far it’s been a great piece of hardware, but I was more impressed with the attention to detail in the packaging. One detail the author doesn’t mention is that the stickers used to close the various bags inside the box all have the word “hello” printed on them. It made the process of unpacking an otherwise utilitarian device enjoyable, like finding a note in your lunch from your spouse wishing you a good day.

Is buying products because you like their packaging stupid? Tyler Cowen is trying an experiment with books, buying books where the cover appeals to him without reading anything about the book. So far it’s working. His theory is that professionals who design the covers put a lot of effort into making the cover appeal to the people most likely to enjoy the book, so if we pick a book with a cover we like, we’ll tend to like the book, not because there’s a necessary connection between a book and its cover, but because there are teams of people working very hard to ensure such a connection exists. Why not trust them?

Maybe it’s the same with the cereal. On the other hand, maybe the packaging actually improves my experience of the product. Think about it however you like; maybe it puts me in a good mood when I pour the cereal into my bowl, or maybe it creates the right frame for the experience (they say you get what you expect out of something and here the packaging sets a good expectation). I’ve heard that experiments show that food actually tastes different depending on the packaging it comes out of, but I’ve never actually seen the evidence. In any case, the packaging seems likely to influence my subjective experience of the product, so I’ll think the product is good whether it is or not.

Then again, maybe that subjective evaluation is all there is. If so, if there’s no objectively good cereal, then the packaging might have as much an impact on the taste as the ingredients do.

The same could be true of books: the book’s cover and other features (its binding quality, typeface, margin sizes, etc.) might affect your perception of the book, the way attractive people sound more interesting even when they’re saying something mundane.

Is more choice better?

2007-08-26T07:47:00.000-04:00

I recently read the excellent Paradox of Choice, by Barry Schwartz. Schwartz argues persuasively how a world with 29 different types of pasta sauce to choose from leads to anxiety, depression, and other problems. After reading the book, I began to think that happiness depended on reducing the number of options before us, either as a society or artificially as an individual.

Then I encountered Malcolm Gladwell’s TED talk about Howard Moskowitz, in which he argues, also persuasively, that having 29 types of pasta sauce to choose from has been one of the greatest contributions toward our happiness in the last few years.

So on the one hand, more pasta sauce causes anxiety and depression; on the other, it makes us happier.

Either one of them is wrong, or there’s a way to reconcile these views. I’ve been trying to reconcile them, and this is what I’ve got.

I think what Gladwell observes is that we now have enough types of pasta sauce to please everyone’s taste—if you can figure out which one you like best. What Schwartz observes is that figuring out which one you like best is exhausting, especially when pasta sauce is only one of 20 items on your grocery list, and grocery shopping is only one of your weekend chores.

Gladwell’s talk is a good tonic for the nostalgia lurking in the background of the Paradox of Choice. There are passages where Schwartz seems to long for the good old days of a more restrictive society where someone else decided what sort of sauce tasted good enough and you just bought the only one that was available.

On the other hand, Schwartz’s discussion of opportunity cost illustrates the negative consequences of the increased choice that Gladwell celebrates. The basic idea is this: If I really like chunky mushroom pasta sauce but I also like four cheese and spinach pasta sauce almost as well, then I’m robbed of some of my enjoyment of chunky mushroom because I know I’m not eating four cheese and spinach, and I know that would have been a good experience, and in a way I’m paying the cost of not eating it. In other words, the value to me of the best option is only as good as the difference between that and the second best option, which might be quite small. Plus I have the added stress of repeatedly making these kinds of choices.