Sometimes I get ideas about a problem I’m trying to solve once I’ve stopped actively thinking about it and have let it drift into the back of my mind. With Project Pinnacle, something escaped my attention until a few weeks after my visit to the pilot site.

Well, it didn’t entirely escape my notice, but its implications for documentation and training didn’t hit me immediately.

The thing I noticed while watching users try out my quick reference guides was that they tended to follow only the first few steps of the procedure. They would look at it long enough to get to the screen where they performed the task, and then they would try to do the rest without the guides.

One of the reasons for this is that they had to keep glancing between the monitor and the paper, which made it easy to lose their place. Trying to use a finger didn’t help much either because at some point they had to start typing.

A few weeks after my visit, I got an idea of maybe a true quick reference guide that would fit what they needed. Since they relied on the printed procedures only for navigation, why not just provide the navigation steps?

I put together a version of each guide that listed the steps with double angle brackets between each step. This condensed the existing material from about four pages for each guide down to under one page. I haven’t tried these versions out yet. The project manager wasn’t in favor of the version of the guides that have the screenshots with callouts because of the cost of keeping the screenshots current for all languages.

When I first reported to the project leadership about my visit to the pilot site, I pointed out that a way to improve our training of our audience and at the same time reduce documentation costs would be to provide more prompts in the application. I’m not trying to reduce my workload, but I believe that the more help you provide in the interface, the less help you have to maintain elsewhere. I know, not real profound, but it’s not something very many product designers think about.

Since then, I’ve provided prompts and descriptions for a number of application screens and features. We’ve seen a direct impact of this as we’ve worked on the training video scripts. We want to keep the verbal explanations simple and let the features be demonstrated so that we don’t have to rerecord the audio if features change. The fact that we’re including help in the interface helps us do this because we can leave much of the explanation to the application itself.

Image credit: Salvatore Vuono, freedigitalphotos.net

Bookmark It

Hide Sites

I have a crackpot idea for presenting user assistance in software or on websites. Okay, maybe it’s not so far out there, but I haven’t seen this done anywhere that I can recall.

Like a lot of ideas, I was probably thinking about something else when this occurred to me. But I’ve got this picture of a div that slides or pops out in the interface when the user wants to see it to get more information. This pane could appear to one side or the bottom of the main section of the page.

Here are a couple of mockups. These are not to scale.

Help appearing to one side

Help appearing at the bottom

The advantages of this approach is that the user doesn’t have to see help unless he or she wants to, and it’s right there in the same window, not covering up anything, so you don’t have to switch back and forth between windows.

Disadvantages are the limited real estate for content and the amount that this may cut into the site or application’s usable space.

One of the main things I like about an approach like this is that I believe user assistance ought to be designed into the interface. It shouldn’t be something added at the last minute like you were deciding what hat to wear today before leaving the house. It’s part of the user experience, so it should be part of the user experience design—with input from the technical communicator, of course.

What do you think? Have you seen this kind of approach anywhere?

Bookmark It

Hide Sites

That word has reared its ugly head again.

A recent post by Ellis Pratt on the Cherryleaf blog discussed David Black’s claim at the TCUK 2010 conference that someday, end-user documentation won’t be needed. Ellis says:

Although he felt no-one but Technical Authors had the answers to how to understand complexity and failure, he believed that products would become so intuitive, and people would be so technically adept, that there would be no need in the future for end-user documentation.

Other than the fact that I think it’s a bit tacky to respond to an invitation to speak at a tech comm conference by telling all the attendees they’ll be obsolete in a few years, I have a problem with this fallacy that anything, especially technical in nature, is intuitive. I’ve heard the word intuitive in this context so often that I’ve come to almost despise it.

It’s something of a cliche to consult the dictionary when trying to prove a point, but in this case, it’s highly called for. Dictionary.com says, and I quote, intuitive is “perceiving by intuition, as a person or the mind.” Well, nothing like using the word to define the word, so here’s one of the definitions of intuition: “direct perception of truth, fact, etc., independent of any reasoning process; immediate apprehension.” The next few definitions are similar. Then we get the definitions according to the school of philosophy:

a. an immediate cognition of an object not inferred or determined by a previous cognition of the same object.
b. any object or truth so discerned.
c. pure, untaught, noninferential knowledge.

Note that part of this definition are the concepts of no previous knowledge and being untaught. The other definitions hint at these concepts, but the philosophy definition calls them out specifically.

I continue to argue that very little in life is truly intuitive. The idea that we can fabricate and invent things that are in some way intuitive is a myth. I’ve had this cemented in my mind even more through recent experience.

› Continue reading…

Bookmark It

Hide Sites

In our ongoing department reorganization, we technical writers are experiencing some angst as we carve out a desirable place for ourselves. However, as we’ve talked about it as a community of practice (no longer as an organized team with our own manager), I think we’re coming to an agreement that now is the time to make things happen—to strike, as Tom likes to say.

After the initial, high-level reorganization, Tom and I are in the same division, so we’ve discussed a plan for taking a more prominent place in project managers’ and interaction designers’ consciousness. This is the key for us because the PMs are the ones to include us in their project plans and budgets, and we would be working with designers to decide on user education approaches and contribute to the design itself.

Finding Tech Comm’s Place in the Family

After Tom’s blog post about our meeting with an interaction design manager, I asked him about his point of view and his readers’ reactions to the post. We discussed getting involved in projects early and contributing to user interface text. We talked more about this in our community meeting this week. Again, we’re looking to make sure that the people who make the decisions give us a rightful place at the table.

We also talked about many designers’ “holy grail” of creating products so intuitive that no documentation is needed. Tom reminded me and then the group of an important point I had forgotten. An interaction designer once said something like this to me, and I had passed it on to the team: “Saying that ‘if the interaction designer does his job right, the product doesn’t need help’ is like saying ‘if the developer does his job right, the product doesn’t need QA.’”

› Continue reading…

Bookmark It

Hide Sites

One day I spent much of my time with a person who was new to a desktop application I work on. I provided documentation for the application, but this particular person—I’ll call her Ann—tends to doubt her ability to learn. So I was happy to work with Ann one-on-one to help her learn the steps of a procedure she would use at least weekly (and that she knows well at this point, I’m happy to report).

As we talked, Ann decided to open a new Word document to work in. I watched as she went into her file system and located a document with the file name “blank page.docx.” She double-clicked it to begin a new document.

I was somewhat surprised and even a little amused.

› Continue reading…

Bookmark It

Hide Sites

I’m not a fan of documenting third-party software, but that software, as well as operating systems and settings, have a significant effect on user experience for your product. Especially if your product may be used by anyone using any operating system and any combination of settings, it may be impossible to document everything. If you’ve tried to document printer settings, you know what I’m talking about.

It’s nice when you have a user group working in a somewhat controlled environment, such as a corporate desktop configuration. You can count on a certain limit to the variation of user circumstances, and you don’t have to spend as much time chasing down the answers to a bunch of “ifs.”

› Continue reading…

Bookmark It

Hide Sites

We held our team offsite event today, and one of the items on our agenda was lessons learned from the STC conference in June. I talked about some of the sessions I attended, one of them being the “What Is Structured Authoring?” panel with Neil Perlin and Sarah O’Keefe. They spent the entire session talking about what their definitions of the term “structured authoring” and how it benefits the writer, and never was the word “user” uttered until I asked them whether structured authoring—whatever its definition—held any benefit for the user.

Neil replied that structured authoring lends itself to having consistent content organization, which is easier for the user to navigate. This was the answer that I pretty much expected, but I wanted someone in the panel to talk about users. User experience should be central to technical communicators’ thinking.

As we were discussing this in our team today, I thought up and drew a little diagram on the whiteboard that I call the Experience Spectrum:

Whatever definition of “structured authoring” we choose, we can go to one extreme and, while being consistent within a team or organization, create a totally new experience. Users could, over time, learn to expect the experience we created. Or we could go to the opposite extreme and choose a structure or scheme of presenting information that is based as much as possible on user research. We just find out what users want and give it to them.

With this being a spectrum, there are varying degrees and mixes of both approaches.

I rarely advocate the extreme of anything, so I think the best practice lies somewhere in the middle. We definitely need some user research so we know what they are accustomed to and like, and then we can create an experience that doesn’t frustrate users out of the gate. At the same time, as professionals, we know some tricks of the trade and some of our engineering of the experience should be based on our expertise. I’m simply asking here that we let the users have some input on the interaction they’re going to have with our content.

Bookmark It

Hide Sites

Early on in our marriage, my wife and I listened to a set of CDs (a wedding gift) from a series of seminars by John Lund, a marriage counselor. Based on years of experience, he had developed the axiom, “Frustration is caused by unmet expectation.”

Now, just think about that statement for a minute in any context you choose. I suddenly recalled this axiom recently when talking with a coworker about a help system I had built and written, and it hit me that in user experience and documentation design, they are words to live by.

› Continue reading…

Bookmark It

Hide Sites