–Engage

“Innovation has nothing to do with how many R&D dollars you have. When Apple came up with the Mac, IBM was spending at least 100 times more on R&D. It's not about money. It's about the people you have, how you're led, and how much you get it.” - Steve Jobs

To train or not to train …

Lately, I’ve been thinking a lot about help, documentation and training. My current employment does a lot of what I would call unnecessary training. I have heard the word “training” too often used as a way out of doing a real investment to determine the right solution for the context of our users.

My initial reaction this past year has been to respond as being “anti-training”. In my situation though, I think it is still important to look more towards designing a proper digital solution than it is to look to training for an answer. However, I’d like to breakdown what I feel are necessary times to train and times when it shouldn’t happen. I’d also like to break down different levels of training or help and when they are or are not appropriate.


First, what is “training”?
For the purposes of this article, I’d like to suggest that “training” is any form of assistance within an digital solution that takes the user outside the flow of completing the purpose the design is meant to directly solve. This can include:

  • in-line text — explanatory text such as when you are filling out a phone number that says “format: ###-###-####”
  • tool tip or bubble — when rolling the mouse curor over a widget, or declaring the focus on a widget in another way, text will appear in obvious context to that same widget.
  • contextual help — a link next to an item on a page that when clicked displays text directly relevant to the object that the link is visually associated with. This is often a popup of somekind.
  • FAQ (Frequently Asked Questions) — a universal link/action item that when triggered displays a list of questions and their answers under the pretense that many other users have asked a siimilar set of questions.
  • help/support area — a universal link/action item that when triggered displays an indexed and tabled set of help documents that may or maynot be searchable. An add-on to this would be the use of comments from other users that expand on, improve, or clarify the existing documentation.
  • online and offline manuals — outside the direct context of the solution are manuals which are made available. Whether these are in print or not does not matter except online versions of these manuals may or may not be searchable and some even have user values attached to them such as “this was useful to 70% of the users who read it”.
  • online demos — a sequence of some kind that takes the user through an explanation of the solution. For product design (non-PC contextual solutions) these are often done as supplementary videos. While the pace can be controlled by the user, the overall experience is quite passive.
  • tutorials — unlike demos, tuturials require interaction from the end-user beyond pacing. Sometimes a combination of of tutorials become an accrediation process and an e-learning function is achieved. (some might call e-learning something else, but to me it fits nicely here.
  • in person (1) trainging — classes, seminars, workshops, etc. are all this variety and can be from 5 min. to several weeks. Think about how many graphic programs require multiple courses to learn how to use well.
  • in person (2) mentoring — This usually is done after “in person (1)” but happens two ways that I’ve seen: 1) A single person is tasked to go to an “in person (1)” type training and then comes back and assumes a special role for peers as a new internal “help” resource; 2) everyone goes to a short “in person (1)” training and one person goes to a longer one and then #1 starts again.

So the question is when to use what? How and when?

Adding to the interface directly
Many more classically trained designers might suggest that a well designed product doesn’t require this type of assistance at all. Yes, we need icons and basic labels, but in-line explanatory text and tool-tips distract users more than they help and if we just used (I’m playing a little) the right amount of negative space, color, and the perfect use of semiotics and language in the primary parts of the interface, we won’t need such crude devices. There was even an article resently that I commented on and a colleague of mine did as well. In it it discusses how safer roadways might be made by using less signs and more contextual (and I would add) and metaphorical clues. In my reply I disagree. And still do. I do believe that because there are little to no affordances in the digital 2-D interface world that users can gain a lot through further elaboration. In reading some works by Jared Spool and his gang at UIE I feel like this is supported in the research. Mainly Jared speaks about “sniffing”. That we tend to hunt for the next thing we want to do and the more clues we get in the interface the better.

The one no brainer is the use of tool-tips, especially when they are used for icons. Icons have so much baggage to them that they need all the help they can get. All the other possible in-line solutions require a designer to judge where the balance line is for their particular subject. This needs to be done through examining the audience the business model and the user personas. Can the “hit” to the presentation be “temporary”? Can the user turn it off if they don’t need it anymore? Can the system turn it off automatically after a certain number of clear successes with the relevant widget(s)?

contextual help
I love contextual help. It’s biggest problem is how long it takes to build correctly, but the gain is just so big. A smaller negative is that you need to make sure you limit its use to “problem areas” as you don’t want to have a link associated with every widget or set of widgets; however the blog I’m using now does do this in their admin screens (but alas not in this screen where I could really use it right now). So again there is a balance because you are placing further eyeball drain directly in the line of activity. So whatever you use to “alert” the user that this help is available, you need to do it in such a was as to be inconspicuous.

Good contextual help though cannot use the same format and layout as full “help” documentation. It overburdens the process creating confusion, when what you are looking for is absolute clarity.

manuals, help systems, FAQs
Ok, these are all my pet peeves. They are a necessary last resort and otherwise evil. Yes, you heard me. I love my tech writers who put so much good energy into making this important documents, but to me, everytime I open one of these things I am thinking bad thoughts about the company who’s product or service I’m trying to use.

The main reason for this is that you’ve taken me directly out of the context of the work I’m doing and every minute I’m there looking at this documentation I’m thinking to myself, “I really want to be doing something else and YOUR solution is wasting my time.”

But like I said, you have to have it. Why? Because designers are very fallible and well, we need this stuff. The least we can do though is put the same amount of energy into their design as we did into the solution that you couldn’t figure out using with this added documentation in the first place.

Online e-learning
Demos and tutorials and even online training have their place as discount methods of quick “in person” solutions. Like a 2-hr. or less class.

Demos in particular are good if to get a user “in the mood” so to speak, you start a subtle language training in the context of the application. Like all e-learning and in-person solutions, the goal here is to help the user make their way towards some new cultural paradigm. These can really only help with general concepts.

To kick it up a notch more interactive e-learning can be quite helpful, especially when first replacing existing modes of work with new ideas.

in-person
Well, this should really only be used in the cases of either high complexity (I’m really upset that this seems to be reality) or a major change in culture. Unlike the previous example of taking the same process but adding a new solution to it, this should be used for the introduction of new processes and new solutions all at the same time.

I would caution that there are very few examples of things that should require this level of intervention. You are really doing something that takes the user way out of context of the purpose of the solution. That said, cultural change is very difficult and hand-holding is almost always required to do it successfully.

Conclusion
So training is not evil as I thought so yesterday, but training needs to be designed within the context of the entire UX solution. In fact as an IxDer there are great opportunities to think about the behaviors and relationships within all the levels of training and help and they should be on our radar as much as whether or not to use a drop-down vs. a set of radio buttons.

Be Sociable, Share!

Search

The archives run deep. Feel free to search older content using topic keywords.