Building Successful Hand-on Labs

Building Successful Hands-on Labs

The development of a hands-on lab, involves many different roles and proven practices for the process. In this document, we’ll identify the roles and responsibilities and then focus on the lab development process with callouts to the roles that combine to create a solid team for creating hands-on learning experiences.

Roles and Responsibilities

Proven practice #1: Identify who will take each role and its responsibilities to ensure everyone knows what they will be doing. This is the first step in the development of labs and allows the rest of the process to flow smoothly. All of the following roles are recommended. Each team member may take on more than one role depending on the size of an organization.

• Stakeholder: Has a vested interest in the decision-making process and owns the “reason” for having a hands-on lab. May identify the subject matter experts (SMEs). Has final approval of the finished lab.
• Subject Matter Expert (SME): Provides technical knowledge and background for the content of the lab. Works closely with instructional designers (IDs) and lab developers to ensure the lab performs as intended, covers the objectives, and provides the learner with best experience.
• Project Manager (PjM): Organizes, plans, and executes projects while working within restraints like budgets and schedules.
• Instructional Designer (ID): Helps lab developers and SMEs to develop the functional specification for the lab. This functional specification is the basis to build the lab and to ensure it helps the learner achieve the stated objectives of the lab.
• Lab Developer: Works with the IDs and SMEs and is responsible for building the environment and instructions that support the learning objectives. Additionally, coordinates with the SMEs to find creative solutions using the platform capabilities to deliver at scale and provide the best experience for the learner.
• QA tester and editor: Tests lab to ensure it can be finished as intended without issues. Reviews lab to ensure writing style guidelines are followed and content is understandable, as well as identifies where additional context may be needed.
• Skillable: Your partner on this journey. If you wish to undertake the lab development yourself, then any platform questions or "how can I do X?" type of questions, you can speak to Customer support or message your Customer Success Manager (CSM). Alternatively Skillable's Professional Services can supplement you and help create the hands on lab for you. If you're interested in Professional Services, please contact your Account Executive or Account Manager.

The Process

The Project Manager (PjM) will be in all of the meetings to keep track of progress.

Proven practice #2: Although this process may seem lengthy, each step helps ensure the lab is a success.

The Functional Specification

The most critical step of the hands-on lab build is the creation of the functional specification. It identifies the details that guide development. It should be updated as lab development happens to capture changes to the original plan. These changes may be due to the live environment, unexpected complexity when scale is considered, or other blockers. These changes should be identified and agreed to by the Stakeholder with an explanation, so the Stakeholder is fully aware of the situation. A roadblock may make the lab unattainable or cause time constraints that don’t allow for the desired experience. Most blockers are successfully overcome with creative instructional design and a relook at the reason for the lab.

The functional specification identifies the following:

• Learning objectives
• Exercises
• Outcomes
• Technologies used.
• Storyline
• Prospective environment
• Assessments

The environment, learning objectives, exercises, and outcomes guide the lab developers. They provide the purpose for the lab and a path to follow. The storyline is ultimately for the learner and provides the reason for the hands-on experience. Without this, a lab becomes an exercise in “clicking things” without a reason, and the learner ultimately walks away without having enhanced their skills. Assessments add to the learner engagement and should, whenever possible, be included in the experience. This gives the learner immediate feedback and helps to enhance learning. Missing any of these elements will deeply impact the development and/or the learner’s experience of the lab. The type of assessment should be detailed out with the SMEs, lab developers, and IDs and signed off on by the stakeholders.

Proven practice #3: Ensure the learning objectives and the storyline support each other to make the lab the best learning experience possible for the student.

Proven practice #4: Include assessment whenever possible to help make the learning experience possible more “sticky” for the learner.

Proven practice #5: The functional spec is the roadmap. Major changes and additional content identified after this document is agreed upon should probably be considered for future updates unless they block development. This will minimize the amount of churn and helps ensure the best version of the lab is created within the timeline while future improvements are identified.

Lab development

Development can now begin. The first step is to develop the lab profile, aka environment, which is used to support the instructional content and is the way the learner will interact with the subject of the learning experience.
A lab developer should create the initial environment based on the lab developer’s experience, subject matter expert guidance, and topic. It doesn’t need to be perfect and will have several iterations and updates along the way before the lab is done. The developer can create the lab profile and environment using:

• Skillable template gallery
  • Either public or organization gallery
• Custom new lab profile build or copy from another custom lab profile that generally fits the need.

With a lab profile and an environment to work against, the lab developer should complete the following:

• Create a rough draft of the instructions based on the outline in the functional spec to identify existing gaps in supporting content and knowledge.
• Identify risks and blockers that will need to be mitigated or may cause the lab objectives to be revisited.
  -Build the lab’s instructional content to meet the expected audience level like step-by-step or scenario based. Content should be tested multiple times before the lab is complete. This is necessary to ensure the lab works as expected and each portion of a lab is independent, or, if exercises in a lab depend on each other, combine to work as expected. The cycle becomes write, test, update, write, test, update until an end-to-end test is completed by the lab developer to finalize and make it ready for the next milestone.
• Identify potential items that can be assessed using automation. Unlike a scored lab that is used for testing or validating skills, an assessment-focused experience is intended to reinforce the skills being learned through validation and feedback. After identifying those points where automation can check a learner’s work and provide feedback or even multiple-choice questions, the Lab Developer can rough in those activities where they will be built later.
  • Note: Assessment activities support the learner’s journey by giving immediate feedback for success or additional help to be successful. When creating activities the developer should ensure they contain clear feedback and, for the scripts, contain error checking. IDs should be used to help with feedback.
• Create deployment scripts for resources that may be needed and would otherwise distract from the learning objectives if the learner were required to perform the tasks themselves.
• Create policies to control access when cloud resources are used.

Proven practice #6: The lab developer should always keep the learner and their experience in mind during development. End-to-end testing by the lab developer will identify anything that may have been missed during development and can be fixed before moving on.

Review and QA

QA Testing

Following development, Internal testing by editors and with a person or group who is not part of the lab development will give the lab developer an outside perspective to see if the lab can be done as written. Internal testing is not the same as the learner’s experience and requires attention to the details and time.

Internal testing looks at:

• Lab step functionality - “does the lab work”.
• Lab step accuracy - “are the lab steps clear and reflect what is seen in the user interface”.
  • Titles, names, and UI elements for example are correct.
• Lab images reflect the current UI.
• Experience notes are included for long running processes, page refresh requirements, etc.
• General flow of the lab.

When the QA tester encounters a blocker that stops progress on the lab, the Lab Developer should be brought in to address the fix on the fly, if possible. Continue with the test, if possible when a blocker does not affect later exercises or tasks.

Proven practice #7: It is a good idea to retest from the beginning after blockers have been fixed to best reflect a learner’s expected experience.

Editorial review:

The Editorial review is responsible for making sure the lab aligns with the expected style guidelines, language is appropriate and reads well, and generally, the lab flows from topic to topic creating a story for the learner. This isn’t a technical review. The Editor should look to see if a consistent “voice” is present in the lab since more than one lab developer may have been involved in writing the lab instructions. This helps with readability. The Editor ensures the lab’s instructions are clear and written to the expectations of a high-quality lab.
Lab developers should review the feedback from the QA tester and the Editor and implement changes as needed.

Stakeholders take their turn

Proven practice #8: Stakeholder and their subject matter experts, product owners, and/or others should test the lab after the lab developer has implemented the QA/Editorial feedback. They should test the same way a learner is going to use the lab and note any changes needed, language to add, and any other suggestions they may see add value.

These changes should be discussed with the lab developers and agreement on what to implement should be attained. Testing feedback that includes adding new content or expanding subjects will change delivery timelines. Therefore those should be discussed and possibly pushed to the next version of the lab.
Finalize

After all development, testing, and acceptance complete, the lab is ready to be put into production.

Consuming the lab can happen using several methods:

• Skillable TMS
• Customer LMS
• Directly launching via API
  Integration scenarios are not covered in this document, however, learners consuming hands-on labs will do so using some API consumer to launch the lab.