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

A huge problem for projects is the lack of a common language between the developers and the users.

When my colleague and I were preparing a presentation for an internal conference on this subject, he said something that has stuck with me. He said, “The goal of the project is to make the user successful.” I added to that: It’s not to write code or validate code. It’s not even to ship a product or make money (of course, this last one is especially true in a non-profit organization). At least, it shouldn’t be these things.

The goal of a project is to make the user successful at what he wants to accomplish.

Go ahead, read that previous sentence a few times. It’s one that would do well to sink in.

› Continue reading…

Bookmark It

Hide Sites

Last week, IT groups in the organization held a conference so that we could share techniques and best practices while saving the money it would take to send hundreds of people to external conferences. Because of the different roles represented aside from developers and testers, I had enough topics other than things like Java and test automation to keep me busy throughout the two days.

One of the sessions I attended was the basics of usability presented by a usability specialist and an interaction designer. The session included an exercise that illustrated why usability testing is important and how it can be done early in the process with little expense. The presenters divided the attendees into several groups, and each person received a role as product manager (or customer), user, program manager, business analyst, or interaction designer. Each had certain goals to meet with the product, and then we had to create prototypes consisting of sheets of paper and sticky notes written on with markers. At the end of the designated time, the user had to come in and try to accomplish certain tasks using the prototypes and navigating them with his finger.

I was the product manager for the group I was in, and I had some knowledge of the subject matter that the application related to, but sometimes the business analyst, program manager, and designer would ask me questions I didn’t have the answer to. Still, it was a fun exercise. And one of the points was that usability should be owned and encouraged by everyone on the team. We also found that at times, we overlooked very obvious things that were necessary in the interface.

› Continue reading…

Bookmark It

Hide Sites

Yesterday I met with the interaction designer (I’ll call him Joe) on a certain project so that we could discuss text on a few screens he had designed. “I’m not a writer,” he said, “so I have a hard time getting things just right.” To help him phrase the text, I had to understand the screens, so he spent some time explaining the concepts. This was mutually beneficial, since I’ll soon be writing the documentation for those screens.

I mentioned to him that a designer had said that if an application is designed well, it doesn’t need help. Joe smiled and said that it’s what they (meaning the design team or designers in general, I think) refer to as a “sexy thought”—it sounds nice in theory but really isn’t true.

› Continue reading…

Bookmark It

Hide Sites

I remembered a recent experience during a conversation today, and it reminded me of how a technical communicator can contribute to projects at nearly all stages.

Some of the systems in the organization are incorporating new security, so this switch involves guiding users through the process of getting new user accounts. The interaction designer for one particular site asked me to help with the on-screen text that would be displayed during the transition period. We had several meetings with the program manager and lead developer as we went through their design of the process and talked wording.

For two main reasons, this is an area where I think it’s important for technical communicators to be involved, especially when user assistance is embedded in an application or site (as opposed to documentation that opens in separate windows or is provided in hard copy).

› Continue reading…

Bookmark It

Hide Sites

A little while back, Michael emailed me an invitation to look at some findings from a study about online experience. I haven’t had a chance to check out the full document yet, but the executive summary contains quite a bit of information. I’ll consider here how some of the findings affect technical documentation.

Easy Access to Complete Information

One point made in the findings is that users’ “enjoyment” of a site is tied closely to how easily they can find the information they want and stay oriented at the same time. I think this is a given for technical communicators; we know that users want to get answers as fast as possible, and documentation must be navigable. Those two factors are easier to pin down than a third: “complete information.”

› Continue reading…

Bookmark It

Hide Sites