Designing and deploying information technology systems is a perfectly tame (although complicated) process. The rules for configuring systems are well-known and predictable; knowing how we want to configure them can be more challenging, but the process is well-known. Also, the rules for configuring IT systems are the same regardless of the nature of the work done within the organization. We follow the same procedures for configuring IT in educational organizations as we do in other businesses.
Despite following the same rules as others IT manager, those who manage IT in educational organizations face much different challenges compared to those who work in business. Perhaps the most challenging aspect of school users is the fact they rarely know exactly what they will want the IT to do. Also, the IT is one of several tools the educator may choose to use. Further, many educators have been practicing their craft with other tools, so they may be reluctant to adopt and adapt when new options arise.
The idea of technology acceptance has been widely adopted by scholars who study and technicians who deploy IT in many businesses and industries (but education has been late to adopt it). Technology acceptance has been the focus of other posts, so I won’t repeat what can be found elsewhere, but the idea of user perceptions (which is central to technology acceptance) has been important in my thinking recently.
Technicians and designers may create systems that they find easy-to-use and effective, but the educators and students who use the systems may not find them so. Many technology professionals spend hours and hours behind keyboards and mice, looking intently at screens and the interfaces we use to interact with systems. From this position, they become very facile at things others find it difficult to follow.
The problem is exacerbated by the fact that technicians are not always the best teachers, and teachers are not the best students. My message to IT people is “slow down;” “explain what you are doing and why you are doing it,” then when you are done, “repeat the steps, and let others do it themselves.” My message to teachers is “pay attention,” “takes notes,” and “make sure you understand your notes when you leave,” then “practice on your own.” It amazes me sometimes what poor students teachers can be.)
IT professionals must accept, however, that users’ perceptions of the systems they build are reality. If they say it is “too hard to use,” it is. You have an obligation to fix it.
If they say it is not effective, then it is not. The first step in fixing it is listening to them and asking questions until you understand exactly what they want. This rarely happens in your first conversation, or even the second or third. Listen. Build what you heard them say, then change it when they complain you did not meet their needs. The response from IT, “Well, it might not be want you wanted, but it is what you told me you wanted,” is not acceptable in organizations that depend on digital tools.