User-Centered Design For Your LMS Development Process
In recent months, I have been proactively involved in a number of LMS (Learning Management System) re-engineering projects. We had to tailor the LMSs that are already in use by the training providers to the stakeholders’ (aka the learners & the trainers) needs.
Being a proponent of the User-Centered (UCD) approach (see my recent “eLearning Platform Development: Implementing 3 User-Centered Design Standards’’ article), I always wonder: why do the LMS developers so often end up having to re-engineer their systems in the first place? Why do problems and challenges start occurring so fast? After all, even if they opt not to use a formal UCD methodology, they surely do consider their stakeholders’ requirements and presumably have an adequate understanding of who the stakeholders are and, at least, a rough idea what they want.
In my opinion, the problem lies in the dissonance between “perceived expectations of the User Requirements’’ and the “ACTUAL User Requirements’’. When not applying a UCD methodology throughout the development process, developers often think they have a complete picture to materialize but, in reality, they are simply carrying out their tasks on a basis of a range of isolated “snapshots’’ of what they believe the users want. The paradox lies in the fact, that the majority (if not all) of these snapshots is likely to be realistic and, therefore, representative of the users’ needs. However, without a UCD methodology, it is often impossible to link these snapshots to one another and to integrate them together. Consequently, overseeing the entire User Experience becomes impossible!
Below are the 3 user expectations versus reality challenges that highlight the importance of proactive user involvement throughout all stages of the LMS development processes:
1. Users Often “Do Not Know What They Want’’
When LMS developers do not take user requirements gathering seriously enough and do not have a consistent approach to validating those requirements, it is only after the project is completed already, that they may discover that the stakeholders are finding the project’s outcomes unsatisfactory due to failure to address their needs and requirements.
Gathering user requirements for an LMS cannot be completed without explaining to the respective users what the UCD process is all about and clarifying that when asked about their requirements, they do understand the questions!
UCD is all about capturing users’ need and requirements and translating them into concrete system facets. For example, there is no point in asking the users to explain: “How important online timetabling/enrolments is to you?’’. It is much more effective to attempt to identify what the features of the online timetabling/enrollments system that they find critical are.
2. Conflicting User Requirements
LMS users singing-out their requirements in unison and harmony is yet another unrealistic expectation UCD developers might be having. The user requirements gathering process is likely to identify a number of diverse perspectives across the user communities. It is as simple as that: different users have different requirements! Therefore, when tailoring the systems to the needs of a particular user group, the developers need to make sure that the task is not carried out at the expense of other user groups that may not be equally comfortable with the system implemented.
Juggling between the conflicting user requirements is where LMS developers are facing arguably the greatest challenge of all. From the UCD perspective, the system should allow as many customization options as possible but it is not always realistic to address each and every one of the requirements fully. As delivering a “complete universal solution’’ that is ideal for all of the users is seldom a realistic option, the conflicting user requirements should be identified and compromised solutions found.
Let’s consider the challenge of optimizing the timetabling/enrolments LMS function once again:
Students commonly want to be able to enroll from anywhere in the world without even minimal disruptions and without having to obtain any conformations/permissions along the way. However, the training provider may be concerned that such a “smooth’’ and “user-friendly’’ path may lead to students enrolling themselves into the wrong subjects and courses by mistake and would like to see the enrollment process delivered in a more sophisticated but consequently slightly less user-friendly manner where no enrollment is complete without a faculty member confirming. In some cases, the enrollment process complexity may range from faculty to faculty as some courses may include a set list of compulsory subjects only, while other courses may be structured in a way that requires selection of multiple electives including providing students with a possibility of taking up electives from other faculties. Technical and managerial requirements for delivering these 2 scenarios will obviously vary dramatically.
3. Ever-Shifting Nature Of The Expectations’ Paradigm
Traditional UCD approach to developing Learning Management Systems involves considering current requirements and aspirations of the users. However, we need to accept that user requirements do change over the time and, given the time frame, it usually takes the developers to get the projects completed and to roll out the LMSs—we may end up chasing the past dreams rather than the current ones. This is due to a number of reasons such as the rapid pace of the eLearning development with new eLearning-related technologies, processes, and applications emerging all the time, changes to the eLearning services delivery and, last by not the last, ongoing evolution of the service delivery approaches across the industries.
In order not to end up with a so-called PUCD (Past User-Centered Design) instead of a UCD, we often need to ensure that the users’ feedback is gathered continuously throughout the project, and adjustments are made based on this respective feedback. It is obviously impossible to develop an LMS that will withstand the test of time completely (no system can do that) but we can, at least, try to address new developments and updates to the UCD requirements as much as possible.
To sum up, we should never forget that the LMS user expectations are expectations of the users rather than our expectations of what the user expectations are!
