“One Day I’m Going to Figure Out the Solution to Help…”
June 28th, 2011 | Posted in blog 42 Comments »
He mentioned this during one of our lazy afternoon meetings, which dragged on much longer than the scheduled time. The central problem of writing help, my colleague Derek explained, is how you make it so Joe user can find the answer to his one question among 50,000 other answers in the help.
Every user seems to have the one or two questions he or she thinks should be at the top of the help file, he explained. A lot of users think a help file only needs a few pages — listing the answer to two or three questions.
But project managers have one set of questions. New employees have another set of questions. Team members have their own questions. And team managers have other questions still. You can’t just address one user’s questions without deprioritizing other questions. And as soon as you start answering everyone’s questions, the help grows longer and longer. You start trying to account for all of these different questions and scenarios, adding more and more topics and notes and other information, and the help grows longer.
At some point, with so many topics, your help sucks. Either it becomes too long, and users dismiss it as a lengthy manual no one has time to read. If you reduce it to five pages, it also sucks because it doesn’t have relevant information for anyone.
Exactly, I thought. I’ve been trying to answer this exact same question! This is the central problem of help. It’s why I have 40+ posts on the topic of findability. It’s why I came up with my whole metadata plan, and faceted browsing, and so forth.
Then Derek shared an experience that opened my eyes. He said about ten years ago, when he was a new technical writer, he was incredibly enthusiastic. He read everything he could get his hands on, kept up with the latest journals and conferences. He had lots of energy and drive to learn everything he could about technical writing. He tried different approaches with help, always trying to figure out the solution that would make users happy. Once, during a meeting, he told his project team, One day I’m going to figure this help thing out. I’m going to figure out how to do help in a way pleases every user.
He later changed jobs and navigated his career path. A decade later, as he was interviewing at a local company, some of the same project members were there, and they were the interviewers. Near the end of the interview, his former team member said, Derek, so, have you figured out a help solution that satisfies all users?
Derek was at a loss for words. No, not really, he said. He mentioned the move to improve user interfaces, and how you have to go to the UI with the information users need. But he knew this was only part of an answer, not the answer.
Like Derek, I often say to myself, One of these days, I too am going to figure out the solution to help. I’ll come to the right solution that makes every user satisfied. I’ll find a way for Joe user and Suzy user and Sam user to find that one topic he or she needs among 50,000 other help topics.
And yet, I’ve been a technical writer more than half a dozen years, and I still haven’t come up with the answer. Is the answer to move towards usability and try to fix the UI, or embed your help directly in the UI? Is the answer to build a robust search engine, like Google, so that users can find what they need by searching? Is the answer to provide more video-based tutorials that guide users through problems visually? Is the answer to create quick reference guides that get users up and running? Is the answer to present a course that users progress through, one level at a time? Is the answer to provide informative graphics that communicate visual information to the user? Is the answer to get lots of SMEs writing the content, perhaps on a wiki?
I keep thinking that one day I’ll stumble across the answer. I’ll figure it out.
Mark Baker, who has also followed this problem diligently, writes,
Findability is an intractable problem. This does not mean that we should not try to improve findability. World peace is an intractable problem, but it is still worthwhile to make a friend. Climate change is an intractable problem, but it is still worthwhile to plant a tree. Findability is an intractable problem, but is it still worthwhile to add a keyword.
Still it is important to recognize the that the problem is intractable, lest we waste too much of our time and energy for too little gain. (Findability Is Intractable)
He goes on to explain the shortcomings of solving findability through taxonomy and other measures. His tone reminds me somewhat of Ecclesiastes, when he laments:
All the rivers run into the sea; yet the sea is not full; unto the place from whence the rivers come, thither they return again.
I wish I had more insight. Maybe a clever reader can fill in the gap. I fear that the answer might be a combination of solutions — similar to the answer of how one makes money on the web. Apart from building a wildly successful app, the way to make money online is by diversifying your income stream. You provide advertising, give presentations, do consulting, sell e-books, sell products, host webinars, create courses, host affiliate links, and do other efforts. Alone, none of these solutions amounts to much. Combined, they produce a decent income stream.
Perhaps help authoring is the same way. You write the quick start guide, you produce a series of screencasts, you record a podcast, you publish a reference manual, you embed help in the user interface, you provide e-learning courses, you build a robust search tool, you create a meticulous index, you provide several main entry points (beginners, troubleshooting, scenarios), you even put a little Chat Now box in the app. You do all these things, and though none alone is the answer, together they meet 80% or more of the user’s needs.
That may be the reality of the problem. But it seems like a lot of effort, even if you can repurpose content from a single source. It seems so much more elegant to dream of the one brilliant idea, the one deliverable to rule all deliverables, or the magic trick that solves findability every time for Joe and Suzy and Sam, regardless of their scenario and individual needs. But that pursuit, like looking for the fountain of youth, might merely be a vain effort that keeps us walking past the answer, even when it is right in front of us.
Sponsors
Tags: Ecclesiastes, Futility, Mark Baker, Technical Writing
If you liked this post, keep updated with new content: Subscribe to I'd Rather Be Writing.
Both comments and pings are currently closed.
3841 Subscribers
Mark Baker (4)
Jen (3)
Richard Hamilton (3)
DiSc (2)
Jenny (2)
Sarah O'Keefe (2)
Aneesha (1)
Barrie Byron (1)
Catherine Crane (1)
D. Renn (1)
Spot on! No matter how well your audience is defined you can never meet their needs 100%. There will always we instances where someone who is not from your target audience will attempt to find the information. As a result, they may not get what they want, when they want it or in a format they understand. In the 12 years I’ve been a Technical Writer I’ve not found a solution either.
Colum, thanks for the comment. I think defining the audience is a critical first step in determining whether content meets that audience’s objective. I usually don’t understand my audience nearly enough, but that’s where information development should start.
Nice thoughts, Tom. Maybe we should approach it like science fiction writers: they start by envisioning the future they would like to see, and they leave the implementation details to others. The vision provides a framework for those who are tasked with finding solutions.
So what’s the future we’d like to see? I imagine it looks like Star Trek where someone just speaks and the computer (or other machine) responds appropriately. In that scenario, the help systems are a lot smarter, or at least a lot better at anticipating the user’s needs, than the ones we have today.
I don’t know how we get from here to there. But I really do think that things like semantics and web analytics hold a lot of promise. Sure, we’re just getting started and we’re still somewhat clumsy. But at least we’re doing something. We’ll learn from our mistakes and we’ll get better.
We might not achieve the ultimate goal in Derek’s lifetime, or yours, or mine. But we can get closer to it.
Larry, I like your approach of looking at the future. I think Apple had a specific vision of the iPhone (or something similar) about 15 years before its time. The solution may not be apparent now, but as long as we know the goal, the solution will eventually unfold.
Tom
Interesting post as usual. I find the HELP a lot like humans. Just as we continue to evolve as individuals, the ever changing user expectations and requirements of HELP give us *valid reasons* to continue evolving as professionals. It is a process.
I would rather not long for the day when I am able to find that perfect HELP. I would cease to exist as a technical writer that day. I would love to stay evolving.
Vinish, interesting perspective. I’m all about professional evolution. But I’m struggling to understand what you mean by ceasing to exist when you find the perfect help solution. Care to expand with more details?
Tom. Is there really a *Perfect Help*? If yes, we need to know how long it remains *Perfect*? Once we have a *good* Help and a general survey from users or customers suggest that the Help serves the basic purpose, all stakeholders are satisfied. However even at this stage, I assume that we can have one or more of following scenarios:
- Soon there are new users who start using the HELP file and hence they have new reasons/ways to find and explore the topics.
- Another version of product is released and the HELP needs to be updated.
- The old *satisfied* users feel the need of a flow diagram to understand the order-invoice life-cycle.
I feel that a technical writer’s experience with the HELP is like a relationship with spouse. Once I buy an apartment, a big car would be really nice. Once I have the car, a bigger office would be nice to have. Then a mac. And so on.
The expectations are from the relationship and from self also. What would drive me when I have nothing else to buy or achieve? The key is that I enjoy the process. So although I loved at the effort and the HELP that I have at hand, we always strive to evolve and make it even better.
Regards
Vinish G
Vinish, thanks for expanding your argument with more detail. I can better understand your perspective now. If we feel we arrive at the perfect solution, we stop evolving and progressing towards a better one.
Yes, this is exactly what I meant! I am never looking for the *perfect* HELP, I always try for a *better* HELP document.
Cheers!
Vinish
I believe that the problem does not lie solely in ourselves as tech writers. Oh, sure, as I read through your excellent list of ideas, Tom, I smiled at each one. Nodding, I recognized each one as a valid strategy that I’ve tried to some extent or another. And I do think that as a profession we need to pursue all of them, and probably some we haven’t even thought of yet.
But the bigger issue is one we can never solve. People who come to our help are in a disadvantageous position. They can’t do or don’t know something. We’ll never change that reality. Learning is hard and, almost more importantly, requires humility. At best, we can ease that process by doing everything Tom mentioned to account for different learning styles and varied information requirements.
Tech writing is not easy and never will be. But that’s what makes it fun.
Anne, good point about learning. It is painful. The day when people can simply upload information into their brains like installing a computer program is probably well into the future. Maybe the struggle to make help satisfying is really the struggle to help make learning fun, which is no simple task. It can be done, though. My 10-year-old daughter hates math but had a blast at math camp. She can’t wait to go again next year. They did a great job presenting real-world situations (e.g., lemonade scenarios), hands-on activities, group problem solving, etc.
Great pondering questions, Tom! We’re all mulling over this problem and its evasive solutions. The approach you describe is akin to what the training/ISD community calls “blended learning,” which attempts to meet the demands of so many learning styles and preferences.
What toolset did you end up using to implement metadata and faceted browse? If I remember correctly, you had settled on a wiki-based solution, but your content was eventually ported to a CMS. If I’m right, do you still have control over aspects of findability on the CMS side?
I’m simply curious about how often back-end developers are giving some control to those of us with more user-facing roles. In my last FT job, I was able to add some metadata directly to the CMS, but not with the flexibility that I had hoped for.
Eddie, I need to fill in the gaps with that. Turns out that even if you have an XML database, the wysiwyg authoring interface that allows you to add content to the database is probably so dumbed-down that it’s not possible to customize the XML tags as you like — at least that’s been my experience. I am not sure how much I can or should write, but basically the solution did not turn out as I expected. It was not possible, in the first version at least, to add any metadata at all. Hmmm. I did it through a Semantic Mediawiki Extension on my wiki prototype here, but that didn’t include faceted browsing or other dynamic tools. (I was planning to migrate from the wiki to a web platform.)
The initial goal ended not so much due to technology but due to processes in place the prohibited my hands-on customization of that technology. (No doubt these are the realities working in a large corporate environment where they have to safeguard production databases and publishing.)
We are now piloting Author-it as our enterprise solution, and we will see if we can implement metadata and other findability techniques. I’m not the tech implementing it, though. I’m just on the sidelines right waiting for our tools team to finish setting it up.
Informative post that provides me with a sense of relief that I’m not alone It’s a challenge I face on a day-to-day basis. Some times I feel lilke Lassie, woofing, woofing but Timmie isn’t listening.
Lassie and Timmiee — I vaguely recall a show about a loyal and helpful collie, but I fear this analogy stretches too far in the past for me.
I think you come closest to the answer when you talk about using a combination of many solutions (help, podcast, manual, video, chat, etc.). Having different ways to find the answer is necessary for the same reason that finding different ways to teach kids in a classroom is necessary – we don’t all learn the same way, think the same way, or look for information the same way. An answer, approach, or deliverable that works for one person may not be the best solution for another. This makes our job harder, but it also encourages us to keep learning. Remember, too, that the audience keeps changing over time, so what works this year may not be the best solution next year. I’ve been doing this for 21+ years and have yet to find one solution that truly works for everyone.
Thanks Tammy. I agree that the multiplicity of learning styles and preferences makes one solution impossible. I think a help strategy that tries to reach users by delivering content in different modes and formats is key. I wrote about a similar strategy once here, with the acronym VITA. Thanks for encouraging me toward this direction and for raising the awareness of different learning styles and preferences.
My colleagues and I were just talking about this topic this morning, actually. My findability series explores how to make content findable for users, but it doesn’t really consider that findability is dependent on the learning style that the user prefers. What one user may find in one system (such as an online help system with a search box) may not be findable to another user who prefers more visual styles of learning. To such a person, the answer may only become apparent with a visual, dynamic screencast.
Thanks again.
Tom,
How about treating this question — How do we create Help that satisfies all users? — as a Zen koan to which the answer is “mu.” In other words, what could we gain by examining the flaws that lurk in the question? What insights reveal themselves if we unask the question? What breakthroughs become possible if we deconstruct the tantalizing goal of satisfying all users?
What if we designed Help around the question, “Which users should this Help satisfy?” Just as a car designer wouldn’t set out to satisfy the soccer mom and the farmer and the need-for-speed driver with a single design, why shouldn’t Help designers also create their “product” for specific personas? The paradox, well documented in the persona literature, is that you often satisfy more users when you (thoughtfully) target fewer.
Hey, I like this. Thanks Marcia. I like the zen approach. I hadn’t heard of this before and will need to get more up to speed about it. But I do agree that targeting specific personas and trying to satisfy the learning needs of those personas is the only sane approach to the problem.
A wonderful, thought-provoking post; thanks, Tom. Where I work, we’re dealing with complex software products for a diverse audience in a specialized field — users with different levels of education, work experience, computer experience, etc. It would be nice if the GUIs were so intuitive that no explanations would be needed, but that’s not going to happen… (But that doesn’t mean the GUIs can’t be improved.
Melanie, I gave up on the intuitive GUI dream long ago. My favorite activity is to watch a user perform a simple task in an interface and become completely flabbergasted by something that is supposedly intuitive. It’s even better if the interaction designer is also watching.
Hi Tom,
Very interesting post – as usual. I think it’s impossible
People are all so different, not just their experience – what works for one person will not work for another. Some people like graphics, others like long wordy explanations. Some will be wanting a brief overview, others will want details and to understand every single tiny aspect.
As many of the other comments have stated, it would be scary to have found the PERFECT solution because that would make us a little bit redundant, and it keeps us extra busy to have to create different types of solutions for different users and also provides variety in our jobs.
I suppose it comes back to knowing our target audience which is usually one of the very first questions that comes up in starting a project. If the users are all very similar – they are all technical system administrators for example, we don’t need to define every single term. If the users have varying requirements, we might need to produce different outputs for each user type. But we always, I think, need to be aware that even with users of similar backgrounds, some will study a diagram while glossing over the text, others will do the reverse. Others just want a virtual person speaking to them from a video presentation.
I also think that this must be a question that comes up in every field – product managers must want to be able to define a product which achieves EVERYTHING for EVERY customer but later decide that they can only cater for a specific group of clients to avoid making a cluttered solution. Authors of fiction probably want to make a book that EVERYONE loves and cannot put down, but some best-sellers bore me senseless, while I’ve recommended books to friends that they have hated.
Sooooooo I’d be surprised if anyone can ever answer such a question – but good luck
Please share the answer if you do and we’ll all decide whether to tell out customers or not!
Helen, your comment makes a lot of sense. I hadn’t thought of the problem in terms of the analogies with applications and books. You’re absolutely right. No one book satisfies every user, but it seems that many demand that help satisfy every user. Perhaps one of the strategies would be to single source content to a variety of formats and modes to satisfy different learning styles. Trying to cover so much ground, however, without expending all your waking moments of time seems like a huge challenge. Thanks again for your insightful comment!
Great post, Tom!
Asking the question “Have you figured out a help solution that satisfies all users?” is like asking the question “Has Google figured out a search solution that satisfies all user?”
Google, with all its money and resources, still doesn’t have a sure-fire solution of how best to provide users with the answers to what they are looking for. So fret not that the tech writing community still hasn’t figured it out either.
This is a “million dollar question” that will probably never have one all-encompassing answer.
Sincerely,
Gil
Gil, good point. Google does an amazing job at finding some types of content but fails at others. It is interesting to compare our efforts to a brilliant company with mega-resources. Thanks for your insight.
I’m reminded of the Q&A in the direct marketing world:
Q: How do I get 200 new customers?
A: I don’t know one way to get 200 customers. I know 200 ways to get 1 customer, and I do them all. (The numbers vary–20 ways to get 10; the ratio isn’t what’s important.)
What matters is that you’ll get a useful answer faster (customers) by not spending too much time looking for the one right answer.
Thanks Karen. What an interesting angle. I guess this strategy aligns more with the multi-approach/solution rather than the single answer. Maybe the real question is to figure out ways to cover the 200 ways (rather than the 1 way) without expending tons of effort in doing so.
As you say, to track down all possible users and try to give each and every individual what they want is simply impossible. For sure we know that users are different. But what are we aiming for? The ultimate solution where a user only makes one “magic click” and the answer pops up? If this is our aim, it’ll be like looking for the fountain of youth.
Instead of figuring out what each and every individual user is curious about, we need to find another approach. The answer, I believe in, is to focus on the technical product (software, hardware etc). There are a number of “product characteristics” that can be written down regardless of users. For example: What problems, needs or requirements does the product solve? What are the required steps to get the product in solving the problems? We, as representatives for the company that develops a product, must provide information about these product characteristics, regardless of if a particular user is curious about how the product can be installed on mars.
Then, we need to tell the user what type of information our deliverable contains. Being explicit. “This manual contains information X, Y and Z. If you follow path ABC you will find X.” But writing “a manual for the manual” is not the approach. Instead, this meta information must be integrated into the search interface to “learn” the user about what type of information is available. This is where metadata and faceted search environments can play a big role.
Lets imagine that there where a “grand content scheme” that all manuals would follow. Meaning that each and every manual was built up from the same content types (the DITA task, concept and reference is not what I’m talking about – something more elaborated) and a user had learnt this scheme. Maybe it would be more like “I know that the manual contains this type of information, I only need to find it”.
Today a user doesn’t know what type of information to expect nor where it is located. What type of information are you expecting a manual to contain? The user has to adapt to the content scheme instead of adapting the content scheme to each and every user.
We are reading a daily news paper, the phone book etc since we know what type of information to expect. Many genres are “standardized” in a sense since any information artifact within the genre contains, almost, the same type of information regardless of who is producing it. Many product UI are also standardized, like the airplane cock pit or car interior. Once the user has learnt the standard, any artifact built on the standard becomes easy (easier) to use. Lets standardize!
SeSAM is my attempt to build an information model that is universal and can serve as a foundation for standardization. Watch my SeSAM presentations on YouTube: http://www.youtube.com/user/jonatanlundin
Jonatan, thanks for explaining your approach. I’m curious about your claim, “Today a user doesn’t know what type of information to expect nor where it is located.” If you have an iPhone, for example, wouldn’t you expect to have all your questions about iPhone functionality addressed in the manual? What if there are 300 different topics. Then how do you find the one you want? I’m just not seeing how SeSAM solves the problem in a way that manuals don’t already do. Most help topics are either conceptual or task-based. Do you have an example of a SeSAM manual that I can browse?
>If you have an iPhone, for example, wouldn’t you expect to have all your questions about iPhone functionality addressed in the manual.
Is this answer a case of “showing our age?”
In other words, another old saw: Q: Where do you hide any information? A: In the manual… It’ll be the last place they look.
Fact is, I DO expect to find stuff in the manual, but most of the time, I am disappointed. Either not enough information, or too much of the wrong kind. Look at your car’s owner’s manual for stupid safety warnings, for example.
>If you have an iPhone, for example, wouldn’t you expect to have all your questions about iPhone functionality addressed in the manual?
Yes, my expectation is that a manual should answer all my questions, but how can I make sure that this is the case?
What I meant is that users do not know what type of information to expect in a manual. They need to explore it (searching). Take the manual for IPhone and a competitor phone; the two manuals are probably very different in regard to what type questions are answered and how the answers are organized. This is due many reasons (the phones are different etc). So it is not the case that all manuals always contains answers to all user questions, and the issue is only to find the answer.
The idea with SeSAM is to make documentation goal oriented, instead of role, life cycle, product feature or task etc oriented. When users are searching they have an idea of what they are looking for. So they match what they see in documentation with what they are looking for. The hypothesis is that it is easier to find if user assistance is organized around what users are looking for to achieve, then making it easy to recognize relevant information.
I’m working on a SeSAM example manual, but in part 3 (b) on YouTube (http://www.youtube.com/user/jonatanlundin) I’ve made a SeSAM faceted search browser kind of mock-up.
Jonatan, thanks for pointing me to the youtube video you made. I’ll check it out.
You’ve described the conundrum very well, Tom. On the one hand, yes, the right mix of tools and media is important, while the importance of good taxonomy and metadata management can’t be over-emphasized. However, no matter how well we achieve those, we can still find ourselves putting out a sucky Help product. I think what’s needed here is good requirements management. Just as a software development project manager has to remain on guard for feature-creep and over-specifying the end-product, i.e., the problems that kill quality software, I believe it goes the same for documentation management. That is, let’s regard the rules applying to managing the feature set and quality of the Help product as similar to — and inseparable from — that of the overall software product.
Dave, thanks for the interesting comment. I wonder if help files can become susceptible to scope creep. Isn’t more information better? I know this is a controversial topic — exactly how much should you document? The more you document, the harder it is to find content. But if it isn’t documented, there’s nothing to find. Do you draw the line at 80%? I was hoping that the right findability techniques would allow me to document ad inifinitum without making content impossible to find.
Tim Green’s comment regarding training the end-users for mastership–as opposed to apprenticeship–is very much on-target. I really enjoyed reading his take on the perspective we ought to have when envisioning–and eventually scoping–our documentation projects. Perhaps a tutorial is the appropriate place for the kind of hand-holding information that newbies need in order to get started. Yet beyond that, can we assume that the main driver toward finding applicable knowledge will be the user’s desire to learn, more than the simple availability of spoon-fed information?
Bill Albing brings up a very valuable point regarding the social component of documentation. One of the things I’ve been stressing lately among my colleagues has been the emerging trend of community-provided documentation, made possible by the advent and propagation of Web 2.0 technologies. Today’s user is equally likely to find solutions to problems through Internet-based resources (e.g. Wikis, blogs, PHP bulletin boards, Google / Yahoo groups, social / business networks, talk-backs, etc) than from vendor-provided documentation. The challenge facing today’s technical writer is to shepherd and guide those conversations in directions that lead to the harvesting of knowledge addressing the needs of the user community. Beyond that, we can serve as curators, managing the taxonomy and applying metadata schemes that make the knowledge findable.
While the nature of the relationship is still being defined, I believe we’re heading toward a partnership with our user communities that’s much less top-down. Rather, we’re becoming part of a knowledge-sharing matrix where multiple conversations are occurring, many of these leading ultimately to documentation. Our role will be to apply our skills in identifying, organizing, refining, and tagging in ways that turn those conversations into usable content.
You’ve hit the nail on the head, Tom. Complexity keeps us employed. Like politicians, we’re trying to meet the needs of many people, and those needs often conflict. We can try to simplify, but doing so reduces the number of users we can help.
The only answer to a complex problem is a complex and detailed solution that addresses users as individuals. It’s great to generalize and answer frequently-asked questions, but you can’t neglect the long tail. Those long tail questions may be unique, but as a whole they are likely more numerous than the frequently-asked questions. For a technical writer to ignore such questions would be similar to a teacher ignoring the individual needs of a student. From a business standpoint it seems cost-effective, but if you’re the parent of that student it seems unforgivable.
Unanswered questions lead to lost customers. Big documentation is here to stay, and the need for complex help solutions keeps us tech writers in demand.
Great post!
Craig, I like your reference to the long tail. I think you may be on to something here. Have you developed this point in a post? I’d love to see more detail. More importantly, I’d love to see an actual proof of the idea (that answers to the non-mainstream questions end up with more collective hits than answers to the mainstream questions).
You also wrote, “The only answer to a complex problem is a complex and detailed solution that addresses users as individuals.” I thought science favored the simple solution to a complex world, like e=mc^2 or something.
First a disclaimer: In addition to being a help author myself, I also work for a help authoring tool company (Help & Manual), writing their documentation, handling support and the user forum and developing interactive templates.
This is an intractable problem and like all of us in the help industry I’ve thought about and agonized over it for years. All the “normal” answers have been covered above and elsewhere, so I don’t want to waste everyone’s time chewing through all that again. I want to try looking at it differently.
A logical corollary of Occam’s Razor is that if a problem seems intractable it’s possible that you’re thinking about it incorrectly. If you’re trying to eat clear broth with a fork you don’t need a sharper fork, you need a spoon. Assuming that we may be doing this here, the question is: What are the equivalents of the fork and the spoon in help accessibility? I think that part of it may be that we are making some incorrect assumptions about our relationship with the user and the user’s responsibility to take initiative. In addition to this, we are also avoiding some uncomfortable facts about the products we are documenting.
In a TV film I saw recently about the production of the bows used in Japanese Zen archery, the master bow maker said something that made me sit up and take notice. The interviewer had noticed that the master didn’t seem to be giving the apprentice any instruction at all, and he asked the master why that was. The master replied that that would be counterproductive and also insulting to the apprentice. He explained that he was not training an apprentice, he was training a future master bow maker. The master was simply making himself available as a resource. It was up to the apprentice to take the initiative necessary to learn from the master’s example and become a master himself. Training an apprentice does not produce a master, it produces an apprentice. A master is someone who can take the initiative. That is the only way to become a master at anything.
I don’t know about you, but grasping that was a “Wow!” moment for me. I suddenly realized that we are treating the users we are writing for like passive apprentices who need to be spoon-fed with everything, instead of finding ways to trick them into taking the initiative and becoming masters in their own right. If they fail to find something or don’t get something at the first try, we feel guilty and think we’ve done something wrong and think we need to do it better, explain it better, add yet another video and another chapter in the help. In our interaction with the users in support we often make this problem worse by supporting this assumption, instead of encouraging users to think for themselves and take more initiative.
This all applies mainly to complex software tools like a help authoring tool or a powerful image editing program like PhotoShop. The simple fact is that you cannot “document” these tools in the way that we believe we should be able to, so that everyone can use them easily. They cannot be used easily, so you cannot document them to be used easily. You can’t pour two litres of water into a litre jug.
The simple fact is that users who are not willing to take initiative, experiment, find resources and learn for themselves are never going to learn how to use these tools. It is not going to happen, ever, and it is waste of time to try to come up with ways of achieving it. The best we can do is make the resources for learning available and encourage users to take the initiative to find and use them. There are no accomplished PhotoShop, RoboHelp or Help & Manual users anywhere in the world who have not invested a lot of personal initiative, time and effort in teaching themselves. They just don’t exist. The user who has learned how to use these tools in the way we unconsciously think we should be teaching them is as mythical as the unicorn.
Of course, there is an economic dilemma behind this: The vendors don’t want to admit that their products can only be used by users who are willing to take initiative because there aren’t so many of them. The problem is, tools that have all the features professionals need are not easy to use. You can make them easier to use, but not easy, because professionals want so many things that easy is out of the question.
And the professional market is small — vendors much prefer to sell to the mass market, but for that you need simple, intuitive products that require little or no explanation.
This is a great probing question, but it assumes that the help is a closed system that we construct instead of an open and social system that can be added to by other users. When it is narrowly defined and constructed, help will not satisfy all users. But when it has a social component, allowing other users to add their questions and answers, we can come a lot closer to covering all the bases, and usually covering bases we didn’t know existed. As long as we are involved in a human endeavor, our help systems will need to be open-ended if we want to reach the largest audience.
Bill, I like the way you contextualize this problem — with help as an open or closed solution. I can’t imagine anyone voting for the closed solution. But with the open solution, it seems that wikis are pretty much the only technology that allows help to be open, right? Do you do a lot of wiki-based documentation?
Thanks! nice post here,hope to see more post,Great information on your site here. I love this post because we can get some useful information from your blog. I expect more post from you guys. Thanks for sharing it.
When you’re in the corner and have no cash to move out from that, you would have to take the home loans. Because it would help you definitely. I take short term loan every year and feel myself great just because of this.