Making the Most of Custom Lab Builder: A Guide to Writing Inclusively for All
Language shapes how people perceive and engage with content, so it’s crucial to consider the kind of words you use. Using outdated terminology can offend and disengage learners, as well as hurt a company’s reputation. This blog is the second in a series on making the most of the Lab Builder, looking at what we call the Four Cs. Ensuring your writing is… Conscious Consistent Conversational Concise The previous post in this series looked at accessibility. In this post, we’ll explore what it means to write consciously and inclusively, share practical tips, and show how our platform supports this critical effort. Why is inclusive language important? Inclusive language avoids bias, respects diversity, and ensures accessibility for all. In cybersecurity, it means using terms that foster collaboration and trust, avoiding outdated or harmful phrases, and creating welcoming and empowering content The Quality Team at Immersive Labs is committed to staying up to date with how language changes in the cyber industry. We regularly undertake research and speak to other industry professionals to ensure that our language is appropriate. Words to avoid We recommend avoiding specific terms that some people may find offensive, and some socially charged language that may have negative connotations. Non-inclusive language to avoid Preferred inclusive versions Whitelist/Blacklist Allowlist/Denylist White hat/Black hat hackers Ethical/Unethical hackers Master/Slave Leader/Follower, Primary/Replica, Primary/Standby Grandfathered Legacy status Gendered pronouns (e.g. assuming “he/him/his”) They, them, their Gendered pronouns (e.g. “guys”) Folks, people, you all, y’all Man hours, man power Hours, engineer hours, workforce, staffing Man-in-the-middle attack Machine-in-the-middle attack Sanity check Quick check, confidence check, coherence check Dummy value Placeholder value, sample value Crazy, insane Amazing, incredible, or any other appropriate adjective Socially charged words Preferred inclusive versions Native Built-in, default, pre-installed, integrated, core Abort Stop, cancel, end, force quit Cripple Disable, impair, damage, destroy, ruin Kill Stop, force quit, close, shut down Trigger Activate, initiate, cause, launch Unsure if a phrase you’ve used could be seen as offensive? Ask yourself: is this the most accurate and appropriate choice? Often, you can find a more descriptive word and avoid using these examples. Top tips for inclusive language Use writing tools Tools like Grammarly can help identify problematic words or phrases. You can create customized lists in Grammarly, which will then flag when a word has been used in your writing. Additionally, there are many inclusive language guides available online. Keep it short and sweet Use short sentences and paragraphs. Shorter sentences are easier to read, scan, and understand – especially for those with cognitive disabilities. Aim for sentences around 10–15 words, with variation for a natural flow. Avoid sentences longer than 20 words, as they can be harder to follow. Read aloud Proofread your work aloud to catch awkward phrasing, overly complex sentences, or insensitive terms. Hearing the words can help identify spots where clarity or tone might need improvement. Get a second opinion Ask a colleague to review your final version. A fresh set of eyes can spot language that might be unclear, inappropriate, or overly complicated. Share your thoughts Now that Lab Builder is here and you’ve had a chance to create your own content, how have you made your content more inclusive? We’re always looking to stay up to date, so if you have any further suggestions to add to our list of words to avoid or any other tips, let us know! We’d love to learn from you and grow the collective community knowledge.Making the Most of the Custom Lab Builder: Writing With Accessibility in Mind
What if someone tried to access your content who was visually impaired? Or who had cognitive difficulties? Or who was hard of hearing? Would they be able to understand the information you’ve provided and improve their cyber resilience? Our in-house copyediting team has created a series of articles to help you craft high-quality labs, aligned to the rigorous processes we follow. We embrace what we call the Four Cs to ensure all labs are: Consistent Conscious Conversational Concise These articles delve into each of these principles, showing how to implement them in your labs to create content that resonates with readers, enhances learning, and boosts cyber resilience. This post highlights how being conscious of your formatting can enhance accessibility for assistive technology users and how consistent formatting improves navigation for everyone. Rich text formatting Rich text formatting tools like subheadings, bullet points, lists, and tables in the Custom Lab Builder help organise information for easier scanning, better retention, and improved comprehension. Using these will ensure your content is consistent, accessible, and reader-friendly for everyone! Rich text formatting elements carry specific meaning, which assistive technologies rely on to convey information to specific users. Headings Visually, headings represent hierarchy through different font styling and allow users to quickly scan content. Programmatically, they allow users who can’t see or perceive the visual styling to access the same structural ability to scan. Heading elements should reflect the structure of the content. So your title should go in ‘Heading 1’ formatting, your next subheading will go in ‘Heading 2’ formatting, and so on. To ensure your content reads correctly to screen reader users, don’t use HTML heading styling to represent emphasis, and don’t use bold to make text appear like a heading. Lists (bullets/numbering) Always use bullets or numbered lists using the provided formatting to convey a list. A screen reader will announce that the following information is a list. Links How a link is formed significantly impacts usability. Consider the following sentence: “To find out more about this topic, complete our Intro to Code Injection lab here.” Links are interactive elements, which means you can navigate to them using the tab key. A user who relies on screen magnification to consume content may choose to tab through content to see what's available. The example above would be communicated as just “here”, which provides no context. They’d need to manually scroll back to understand the link’s purpose. Always use descriptive link text that clearly indicates its destination. Avoid ambiguous phrases like “here”. If that’s not possible, ensure the surrounding text provides clear context. “To find out more about this topic, complete our Intro to Code Injection lab.” Bold Only use bold for emphasis! Avoid italics, capital letters, or underlining (reserved for hyperlinks) to prevent confusion. Consistency in formatting reduces cognitive load, making your text more accessible. Bold stands out, provides better contrast, and helps readers quickly identify key information. Avoid italics With 15–20% of the population having dyslexia, italics are worth avoiding because research shows it’s harder for this user group to read italic text. Italics can sometimes bunch up into the next non-italic word, which can be difficult to comprehend or distracting to read. Media If you’re adding media to your labs, such as videos and images, it’s especially important to consider those who use assistive technologies. These users need to have the same chance of understanding the content as everyone else. They shouldn’t miss out on crucial learning. What is alternative text? Alt text describes the appearance and function of an image. It’s the written copy that appears if the image fails to load, but also helps screen reading tools describe images to visually impaired people. Imagine you’re reading aloud over the phone to someone who needs to understand the content. Think about the purpose of the image. Does it inform users about something specific, or is it just decoration? This should help you decide what (if any) information or function the images have, and what to write as your alternative text. Videos Any videos you add to your lab should have a transcript or subtitles for those who can’t hear it. Being consistent Consistency is a major thinking point for accessibility. We recommend adhering to a style guide so all of your labs look and feel consistent. We recommend thinking about the structure of your labs and keeping them consistent for easy navigation. In our labs, users expect an introduction, main content, and a concluding “In This Lab” section outlining the task. This helps users recognize certain elements of the product. It reduces distraction and allows easier navigation on the page. For example, some users prefer diving into practical tasks and referring back to the content if they need it. By using the same structure across your lab collections, your users will know exactly where to find the instructions as soon as they start. TL;DR It’s crucial to focus on accessibility when writing your custom labs. Utilise the built-in rich text formatting options in the Custom Lab Builder (and stay consistent with how you use them!) to ensure your labs are easy to navigate for every single user. By being conscious and consistent with your formatting, every user will engage with your content better, remember the topic, and be able to put it into practice more easily, improving their cybersecurity knowledge and driving their cyber resilience. No matter how they consume content. Keep your eyes peeled for the next blog post in this series, which will look at inclusive language. Share your thoughts! There’s so much information out there on creating accessible content. This blog post just focused on the language, structure, and current formatting options available in the Custom Lab Builder. Have you tried to make your labs or upskilling more accessible, and how did this go down with your users? Do you have any other suggestions for the community on how to write content with accessibility in mind? Share them in the comments below!From Feng Shui to Surveys: How User Feedback Shapes Immersive Labs
We’ve all been asked to give product feedback in one way or another – a pop-up message after completing a purchase, an email asking how your visit went, or a poll appearing on your social media feed. They all have one thing in common: a real person behind them, looking for valuable insights. I’m one of those people! My role as Senior UX Researcher involves speaking to Immersive users and gathering their feedback to help the company make tangible improvements. UX, or user experience, is at the heart of what I do. And it’s been around for longer than you might think. What is UX? It’s believed that the origins of UX began in 4000 BC with the ancient Chinese philosophy of Feng Shui, the spatial arrangement of objects in relation to the flow of energy. In essence, designing the most user-friendly spaces possible. A short skip to 500 BC, and you can see UX at play with the Ancient Greeks' use of ergonomic principles (also known as human factors), defined as “an applied science concerned with designing and arranging things people use so that the people and things interact most efficiently and safely.” In short, people have been concerned about creating great user experiences for thousands of years. How does Immersive get feedback? Bringing you back to the present day, let me walk you through a recent research study undertaken with Immersive Labs users and what their experiences and feedback led to. In May this year, we sent out a survey to our users asking them about their needs for customised content. The feedback was given directly to the team working on the feature, helping to inform their design choices and confirm or question any assumptions they had about user needs. In July, we invited users, including Training Manager and community member mworkman to take part in a pilot study for the Custom Lab Builder, giving them exclusive access to the first iteration of the feature. They could use the builder in their own time, creating real examples of custom labs using their own content and resources. This gave them a realistic experience and highlighted issues along the way. What does Immersive do with that feedback? In August, those users joined a call with us to provide their feedback and suggestions. From these calls, we gained insights and statistics that were presented to the entire Product Team, voicing our customers’ needs. We then used this to shape the direction of the lab builder feature before its release. Customers told us that they wanted to create labs based on their own internal policies and procedures, which would require more flexible question-and-answer formats for tasks. They also wanted more formatting options and the ability to add media to labs. In response to this feedback, we increased the number of task format types from three to five, and we’ll continue to add to this. We also added the ability to include multiple task formats in the same lab. Users also now have the option to upload images and include rich text within their custom labs, enhancing the layout and customisation experience. The Custom Lab Builder was released in October 2024 with an update pushed in December, and we’re still working on improving it! Throughout this first quarter of 2025, we’ve released more new features, including drag and drop, free text questions, and instructional tasks in the Lab Builder. How can you get involved? Once again, we’ll be calling on our users to give feedback on their experiences with these features, continuing to involve you in our design process to ensure that our products and experiences reflect what users are looking for. Throughout 2025, Immersive Labs will be providing opportunities for our users to come along to feedback sessions, have their opinions heard through surveys, and many more exciting chances to talk to the people behind the product. Follow our Community Forum for hot-off-the-press opportunities! For more guidance on Lab Builder, visit our Help Center.From Concept to Content: A Deep Dive into Building and Critically Analyzing Labs
Putting it all together The main bulk of the development work is building the labs. This usually comprises two parts that require different skill sets; one is putting together the written portion of the lab (such as the briefing, tasks, and outcomes), and the other is implementing any technical needs for the practical side of the lab. While some labs may focus more on one component than the other, this general overview of lab development will demonstrate each step of the process. Developing written content Regardless of the lab, the written content forms the backbone of the educational material. Even with prior knowledge and planning, additional research is essential to ensure clear explanations. Once research is complete, an outline is drafted to focus on the flow, ensuring the information is presented logically and coherently. This step helps enhance the final product. The final step is turning the outline into the final written content. Everyone approaches this differently, but personally, I like to note all the points I want to cover in a bullet list before expanding on each one. This method ensures all necessary information is covered, remains concise and clear, and aligns with learning outcomes and objectives. Technical implementation For practical labs, technical setup is key. Practical tasks should reinforce the theoretical concepts covered in the written portion, helping users understand the practical application of what they’ve learned. Before implementing anything, the author decides what to include in the practical section. For a CTI lab on a vulnerability, the vulnerable software must be included, which involves finding and configuring it. For general topics, a custom script or program may be needed, especially for niche subjects. The key is ensuring the technical exercise is highly relevant to the subject matter. Balancing the difficulty of practical exercises is crucial. Too easy, and users won’t engage. Too hard, and they’ll get frustrated. Tasks should challenge users to think critically and apply their knowledge without discouraging them. This requires iterative testing and feedback to fine-tune the complexity. The goal is to bridge the gap between theoretical knowledge and real-world application, making learning effective and enjoyable. Quality assurance and finishing touches The development process is complete, but there’s still work to do before releasing the content. We take pride in polishing our content, so the final steps are crucial. Checking against expectations Before the official QA process, we review the original plan to spot any discrepancies, such as unmet learning objectives or missing topics. While deviations don’t always require changes, they must be justified. Assuring quality A thorough QA process is vital for catching grammatical errors, technical bugs, and general improvements before release. Each lab undergoes three rounds of QA, each performed by a different person – two rounds of technical QA, and one for presentation. Some of the steps taken during technical QA include: Verifying written content accuracy, flow, and completeness. Ensuring all learning objectives are covered. Identifying any critical bugs or vulnerabilities that would allow users to bypass the intended solution. Providing small tweaks or changes to tasks for clarity. Assigning relevant mappings (NICE K-numbers, MITRE tags, CWEs). After technical QA, the lab is reviewed by our quality team to ensure it meets our presentation standards. Once all labs in a collection pass rigorous QA, they are released for users. The final step occurs post-release on the platform. Gathering and implementing user feedback Users are at the heart of everything we do, and we strive to ensure our content provides real value. While our cyber experts share valuable knowledge, user feedback prevents echo chambers and highlights areas for improvement. After new releases, we conduct an evaluation stage to analyze what went well and where we can improve. User feedback We gather quantitative and qualitative feedback to help us identify root issues and solutions. Quantitative feedback involves analyzing metrics like completion rates and time taken. We also examine specific changes, such as frequently missed questions or labs where users drop out. These are important things to note, but we avoid drawing conclusions solely from this data. This is where qualitative feedback comes in. Qualitative feedback includes user opinions and experiences gathered from feedback text boxes, customer support queries, and direct conversations. These responses are stored and read by the team and provide context beyond raw numbers. Channels such as customer support queries and follow-ups with customers also help us improve our content. Post-release reviews We conduct post-release reviews at set intervals after content release to analyze quantitative and qualitative data. This review helps us assess the entire process and identify areas for improvement. These reviews allow us to update content with new features, like adding auto-completable tasks for CyberPro. The reviews ensure our content remains current and enhances user experience. Wrapping up Hopefully, this blog post has provided insight into all the care we put into building and tailoring our content for users. This process has come a long way since we started making labs in 2017! Don't forget — with our new Lab Builder feature, you can now have a go at creating your own custom labs. If there's a topic that interests you and you want to share that knowledge with your team, making your own lab is a great way to do it! If there’s any part of the process you’d like to know more about, ask in the comments. Are there any collections that made you think, “Wow, I wonder how this was made”? Let us know!From Concept to Content: Laying the Foundations of a Lab Collection
Technical planning At this stage, we address niche technical details not covered in initial planning but crucial for polished content. Below is an example of the question-and-answer process used for the “Web Scraping with Python” collection. Should the practical sections of the content be created using Docker, for optimal speed and modularity, or does the subject matter require the use of a full EC2 instance? As there are no unusual requirements for the technical portion of the collection (such as needing kernel-level access, network modifications, or third-party software that doesn’t run in containers), the labs can run on Docker. This is a benefit not only for the overall user experience, but also allows for image inheritance during development, which will be demonstrated a bit later on. Are there any tools, custom scripts, or system modifications that should be present across the whole piece of content? The collection is based around writing Python scripts, so ensuring that Python is installed on the containers as well as any required web scraping libraries is a must. In addition, some considerations for user experience can be made, such as installing an IDE like Visual Studio Code on the containers. How can task verification be implemented to make sure it’s both robust and non-intrusive? In the case of this collection, implementing auto-completable tasks may be difficult due to the variety of ways users can create solutions, as well as the lack of obvious traces left by web scraping. Instead, it may be more appropriate to insert task solutions into a mock website that needs to be scraped, which the user can retrieve by completing the task and providing the solution in an answer box. Understanding the technical requirements for a piece of content helps to bridge the gap between planning and development, making it a crucial step. With some of the key questions answered, it’s time to move on to implementation. Creating base images It’s finally time to put fingertips to keyboards and start programming! The first part of implementation creates what all labs in a collection will be built on – a base image. This is a skeleton that provides all the necessary tools and configuration needed for the whole collection, using a concept called image inheritance. If you're new to containerization software like Docker, don't worry – image inheritance is straightforward. Docker containers use images as blueprints to create consistent, mini-computers (containers). This is useful for labs because it allows you to quickly create a pre-configured container without the overhead of setting up a virtual machine, saving time and system resources. This is where image inheritance comes in. Docker images can inherit traits from parent images, similar to how you inherit eye color from your parents. Instead of one central image for all purposes, you create a parent image with shared requirements and then customize descendant images for specific needs. Let’s use the “Python for web scraping” collection as an example again. Think about what kind of things would need to be present in each lab: An installation of Python so the user can run scripts. A code editor to write the scripts in. A mock website for the user to test their scripts on. The first two of these requirements are essentially the same in every lab; there’s no real need to change the installation of Python or the code editor, and in fact, it would be better to have them all be identical, which would result in a smoother user experience. The third, however, does need to be changed — the specific task requirements are going to be different from lab to lab, and the website files will need to change to accommodate this. Taking into account the requirements, an inheritance structure like this can be used: Base image – Python installation and code editor present Lab 1 – Custom website files Lab 2 – Custom website files Lab 3 – Custom website files … Structuring images this way saves time, disk space, and development work by reusing shared configurations. Next time… In part three of this mini-series, you'll learn about the final stages of content development: creating labs, quality assurance, and release. To be notified when part three is released, follow The Human Connection Blog using the bell icon. Meanwhile, feel free to ask questions about the content creation process or specific collections in the replies. Have you used the Lab Builder feature to make any custom labs yet?From Concept to Content: A Deep Dive into Theorizing and Planning a Lab Collection
The decision process When creating new content, the first step is deciding what to commit to. We consider: User demand: Are users frequently requesting a specific topic? Evolving landscapes: Is there new technology or industry trends we should cover? Internal analysis: Do our cyber experts have unique insights not found elsewhere? Overarching goals: Is the content part of a larger initiative like AI security? Regulations and standards: Can we teach important regulations or standards? Cyber competency frameworks: Are we missing content from frameworks like NICE or MITRE? After considering these points, we prioritize one idea for creation and refinement. Lower-priority ideas are added to a backlog for future use. Feasibility and outcomes Having a concrete idea is just the beginning. Over the years, we’ve learned that understanding the desired outcomes is crucial in planning. Our core mission is education. We ensure that each lab provides a valuable learning experience by setting clear learning objectives and outcomes. We ask ourselves, “What should users learn from this content?” This ranges from specific outcomes, like “A user should be able to identify an SQL Injection vulnerability”, to broader skills, like “A user should be able to critically analyze a full web application”. Listing these outcomes ensures accountability and fulfillment in the final product. Setting clear learning objectives involves defining what users will learn and aligning these goals with educational frameworks like Bloom’s Taxonomy. This taxonomy categorizes learning into cognitive levels, from basic knowledge and comprehension to advanced analysis and creation. This ensures our content meets users at their level and helps them advance. Turning big topics into bite-sized chunks Once a topic is selected, we must figure out how to break down huge subject areas into digestible chunks. This is a fine balance; trying to cram too much information into one lab can be overwhelming, while breaking the subject down too much can make it feel disjointed. One good approach is to examine the learning objectives and outcomes set out in the first step, map them out to specific subtopics, and finally map those to labs or tasks. For example, consider this theoretical set of learning outcomes for a Web scraping with Python lab collection. A user should understand what web scraping is and when it’s useful. A user should be able to make web requests using Python. A user should be able to parse HTML using Python. A user should understand what headless browsers are and when to use them. A user should be able to use a headless browser to parse dynamic content on a webpage. These outcomes can be mapped into two categories: theory outcomes (“A user should understand”) and practical outcomes (“A user should be able to”). Understanding the difference between these two is useful, as a few things can be derived from it – for example, whether to teach a concept in a theory (heavy on theoretical knowledge without providing a practical task) or practical (teaching a concept and exercising it in a practical environment) lab. Using this, the outline for a lab collection can start to take shape, as seen in the table below. Learning outcome Knowledge Type Suggested Lab Title Suggested Lab Content A user should understand what web scraping is and when it is useful. Theory Web scraping with Python – Introduction A theory lab showing the basics of web scraping, how it works, and when it is useful. A user should be able to make web requests using Python. Practical Web scraping with Python – Making web requests A practical lab where the user will write a Python script that makes a web request using the “requests” library. A user should be able to parse HTML using Python. Practical Web scraping with Python – Parsing HTML A practical lab where the user will write a Python script that parses HTML using the “beautifulsoup” library. A user should understand what headless browsers are and when they should be used. Theory Web scraping with Python – Understanding headless browsers A theory lab explaining why dynamic content can’t be scraped using previous methods, and how headless browsers can solve the issue. A user should be able to use a headless browser to parse dynamic content on a webpage. Practical Web scraping with Python – Using headless browsers A practical lab where the user will write a Python script that scrapes dynamic content from a website using the “puppeteer” library. All Demonstrate Web scraping with Python – Demonstrate your skills A demonstrate lab where the user will complete a challenge that requires knowledge from the rest of the collection. Each learning objective is assigned to a lab to ensure thorough and user-friendly coverage. Often, multiple objectives are combined into one lab based on subtopic similarity and the total number of labs in a collection. The above example illustrates the process, but extensive fine-tuning and discussion are needed before finalizing content for development. Next time… In part two of this mini-series, you’ll read about the next stage of the content development process, which involves laying the technical foundations for a lab collection. Don't miss the Series… You can opt to receive an alert when part two of this series is released, by “following” activity in The Human Connection Blog using the bell at the top of this page. In the meantime, feel free to drop any questions about the content creation process in the replies. Are there any parts of the planning process you want to know more about?Feature Focus: Introducing Drag and Drop, Free Text Questions, and Instructional Tasks in the Lab Builder
I’m excited to announce the latest updates to the Lab Builder. Today, we’ve introduced three new task types: Drag and drop Free-text questions Informational/instructional These exciting new task features will enhance the flexibility and interactivity of your labs, offering even more engaging learning experiences. The new tasks can be added to your lab as usual via the Tasks library. They’re live now, so you can start adding them to your labs right away. Drag and drop Drag-and-drop is a dynamic, interactive task. Designed to challenge the user's recognition and matching abilities, it’s perfect for testing their knowledge in various subjects. This task type consists of text-based items and targets. Users need to drag the items to the correct corresponding targets. It’s easy to add and edit items and targets in the Lab Builder quickly. You can have a minimum of two items and a maximum of 12. You could use the drag-and-drop task type for questions and answers, completing sentence fragments, or matching terms with definitions. Once added to your lab, the new task will appear as follows: Free-text questions This task type requires the user to manually enter text to answer a question. For this task type, you need to write a question and provide at least one possible answer – but there can be multiple correct answers. You can configure this easily in the Lab Builder. Fuzzy matching automatically detects answers that are close enough to the correct answer. For example, if the user submits the right answer with a minor spelling error, it’ll still be accepted. This is designed to reduce user frustration and is enabled by default. You can disable fuzzy matching by turning off the toggle at the bottom. Finally, you can also provide feedback to users if they get an answer wrong, sort of like a hint. This is useful if you want to help point your user in the right direction and prevent them from getting stuck. Instructional tasks This task type is designed to provide users with vital information, guidelines, or instructions. In the Lab Builder, they have the same configuration options as the Briefing panel. Instructional tasks are particularly useful in explaining what the user is expected to do in a following task, presenting story details, or providing a learning journey for users as they go through the lab. You may want to remind users about specific information they need to answer some tasks or tell them to log into an application. The example below reminds users to refer to a specific part of the briefing panel before answering the next questions. Why are these new features useful? Increased engagement: These new question types introduce a gamified element to your custom labs, making learning more interactive and enjoyable. Versatile content creation: These features expand the possibilities for creating diverse and engaging labs, allowing you to tailor your content to your organization's unique needs. Enhanced learning: Drag and drop encourages active recall and association, while free text questions promote critical thinking and deeper understanding. Go and build some engaging labs! Explore the possibilities and build labs that truly engage your users! For more guidance, visit our Help Center, where there’s ample documentation on using the Lab Builder in more detail.
