The Never-Ending Pursuit of HCI Perfection
by Joseph Koivisto
Zhang et al., in their article “Integrating human-computer interaction development into the systems development life cycle: A methodology” (2005), make a very compelling argument for the importance of establishing a System Development Life Cycle (SDLC) at the core of which remains the human element, i.e. the user. This, in a way, makes perfect sense: systems that are not understandable, ergonomically-sound, or usable (within a certain tolerance of user skills and technical proficiency) will not be used.
And while they provide a useful framework for implementing a human-centered project plan – things such as HCI analysis during each SDLC stage, HCI matrixes that serve as useful check lists, and iterative usability testing throughout the SDLC – I cannot help but think that there is an inherent flaw in their thought process. Namely, I think that their model aims at too high of an ideal, one that cannot possibly be obtained during the development of your average (or even above-average) information system.
Let us first look to Cervone’s 2007 article “The system development life cycle and digital library development.” In it, Cervone – in a throw-away closing paragraph – declares, “Eventually, though, the new system becomes the old system and due to changing requirements and technical obsolescence, it reaches a point where it is no longer cost effective or technologically possible to continue maintaining the system in an effective manner. It is at this point that we put a new team together and start the system development lifecycle anew to define a successor digital library project” (351-2). What strikes me about this statement is the never-ending, ongoing evolution of system development that goes beyond the individual project level. Regardless of who much time, energy, and dedication is funneled into a single project, it will ultimately be replaced by some future solution that does what the initial system did, only better, faster, and not to mention better-looking.
So, what impact does this line of thinking have on Zhang et al? First, it is important to understand that their article comes as a reaction to a perceived dearth of literature and critical discourse on the topic of human-centered design in the context of SDLC materials and texts.
I would not disagree with them that there needs to be a larger conversation about HCI with regards to its importance and influence on SDLC and the individual development tasks that make up the larger project. But what I would say is that given the ongoing nature of system development and the necessary constraints of development platforms and technical capabilities, what should ultimately be the goal of the human-centered SDLC?
A few thoughts to consider:
- One can only develop as system to the extent that the available development software will allow. In terms of HCI, a system can be made as usable as the technical possibilities will allow. Things like system metaphors, color-depth, visibility, and ease-of-use are handicapped by the technical context within which they are developed. Regardless of how human-centered your development model is, there are imposed constraints on how usable, ergonomic a system you can develop. For example, look at the early operating systems (i.e. MSDOS, MAC OS System 1). The degree of usability will never be able to reach the ideal that you set out to achieve.
- Zhang et al. acknowledge that total usability is impossible. In their evaluation model (528), the set the tolerance level at 85%. Within that 15% may exist several potential users who cannot (or will not) be accommodated by the system. Therein may be hiding some unfortunate biases such as ableism, ageism, or enthocentric perspectives on usage. Regardless, this acknowledgment in their own work should be incorporated into the human-centered model as a supplementary maxim: no system is 100% usable to all users.
- Over time and through multiple stages of development iteration, usability will get better. We need not look too far to see that usability, providing that it moves along with trends in technical feasibility and development platforms, will improve. I present as an example the iPod system interface:
We see that the increased technical capabilities over time allowed for more human-centered designs such as moving from low-level black-on-grey text to full high-contrast color; better, more understandable organizational structures with visual aids (album covers); and a more expansive means of interaction (buttons, rotation pads, touch screens). The point I’m trying to make is that your system, although not bad within its own right, will be made better through proper implementation of future technologies and platforms. And while we would all hope to be like the innovative gods at Apple, we can only but acknowledge that we – and our system development skills – are merely mortal.
So, I suppose that what I am saying is not that Zhang et al are wrong; in fact, far from it. Rather, I think that they need to temper their idealism with some of Cervone’s realism. Yes, strive to make the best, most human usable system that you possibly can. Yes, repeatedly ask the tough questions about ergonomics, readability, system metaphors, and understandability. Yes, tirelessly test your systems with live users whose opinions will guide you to a better product. But, ultimately, realize your own constraints. Acknowledge that they are not flaws, but merely contextual constraints that you cannot change. And, please, understand that your system will eventually be old and no longer deemed “user friendly.”But as you set out onto the next development venture, bring along what you’ve learned. It will help to build a better foundation from which to begin.
Cervone, H. (2007). The system development life cycle and digital library development. OCLC Systems & Services: International digital library perspectives, 23(4), 348-352.
Zhang, P., Carey, J., Te’eni, D., & Tremaine, M. (2005). Integrating human-computer interaction development into the systems development life cycle model: A methodology. Communications of the Association for Information Systems, 15, 512-543.