Upcoming Courses

go to course
Emotional Design: How to make products people will love
go to course
UI Design Patterns for Successful Software
87% booked. Starts in 8 days

Featured chapter

Marc Hassenzahl explains the fascinating concept of User Experience and Experience Design. Commentaries by Don Norman, Eric Reiss, Mark Blythe, and Whitney Hess

User Experience and Experience Design !


Our Latest Books

The Social Design of Technical Systems: Building technologies for communities. 2nd Edition
by Brian Whitworth and Adnan Ahmad
start reading
Gamification at Work: Designing Engaging Business Software
by Janaki Mythily Kumar and Mario Herger
start reading
The Social Design of Technical Systems: Building technologies for communities
by Brian Whitworth and Adnan Ahmad
start reading
The Encyclopedia of Human-Computer Interaction, 2nd Ed.
by Mads Soegaard and Rikke Friis Dam
start reading


A programmerism (or programmer-ism) is the inappropriate use of technical terminology used in various interfaces, which can lead the user to feel that the interface has been written in a foreign language. When a programmer or a system developer designs technical language into the interface of a product, the programmer is confronting the user with terminology that will confuse the user, make the user's task more difficult or impossible at worst. The technical terminology may be very relevant to the programmer or even the most 'correct' in technical terms, but it is still irrelevant to the user. Consider the following example (the screen dump is taken from the text editor Metapad).

Figure 1: Error message when trying to save an opened file.

The error message above appeared when the user tried to save the file being worked on. The error message uses the concept of a "process", which is not familiar to a non-technical user and will thus be confusing. Not knowing what a process is, the user is left to her own devices and must guess how to solve the problem. And since this is about saving her work, the incident will most likely be very stressful as she does not know if her work will be lost.

To the programmer, however, there is nothing alien about the error message. In fact, using the word "process" instead of "program" may in fact be more technically correct. For the technically curious reader, a process is the sequence of states of an executing program. A process consists of the program code, private data, and the state of the processor, particularly the values in its registers. Also, the process may have other associated resources such as open files (Free Online Dictionary of Computing). In our Metapad-example from above, the programmer confronts the user with this technical complexity and thus forces the user to derive which consequences it will have for what she is trying to accomplish (in this case, save a file). If the user cannot make out what a process is, she will not know how to save her file.

Differing objects of interest

It is important to keep in mind the difference in focus between users and programmers. Users are not (necessarily) interested in the technical aspects of computers, but use them as means of or tools for achieving their goals/completing their tasks. The user's focus is on her task or, more generally put, some subject matter and from the user's perspective the computer merely acts as a subsidiary tool that is put to use in this activity (see transparency). The programmer's object of interest, on the other hand, is the computer, and acquiring computer-related knowledge is an objective in itself. This may be part of the reason that system developers/programmers do not speak to the users in the user's own language as they fail to recognize that the user's domain of relevance when using the computer/the application is different from the developer's. 

Determining the right amount of technical terminology

The take-home-point of the above, is that the user should be addressed in the user's terms. This does not mean that all interfaces should communicate in abstract and completely non-technical terms or that technical terminology should be eradicated. Rather, an appropriate level of abstraction should be found so that the user is exposed to an appropriate amount of technical terminology. It should of course be acknowledged that technically generic terminology, once learned, is generalisable across many applications/products with the same underlying technical architecture.

Final Note

As a final note, the actual reason the error occurred in the Metapad program (figure 1) was that the file being worked on was opened by another instance of the Metapad program. The user did not know that the file was open in two instances of the same program and when trying to save the file from one instance of the program, a file system write error occurred because the other instance had a file lock on the file. This scenario could have been entirely avoided with a few lines of code added to the Metapad program. In other words, there was absolutely no reason for the error message to be there in the first place.


Join our community and advance:




Join our community!

User-contributed notes

Give us your opinion! Do you have any comments/additions
that you would like other visitors to see?

comment You (your email) say: Oct 25th, 2014
Oct 25
Add a thoughtful commentary or note to this page ! 

will be spam-protected
How many?
= e.g. "6"
User ExperienceBy submitting you agree to the Site Terms


 what's this?

Free On-line Dictionary of Computing, Edited by Denis Howe(Original database files available at foldoc.org). [Accessible online]

iarchitect.com (1999). Interface Hall of Shame: Terminology. Retrieved 7 August 2003 from iarchitect.com: http://web.archive.org/web/20020602184113/http://www.iarchitect.com/clarity.htm