e-Learning

Creating successful e-Learning takes a whole lot more than putting content on-screen. Here are some things to consider:

• What do your end-users really need?
• Where does the balance lie between features and functionality, technical complexity, and budget and schedule?
• How can your eLearning application be defined and developed so that it can grow and change with your business needs?
• Which combination of technologies is appropriate?

 The e-Learning Development Process

 Analysis

The first step is a Needs Analysis. You use a Need Analysis to aggregate the information telling you how to serve your business' goals and objectives for the e-Learning. The Needs Analysis also determines who is the Target Audience for this learning. The kind of e-Learning is influenced by the characteristics of the learner, for example, is the learning directed those unfamiliar with the topic, a refresher for an infrequent task, or add  identifies the knowledge and skills that need to be developed or reinforced. Finally a Task & Topic Analysis defines the content that will be required. 

Design

The next stage is the design of the e-Learning project and generally includes:

1. Defining the learning objectives to achieve the course objective,
2. Determining the order of the objectives (sequencing), and
3. Choosing instructional, media, evaluation and delivery strategies.

The Design outcome is the game plan used to develop the course. The game plan illustrates:

• The instructional design (e.g. its configuration in courses, units, lessons, activities),
• The learning objectives coupled with each unit; and
• The delivery methods and formats (e.g. interactive self‑paced materials, synchronous and/or asynchronous activities) to deliver each unit.
• The evaluations to determine if the learning objectives have been met.

Development

In the Development Stage, the e-Learning content is created. The content can vary depending on the available resources. For example, content may consist of simple materials (e.g. those with little or no interactivity or multimedia, such as structured PDF documents) which can be combined with other materials (e.g. audio or video files), assignments and tests.  For the more simple materials, storyboard development and the development of media and electronic interactions would not need to be be initiated.
Multimedia interactive e-Learning content development is comprised of three stages:

1. Content development - The writing and collecting the required knowledge and information;
2. Storyboard development - The storyboard isa document that describes the components of the final interactive products, including images, text, interactions, assessment tests in the order for the e-Learning product. They make up the instructional methods (pedagogical elements needed to support the learning process) and media elements.
3. Courseware development - By developing the media and interactive components, you can the course in different formats for web (and CD) delivery, Courseware also integrates the content elements into a learning platform that learners can access.

Implementation

Implementation is when the course is delivered to the learners. The courseware may be installed on a server or is made accessible for learners, or can be instructor or a facilitated course. This stage also includes managing and facilitating learners’ activities.

Evaluation

The evaluation stage is necessary to understand what worked and what didn’t This helps you to improve the attainment of your learning objectives. The e-Learning project can be evaluated for specific evaluation results including:

• Accomplishment of the learning objectives,
• Assessment of  learners’ behaviour,
• Transfer of leaning to job‑related knowledge and skills, and
• Impact of the project on your organization.

Maintenance

Change is inevitable. To keep e-Learning viable to your organization, it needs to be maintained and updated. This can start the whole process over again, or you may only need to update specific portions. But part of good e-Leaning is regular maintenance.

Steps to Creating Help

 Here is a quick 10 step overview to how I like to create End User documentation.

1. Analyze the needs of the users. It all starts here. Begin by asking what users want to do, their core tasks and responsibilities, and how the application assists them with these goals.
2. Make a list of the articles your users will need. This list of articles will include the instruction that you write. It does not need to be exhaustive as it is to get you started down the right path. As you begin creating the content, you have more ideas for more information that’s needed.
3. Get access to the product and explore it. Access to the development environments, test logins, bug tracking tools, and other related sites and assets to explore the product (usually a web application in IT) are invaluable to writing. You can then explore the application in terms of the list of articles you want to write. You may need to set up demos with developers
4. Start developing your help material. I like to write content in Google Docs because it’s so easy for my developer colleagues to review. The commenting features for Google Docs are unparalleled and allow lots of back and forth exchanges. But you could start writing anywhere. The key is not to get mired into structure and format at this stage. Just focus on the content
5. Review your content with subject matter experts. Ask the product manager which person will be the designated reviewer, and make sure to follow up with the person about his or her preferred method for review. If the person doesn’t get around to reviewing anything, consider setting up a meeting to review the content during the meeting
6. Figure out the formats you need to publish the content in. for example, If no one asks for a lengthy PDF document, don’t assume you need to provide one, particularly if your product is web-based and you’re in an agile environment. With agile, things change quickly so any PDF you create will be out of date. Eliminating the print deliverable can simplify publishing considerably. If people really need something printed, consider creating a printable quick reference sheet (1-3 pages on a specific task).
7. Select a publishing destination. There are many different destinations. What’s right for one situation may not be right for another. Different organizations use different methods. I keep my focus on the content.
8. Convert your help material from your scratch pad area (e.g., Google Docs) to your tools and publish the material. The conversion from the scratch pad writing tools to the formally published output will invariably introduce errors and other formatting issues that you’ll need to fix and address.
9. Create quick reference guides that pull out significant, overview-like material into a highly compressed guide. You could create a quick reference guide using something like Microsoft Word, or single-sourced perhaps from your help authoring tool. The main point with a quick reference guide is to be brief, basic, and visual.
10. If you need video tutorials, pull from your help material to create several 300-word scripts. You don’t need a ton of videos. They’re mostly introductory for new users, so cover the basics. I prefer Camtasia Studio as my video tool and publishing on Youtube or Vimeo. However it is also easy to attach them to the help site.

Why hire a Technical Writer

Many people in the software industry have great skills, and believe that they can write, however, a technical writer must possess superior grammar skills, advanced level word processing skills, and a keen awareness of the target audience. Technical writers produce documents the reader can understand and find the desired content in the document or online help. They also must have subject matter expertise and the ability to communicate effectively with the subject matter expert (SME).

Almost everyone owns a computer that contains some sort of word processing software. So why hire the services of a technical writer? Word processing software is only a tool. It's the person behind the tool that makes the difference. Here are some benefits of hiring a technical writer:

•  Technical writers bridge the gap between product designers and those who must use the product. We transform industry jargon into a language that all audiences (from novice through expert) can understand.
•  Well written documents reduce calls to your technical support department. Customers who learn how to complete their tasks by reading the documentation won't have to call your support staff.
•  Hiring a technical writer significantly reduces your documentation costs. Technical writers can write more concisely without sacrificing quality, resulting in shorter manuals and production costs.

In my career, I have seen thousands of dollars wasted by companies that use precious engineering time for writing manuals.
If your engineers give me the facts, I can sort out the data at a fraction of the cost!