The need to Involve end-users and management in the Software Development Process
Anyone who interacts with an information system in the context of his or her work in the organization can be called an end user.
Some kind of user involvement throughout the systems project is critical to the successful development of computerized information systems. However, there are also other human factors that must be taken into account by system engineers. Some points that must be taken into account are:
• Does the system require changes to the work processes in the environment? If so, training will be required. If changes are significant, or if they involve people losing their jobs, there is a danger that the system will be resisted by the user.
• Does the system de-skill the users in an environment? If so, they may actively resist introduction of the system into the organization.
• Does the system change the political power structure in an organization? For example, if an organization is dependent on a complex system, those who know how to operate the system have a great deal of political power.
• Does the system require users to change the way they work? This can be problem is it involves users undertaking tasks that are normally seen as lower status tasks. For example, lawyers may resist the introduction of a computer system because it requires them to learn to type. They may think that typing should be done by secretaries.
These factors are often significant. They may be critical in determining whether or not a system successfully meets its objectives.
Usability experts have long insisted that users should be integrated into the software development process, but it is only recently that software companies have become willing to listen to their message.
Successful user integration can only be realized if companies take the users of their products seriously, regardless of which industry the company belongs to. The software industry is maturing now. It is leaving its early stages, where technical issues matter most and where mostly "techno-geeks" are using its products. Now software is reaching the masses. "Ordinary" people do not care as much about technical issues. Instead, they want products that fit their needs. Software companies have to learn this lesson or they will not remain in the market for long.
User integration begins with a learning process inside the company. All software developers have to take users seriously. The management has to promote the vision of user integration and to provide the conditions for a user-driven development process. But this only works if developers, designers and usability people bring the process to life. In other words, a change of mind alone is not enough, there must also be the commitment to "institutionalize" such thinking by establishing a development process that integrates users and their needs.
Developing software without integrating end users may sound like a funny idea. Nonetheless, this has been common practice for years. It took a long time before software companies realized the importance of user integration. A user-oriented development process does take time and resources, but it is well worth the effort. It is the only way to achieve the goal of user-friendly software.
Which USER do you have in mind?
The Prototype User: Lots of software seems to be written with a simple "user model" in mind: Developers design applications as if they were the only users of that software. Sure, the developers know their software, so no usability problems arise. It seems that many software developers constantly have to be reminded that they are not creating software for their fellow developers.
Users Are Stupid: Sometimes users are seen as a "disturbing factor" for the developers because users inconvenience them: They run into errors, complain about the software, etc. Users are simply regarded as "stupid" because they do not know how to use the software.
Users Are So Diverse: Another common argument is that users are too diverse: One user needs this, the other needs that, and a third one might even need something else. Thus, the impression is that involving users only increases the confusion instead of settling it, thanks to the "elastic user". So many developers end up creating software that tries to be "everybody's darling", which in fact means that it is nobody's darling.
The User – The Unknown Beast: As a consequence for many developers and sometimes even interface designers and usability specialists, the user remains some sort of "unknown beast" – a phantasm based on assumptions that may or may not be true. Such practice is not a good foundation for creating software that cares for the needs of the users.
Understand the USER ENVIRONMENT
Site visits are the best way to confront developers, user interface designers and usability people with the reality of how end users actually work. Site visits include far more than letting users interact with software. They imply observing real work practice. Watching and learning how real users work can lead to software that vastly improves users' work practice and even the communication structure of the company as a whole. Site visits help identify typical users, their tasks and the context of the software-based work. They provide a wealth of data; however, user roles and scenarios are their most handy results for creating a new design. When site visits are not possible, user interests have to be promoted by "experts," various (and varied) internal members of the development team plus experienced external consultants, using brainstorming methods for exploring user roles and scenarios.
It is important that new design ideas are tested with users to ensure that the design truly fits users' needs. This is where the users and the developers collaborate. User days provide a variety of possible testbeds: Design concepts can be presented to users and discussed with them, prototypes can be tested with users, as can the final or close-to final application. All of these user inputs can help settle design issues and lead to improvements in the design. Prototypes or applications can also be taken out to the users and tested under real working conditions.
It is important to interpret and use the data gathered during site visits with care and – best – with approved methods. This ensures that design specifications are grounded in data, not in intuition.
