If you are an instructional designer, then this question is relevant to you: “When was the last time you designed an e-Learning course for end-user application training?”
I am sure that many, if not most, readers of this article are either in the middle of such an e-Learning project or have just finished one. Also, many of you probably felt that you did not get enough support from the application development team. You are left wondering if the application team really appreciates your efforts, or how you could have done this better!
I personally believe lack of knowledge of the entire application documentation cycle is what puts the instructional designer in such a situation. Most of the e-Learning projects that set out to train end users run in parallel with the application development. The application development team (including the business analysis and the functional teams) is struggling with deadlines, and in most cases do not have time for the Instructional designer or the training team. Hence we instructional designers are left to fend for ourselves. So what is the way out? How does the instructional designer overcome this barricade and create an instructional design that meets the learning objectives of application training?
First, as observed in practice, there is usually enough documentation generated as part of the application development to support instructional design. If the instructional designer looks in the right places, then it is possible to come up with an excellent course that will meet its instructional objectives.
Second, it might be a challenge for an instructional designer to communicate with multiple stakeholders in the project team. I have had instances where the instructional designer had to shuttle between the functional or business analysis team and the technical development team. The inputs would not come on time, and the instructional designer would become frustrated waiting for inputs and sign off on reviews. This situation is avoidable if the instructional designer is aware of the roles that each member of the software development process plays.
The development team
Let us look at a team that develops software. The team normally consists of the Project Manager, Business Analyst, Technical Architect, Database Administrator, Technical Programmers, and Software Quality Assurance Team. I am not claiming this is a complete team; however, most teams will consist of individuals who fill these roles. Let us analyze each role and examine how it can help with the instructional design process.
Project Manager
The project manager is the most crucial member of the team. The project manager may not be in a position to help the instructional designer with the course content creation, but this person will be able to give you key inputs on the project schedule. The project manager can also direct you to key members of the project who could be valuable to your design efforts.
Business Analyst
The business analyst (BA) is a very important member from the instructional perspective. The BA will be in a position to explain to you the various business processes and the overall features and functions of the system under development.
The BA will also be able to help you in identifying the exact needs of a prospective learner. He or she can help you segregate the “need to know” from the “nice to have” information in the course. BA’s are crucial resources that play the role of subject matter expert in the e-Learning project. However, they are also involved in various other tasks, like modeling, coordinating with the customers in requirements gathering, training, and helping the customers in user acceptance test, and so on. As a result, it will be useful to plan their time for the e-Learning project in an optimal way. If you are well prepared and quite knowledgeable about the project, then you may have a willing SME who is ready to help you.
Technical Architect
The Technical Architect is a key resource on the application development team. Normally the architects work on multiple projects at the same time. Technical Architects, like building architects, have a good understanding of the application from the design perspective, and also of the technologies used. If it is important for the end users to know why they used a certain technology in developing the application, then technical architects are the best people in the project team to answer these questions. However, you must realize that technical architects are very much sought after resources, and are always busy with multiple projects. Use their services optimally.
Programmers
The programmers, or developers, as we sometimes call them, are very junior members of an application team. Normally they do not possess much functional knowledge of the application, although they may possess foundational knowledge that might be necessary for the learners. They have knowledge of computing logic, algorithms, and so on. This means that they can be a handy resource in helping you to capture screens needed for your course. They can also help you with understanding the application documentation.
Quality Management Team
The quality management (QM) team consists of the quality assurance (QA) and quality control (QC) teams. Collectively, the QM team includes quality analysts, process experts, testers, and auditors. This team can be an excellent resource for instructional designers. The testers will have the knowledge of all the test cases that were administered to validate the application. These test cases can be very useful for you when you have to create assessments, especially when you have to prepare scenarios and simulations.
When you are familiar with the project team, and how you can elicit required information from each team member, it’s time to negotiate the documentation maze.
The documentation maze
URS, SRS, FS, TP: do these abbreviations make your head spin? Yes, it can be really difficult to get around these. Fundamentally, these documents are generated as part of the application development project. The BIG question is where should one start?
Like the courseware development process, the application development process also has phases. The most popular approach is the waterfall model that consists of analysis, design, develop, testing and implementation phases. I will not go into the details of each phase, however it will be of interest to us to know the documents that each phase generates – these are the deliverables at the end of each phase. Table 1 describes these.
| Phase | Document |
| Analysis |
|
| Design |
|
| Testing |
|
| Implementation |
|
This is good a way to start. Follow the application development phases and go through the generated documentation. Let us do a deep dive and peek into these documents.
System Requirements Specifications (SRS)
The system requirement specifications is a document that captures the requirements as stated by the potential users and key stakeholders of the project. This document also contains the hardware, software requirements, and specific integration requirements. Some projects have a two-stage process of preparing these documents. They prepare a user requirements specifications document (URS), and derive a functional specification (FS) from it. Without going in too much detail, I would like to show you some key diagrams used in SRS / FS / URS that will come in handy for you to carry out your instructional analysis.
Use Case diagrams
Use case diagrams describe the functionality of a system and the users of the system. The use case diagrams consist of actors and use cases. Use cases are the services provided by the system to the actors (users). Figure 1 is an example of a use case diagram.
As is evident from Figure 1, it will be very easy for you to identify the learning objectives for each group of learners. You will be able to easily identify various groups of learners for your training. You will be able to clearly identify, from the expanded use case diagrams, the major tasks each group of the learners will have to perform on the system. Merely by going through the SRS, you can tell early in the project life cycle that one of the learning objectives for an associate is, “At the end of the course, you will be able to raise a request for approval.”
Once the learning objective is clear, you need to identify the content relevant to this. You will have to wait till the development phase of the project is over. The case presented here might be simplistic, since it is for illustration. However, each use case may have multiple levels of detailing. These detailed use cases are a treasure trove for an instructional designer. For example, let us consider the use case shown in Figure 2.
Figure 2 is the use case diagram for a resource manager using a resource management system. The resource manager has to maintain the skills database, and hence is expected to add, delete, and update skills. Similarly the resource manager also has to carry out maintenance activities of the resources, so he or she should be able to carry out the following tasks after undergoing the training program designed by the instructional designer:
- Add a skill
- Delete a skill
- Update a skill
- Modify a skill
- Add a resource
- Delete a resource
- Update a resource
- Assign a skill to a resource
- Un-assign a skill from a resource
This will not only help you identify the learning objectives, but will also help you design the entire course outline. It will help you in modularizing your course. You could also use this notation for carrying out instructional design as well. This is explained in Handbook of Visual Languages for Instructional Design by Lucca Botturi and S. Todd Stubbs (see References).
Design documents
The design documents may not contain information that is directly relevant for your instructional design. However reading the design documents will help you in understanding the application from a programmer’s perspective. It will help you understand why a certain feature behaves a certain way. As in the analysis phase, there are few diagramming tools that you should be aware of when reading design documents.
Class diagrams
Class diagrams describe how a system is structured. It does not depict the behavior of the system. The class diagram consists of classes and associations. Classes represent the entities within the system that contain common characteristics. Associations represent the relationships between the classes. Figure 3 shows an example of a class diagram.
Figure 3 Illustration of a Class Diagram
Figure 3 is a high-level diagram, and is illustrative in nature. The detailed diagrams can give more specific information about the classes, such as attributes and the kind of data and functions that operate on them. If you really want to drill down to every possible detail of the application, then these diagrams are for you. From the course perspective however, they do not have much significance.
Object diagrams
Objects are instances of classes. Hence the object diagram represents the objects and their relationships using links in an application. Like the class diagram, the object diagram represents the static state of the system. The only difference being that it is a snapshot of the system at a particular instance.
Sequence diagrams
Sequence diagrams illustrate the various interactions among classes in a project. The interaction modeling is as exchanges of messages, which are undertaken to accomplish a certain behavior. Sequence diagrams consist of class roles, lifelines, activations, and messages. Figure 4 illustrates the sequence diagram for an assessment engine that allows users to compile and run their program using a Web-based interface.
Figure 4 Sequence diagram for a Web-based assessment engine
The sequence diagram illustrated in Figure 4 is not complete, but it will give you an idea of how the diagram will look. This diagram will enable you to identify the sequence of tasks that each group of users of the application will perform.
Apart from these, there are various other diagrams that you will find in the design document. They are as follows:
- State-chart diagrams
- Activity diagrams
- Component diagrams
- Deployment diagrams
For more information about these diagrams, please refer to UML In A Nutshell (see References).
Unit Test Plan
This important document will give you a peek at how each use case has been tested. This document normally consists of the list of test cases for each use case, with expected results. Once the first round of testing is completed, you generate a Unit Test Results document. The development team will fix the reported issues, and then will issue the revised system for verification. After the final round of testing, you release the system to a select set of users who complete the testing and certify it for deployment. This is called the UAT (user acceptance test). Table 2 describes the UTP (unit test plan) for the assessment engine software.
| Step No. | Description | Expected Result |
| 1. |
USER LOGIN | |
| 1.1 | Validations are done with the data base for each employee ID and password | |
| |
i) empid=507083 password=sekar | Should move to instructions page |
| |
ii) empid=507083 password=ouertj | Should give error message |
| |
iii) empid=507086 password=naik | Should move to instructions page |
| |
iv) empid=administrator password=admins | Should move to admin activities page |
As is evident from Table 2, this is very important information for you. It comes in handy when you have recorded the application as a demonstration of the tasks to the learner. Having access to all possible scenarios of a use case will help you in designing the exact activities to achieve the learning objectives. Alternatively, these test cases will also help you in creating an evaluation instrument to validate the learning. For example, in this case you design an activity for the learner to enter the valid employee ID and log in to the system. Additionally, you could familiarize the learner with what will happen if the learner enters a wrong ID. These help the learner to be aware of potential pitfalls.
Let us consider the test cases in Table 3
|
Step No. |
Description |
Expected Result |
|
6 |
COMPILE PAGE |
If compiled successfully and there are no errors, the message will display along with the Back and Run buttons. If there are any errors in the code, the error message and the Back button will display |
|
6.1 |
If the user clicks the Back button |
The coding page will display |
|
6.2 |
When the user clicks the Run button |
If there are no runtime errors, submit the code link, and display the Back button. If there are any runtime errors, display an error message and the Back button. |
|
6.3 |
If the user clicks the Back button |
Display the coding page. |
|
6.4 |
When the user clicks the Submit the code link |
Efficiency page will display. |
In this scenario, the users have to submit their program to a Web-based assessment engine to compile and run their code. As an instructional designer it becomes easy for you to design the “show me” screens for your course. Your screens will consist of all possible paths a user of the system could potentially undertake. Hence, using the test cases ensures that you have explored and exhausted all possible routes your learners need to be aware of. As mentioned earlier, you could also design evaluation items by looking at the test cases.
Conclusion
If you, as an instructional designer, are aware of the application development process and are able to effectively understand the relevant documents that can be generated during the development, then you can be very effective in your job. Your dependence on the development team will be minimal, and you will have a holistic picture of the application. The course that you develop will address all the potential learning objectives, and the application development team and learners will immensely benefit from this.
References
Alhir, Sinan Si. (1998) UML in a Nutshell. Sebastopol, CA: O’Reilly Publications.
Botturi, Lucca & Stubs, S. Todd. (2007) Handbook of Visual Languages for Instructional Design: Theories & Practices . Hershey, Pennsylvania: Information Science Reference.