Developing an inclusive Open Science training resource requires more than good content. FEMLEAD’s work on the Virtual Learning Lab shows why usability, localisation, testing, audience definition and practical tools must be treated as central design choices from the start. 

 Open Science (OS) training tends to centre on access. Teams put materials online, open up courses and share resources under open licences. These are necessary steps, but they are not sufficient. A training resource can be open and still be hard to use. It can be multilingual and still read unevenly across languages. It can address inclusion as a topic while failing to practise inclusion in its own design.  

FEMLEAD’s work on the Virtual Learning Lab (VLL) has made this lesson plain. FEMLEAD developed the VLL to help higher education institutions (HEIs), researchers, students and wider stakeholders connect gender equality with OS practice. It draws together material on institutional change, Gender Equality Plans, inclusive participation, leadership and the FEMLEAD methodology. 

The resource remains in development. Even so, the beta phase has already produced useful lessons for any team building open, inclusive or multilingual training materials. The main lesson is simple. Designers must build inclusion into the learning experience, not only treat it as content. 

Start with the user, not the platform 

Many digital training projects start with the platform and fit the learning around it. FEMLEAD’s experience points to a better starting point: the user’s situation. Who will use the resource? What do they already know? Are they academics, students, equality officers, project managers, community organisations or policymakers? Will they use the material in a workshop, alone at a desk, on a mobile phone or as part of institutional planning? 

These questions shape the whole design. They affect what counts as reasonable text, how examples should be framed, how technical terms are explained and whether users need worksheets, checklists, case studies or short videos. During FEMLEAD beta testing, users valued the content. Feedback also called for clearer signposting, lighter text density and more visible practical tools. That distinction matters. Strong content still needs a clear route through it. 

For other teams, the lesson is to define user pathways early. A single open resource may need several routes: a short introductory path for new users, a more detailed path for institutional staff and a practical path for those applying the material in teaching, research or policy work. 

Treat usability as an inclusion issue 

Project teams sometimes treat usability as a technical matter, addressed after the content is complete. Inclusive training requires a different view. If users cannot find what they need, complete an activity, use the resource on their device, or easily return to a section, the resource is less inclusive in practice. 

FEMLEAD’s evaluation showed a useful contrast. Participants rated the information highly clear. They rated ease of use, findability and intended future use lower. In other words, the material had value, but the user experience needed refinement. 

Many open education projects can apply this lesson. Navigation, mobile performance, menu labels, progress indicators and download links are not secondary details. They determine whether people can work with a resource at all. For inclusive OS training, this matters more still, because the audience may include users with different roles, confidence levels, languages and technical habits. 

A practical rule follows. Test the learning flow, not only the learning content. Ask users whether they understood the material, but also whether they could find it, move through it, return to it and imagine using it again. 

Build practical tools into the resource 

Inclusive OS training should help users think differently. It should also help them act differently. Practical tools carry that weight. Checklists, planning templates, self-assessment questions, workshop prompts and example action plans help users apply abstract concepts in their own setting. 

Users and partners told FEMLEAD they wanted the applied elements to be more visible. The VLL already holds a range of digital resources. The evaluation still recommended making downloadable tools easier to find and strengthening the resource pack linked to the modules. 

The broader lesson for training design is this. If a resource sets out to support institutional change, the applied material should not be left to the end. Designers should build it into the learning pathway. Users should come away not only with a better understanding of gender equality and OS, but with something they can use in a meeting, a course, a project plan or a departmental discussion. 

Test with real audiences, then listen carefully 

The value of beta testing lies in the gap between what a project team assumes and what users experience. FEMLEAD’s national training sessions showed that the VLL is understandable, relevant and promising. They also showed where improvements were needed: clearer navigation, wider device testing, more consistent localisation and stronger practical guidance. 

This feedback is not a weakness in the resource. It is evidence that the design process is working. A training platform concerned with inclusion should be open to correction. Project teams should test it with different users, revise it in response and improve it before wider release. 

For others developing similar resources, the lesson is to plan feedback as part of the work, not as a final reporting requirement. Build in time for revision. Reserve time during workshops for participants to complete feedback forms. Ask open questions about what users found useful and what remained unclear. Then use that evidence to make concrete changes. 

From open access to usable participation 

The central lesson from the FEMLEAD VLL is plain. Open training resources must be designed for use, not only made available. That means clear structure, accessible design, multilingual consistency, practical tools and honest testing with intended users. 

For projects working on gender equality, STEM and OS, this lesson has wider relevance. Adding a module on inclusion does not achieve inclusion. Inclusion comes through decisions about language, format, design, examples, technical access and feedback. A resource becomes more inclusive when users can understand it, move through it, adapt it and apply it in their own institutional or professional setting. 

FEMLEAD’s beta-stage work has shown that the VLL has a strong foundation and clear value. It has also shown where the next refinements belong. For other teams, this may be the most useful message. Do not wait for a resource to be perfect before testing it, but do not treat publication as the end of the design process. Inclusive training improves when it is used, questioned and revised. 

 Want to experience the VLL yourself? Create your account now and start exploring all modules.