Moodle is an open-source Learning Management System (LMS). It allows for configuration and customisation of content typically delivered in courses. The advantage of using Moodle as a foundation for the project is to save build time in the longer term by using some of its built-in existing functionality such as the ability to place users into groups for collaboration, deliver learning content and provide reporting.
The ability to customise, combined with the established underlying functions of Moodle, allowed us to test part of a complex user journey without needing extensive additional development. We were able to gather valuable insights more rapidly before iterating on the end-to-end user journey and committing to a final technical solution.
Understanding the user and business needs
As part of the Social Work Practice Development Programme, early career social workers must provide evidence to demonstrate they are meeting the post-qualifying standards (PQS). Our focus for this round of user research was 'direct observations', which will be a core assessment tool used in the programme.
A direct observation is an assessment method where a qualified practitioner watches a professional in their practice to evaluate their skills and competency.
Users need a simple method to log and share their assessments as they progress through the programme. They should be able to understand where to create and manage their direct observation records and have a clear way to collaborate on the work with their manager, observer and assessor.
We worked with a subject matter expert to determine the ideal process and requirements for a direct observation to make sure it's a valid and fair assessment. This formed the basis for the user journey we designed for testing with users.
Insights we have gathered so far
Previous user research has provided insight on how social workers currently log their direct observations, how they plan and prepare for the sessions and how they collaborate with their observer and manager during the process.
We designed with these user insights in mind:
- sometimes a complex working relationship between the social worker and the observer required a lot of back-and-forth communication
- existing forms for recording direct observations exist on a single Word document, with some sections allocated to the social worker and some to the observer. Users can find these forms overwhelming and confusing to complete
- these documents are sometimes stored on the social worker’s local computer and must be emailed back and forth, resulting in duplicate files and difficulty in keeping track of the most recent version
- social workers are often time poor and find it difficult to juggle the work involved in the programme with their day-to-day work.
We aimed to address these insights by simplifying the form, making it easier for users to know which sections they need to complete, and providing a centralised location to store and manage it within the service.
Design goals for the user research
Our challenge was to design a set of scenarios that tests a social worker’s ability to:
- select the appropriate assessment tool
- create a new direct observation record by filling out a form
- review the information they have submitted
- view a list of submissions they had entered previously
- locate and read feedback added by their observer.
Our primary goal was to create a realistic and intuitive prototype using Moodle that could be used by participants in the user research. This meant we had to:
- transform Moodle's default user interface to meet the GOV.UK Service Standard, ensuring a familiar and accessible experience for users
- structure a clear, multi-step journey for adding and viewing evidence
- ensure the prototype was robust enough to test our research questions effectively when users added realistic data.
Using the database activity in Moodle
Initially the team investigated different activities that Moodle offered as standard to see which one aligned best with the user and business needs. The closest match with most scope for customisation was the database activity as it provides a foundation for creating forms and record-keeping.
We wanted to explore how much this activity could support our design goals, and user and business needs, by default and what additional layer of customisation might be needed.
Moodle offers course owners the ability to customise the user interface using a built in HTML and CSS editor. This allowed for less reliance on the development team who were able to support by working on the ‘hard coded’ areas that Moodle does not allow to be customised by users.
Configuring Moodle to suit our design needs
Using Moodle's built-in templating system to add custom HTML, CSS, and JavaScript, we were able to override Moodle’s default styling and restructure the page layouts to be closer to GOV.UK design patterns.
The journey we tested followed several key steps:
1. The starting point: 'My assessments'
The default Moodle course page was out of scope for this test. Therefore, we bypassed this as our starting point for the journey and instead used a section page that we titled ‘My assessments’.
Before full configuration:
After configuration:
The page was restyled to remove the icons, improve the font-size and remove some of the unnecessary elements such as the breadcrumb trail, ‘mark as done’ button and section navigation.
2. The list view: 'Add new direct observation'
In the user research scenario, the user is asked how they would add a new direct observation. Initially the system is empty as they have not added any yet.
We customised this page to handle the starting point when there are no direct observations, providing a clear call to action. The button text was changed from Moodle's default to the more specific ‘Add new direct observation'.
3. The form: Capturing the evidence
The core of the journey is the form itself where the user will enter information about their direct observation.
Moodle’s default forms used within the database activity are not compliant with the GOV.UK Service Standard. To make improvements, we used Moodle's template editor to add custom HTML that incorporated standard GOV.UK design system components.
We replicated GOV.UK Design System components like text inputs and text areas adding custom CSS that copied the GOV.UK Design System equivalents.
Where inputs could not be reconfigured, we used the default Moodle option allowing for some initial checks on usability and accessibility. We will replace these with standard GOV.UK Design System components in the future.
As Moodle only allowed us to add a form onto a single page, we were unable to use design components such as the task list, which may have initially been more suited to the design. Instead, we used the GOV.UK accordion component to group complex sets of questions within the form. We mitigated the risk by simplifying the form as much as possible by reducing five sections into three, making it easier to navigate in one page.
4. The alternative 'check your answers' page
After submitting the form, Moodle directs users to a page that allows them to review their submission. We adapted this to work in a similar way to a GOV.UK Design System ‘Check your answers’ pattern, allowing users to review the information they entered in a clear, read-only format with a link to edit it, if needed.
Although it was not a direct replica of the ‘Check your answers’ pattern, the view provided a strong option to test if users found it simple to review and edit the information they had entered.
Adapting Moodle
We came up with some creative solutions to design and develop Moodle to meet our needs.
Replicating GOV.UK checkbox patterns
Moodle's default method for creating a list of checkboxes doesn't provide the necessary HTML structure to apply GOV.UK Design System styling. To solve this, we added each checkbox as a separate field in the Moodle activity. We then used custom HTML in the template to wrap these individual fields within a GOV.UK Design System style field set and legend, creating a seamless experience for the user.
This is one of several workarounds we adopted for the purpose of preparing the out-of-the-box functionality for user research. In the future we will assess whether these limitations mean that we need to consider building a custom activity type as a separate Moodle plug-in, instead of using the existing database activity type.
Collaboration with developers
While the Moodle templates gave us significant control, some elements couldn't be changed without core code modifications. Our developers made several key changes directly in the Moodle theme to finalise the prototype, including:
- adding a standard GOV.UK Design System back link to pages
- ensuring form action buttons appeared in the correct order
- removing Moodle-specific page headings and navigation elements to simplify the user journey.
This close collaboration between design and development was essential to creating a convincing and usable prototype.
We knew we would need to change our standard design approach as we were not building from scratch. We proactively adapted our approach to become collaborators with the developers, ensuring regular collaboration within Moodle itself rather than handing over a finished ‘conceptual’ design.
We used a similar approach to that of using the prototype kit but instead added the HTML inside Moodle's template editor. We were constantly iterating the design as we discovered new things we could customise in Moodle.
For example, we discovered that by using JavaScript inside Moodle's template editor, we could ‘lock’ sections of the form in Moodle that a user should not have access to or be able to change. This was not something we initially thought we could do but ended up being a key element of our design.
Next steps and conclusion
We used this customised Moodle prototype in user research to test our proposed journey with early career social workers. The findings will provide crucial evidence to inform the design and build of the next part of the service, allowing assessors and observers to view a social worker's collection of evidence and complete key tasks.
We began accessibility testing in Moodle and discovered no major issues. We found that incorporating GOV.UK components into Moodle meant they retained their accessibility functions and therefore were more likely to meet accessibility criteria like WCAG 2.2 compared to existing Moodle functions (which currently meet WCAG 2.1 criteria). We will continue to prioritise accessibility testing as we design.
Using Moodle in this way allowed us to move quickly and test a complex journey. It gave us a shared platform to collaborate on and enabled us to put a functional prototype in front of users much faster than if we had built it from scratch. This approach saved significant time and will ensure our final design is based on solid user insight.
For links and passwords to the prototypes discussed in this post, please contact the team on SocialWork.DIGITAL@education.gov.uk.