IBM CUA (Common User Access) Basic Interface Design Guide
Feb 2, 2019
4 minutes read

While you're reading this, keep in mind that I'm available for hire! If you've got a JavaScript project getting out of hand, or a Golang program that's more "stop" than "go," feel free to get in touch with me. I might be able to help you. You can find my resume here.

Around 1987, IBM started developing a conceptual framework for how user interfaces should behave. At the time, a “user interface” meant much more than what’s displayed on the screen, although that was a large part of it. The definition at the time included (among other things) the screen layout, functions of specific keys, general program behaviour (e.g. saving/loading records), and language used in messaging to the user. This was called the “Common User Access” guidelines, often referred to simply as “CUA”.

By 1992, IBM had written a series of documents detailing how applications should be developed to align with this conceptual framework. The one I find most interesting is called the “CUA (Common User Access) Basic Interface Design Guide”, which is available for free to read on IBM’s website.

Quoting from the introduction to the book:

The user interface is the means through which users communicate with the computer system. The Common User Access (CUA) is the definition of user interface components that should be the same across all applications. The definition is based on a set of generally accepted user interface design principles. It is optimized for ease of use and encourages learning by exploring.

That term there, “ease of use,” is particularly interesting. Its meaning has shifted over time, and now is almost completely opposite. At the time, it was related to long-term productivity - you could almost expand it to say “ease of long-term use”. An application was optimised for ease of use if it was optimised for long-term power users, e.g. if it had sensible shortcut keys, consistent behaviour, and terse (but clear) messaging.

The meaning that term has today was captured by a completely different term at the time - “ease of learning”. Again, quoting directly from the book:

An interface optimized for ease of learning is often called walk-up-and-use. This type of interface requires that applications lead users step by step through their activities and present information frequently to tell users what to do next and how to do it. New users find this very helpful. However, once they know how to use the applications, the continued presentation of tutorial information, once so welcome, becomes an annoyance.

I think this is a valuable distinction, and it seems to be something we’ve lost sight of. Modern user interface design seems wholly focused on shortening the ramp-up time for a user to reach the average level of proficiency - a useful goal, but one that can be at odds with supporting long-term users. It’s objectively easier to master an application if that application has fewer features and less granularity, but the skill ceiling is necessarily lower. To put it simply: you can get good quickly, but you can’t get that good.

This book has changed how I approach software design, particularly highlighting the different audiences an application may have. A project I’m working on right now has three distinct audiences - consumers, power users, and administrators. The consumer-facing aspects of the application are built for ease of learning. They’re intentionally limited in order to shorten the learning time (indeed, usually there is no learning time). The power user area is used by staff, is significantly more complex, and is optimised for ease of use. There is a learning period, but after that period the users can get more done with fewer actions on their parts. The administration section is the most complex, and extends so far as to have an entirely programmable interface - it’s literally a JavaScript interpreter bolted onto the side of the API, additionally exposing several external services, ready to be composed in any way the user sees fit. Learning time is much longer, but it’s undeniably quicker to work with after learning the syntax for the JavaScript environment.

The whole book is full of great advice, despite the technical details being long out of date. If this kind of thing is interesting to you, I’d suggest reading the document in its original form - it’s surprisingly approachable, and if you’re a massive nerd, makes for a nostalgic evening read. You can find it here: CUA.


Back to posts