This year I will finally be able to put some effort into PDQMac.com, the site I’ve set up with the aim of improving people’s interface productivity. If there’s a key underlying point to what I’ll be doing with that site, it is this:
Productivity is all about muscle memory.
So I’d better explain what that means before I go any further. Let’s start with the fact that nearly all of us have learned how to drive a car and have a memory of that learning process. There are quite a few physical things that have to be learned in order to drive a car that you simply did not know before you started to drive; including managing the accelerator, brake, steering, winkers, and stick-shift (if you learned on a stick-shift car.) You were, no doubt, told how all of these controls worked, but you couldn’t drive properly just because you knew how to with your thinking brain. You had to keep practicing until your body learned how to use these controls. And nowadays, years after, you never think about most of the controls or how you use them because they are perfectly stored in your “muscle memory.”
Muscle memory is the automation of behavior and most of what we do, including for example, how we pronounce words, involves muscle memory. As regards computer interfaces, the simple truth is that the PC interface has not been designed with muscle memory in mind. In fact, at times it seems to be designed almost to defeat muscle memory. So let’s forget that abysmal interface for the moment and talk about interfaces that are built with muscle memory in mind.
- Guns and Fighter Planes. You may have noticed that an AK47 has no drop-down menus. Does that surprise you? The popularity of the AK47 (I’m no gun expert by the way) is generally that it’s dependable, easy to maintain and the interface is true point and shoot. Although fighter planes are far more complex than guns, the design of fighter planes follows the same principle. You really don’t want the pilot who is caught in a dogfight to be wandering whether the “Shoot Cannons” command is on the Format Menu or the Tools Menu.
- Cars. Once Ford got the driving interface buttoned down on the Model T, all cars that came after adopted very similar interfaces, to the point where now, when you change cars, your learning curve is minimal – usually a few minutes. A software writer I know, whom I’ve discussed this topic with at length, tells me that it took a few attempts to get the Model T right, with the first model T using controls that were based on farm machinery. Notice how much more of a learning curve can be involved when a major revision of Windows or MS Office occurs. Sometimes users even have to be retrained.
- Games Machines. Luckily we have games machines to prove indisputably that computer interfaces can be very productive. And notice how successful both the iPhone and the Wii have been, partly I suspect because they’ve added interface features that are very effective in terms of muscle memory.
This gets me to the point where I think I can define what a “muscle memory interface” is:
It is one that is built so that controlling the device or environment can be done with minimal need to engage the thinking part of the brain.
The very fact of the keyboard and mouse, and the need to switch between them makes it very difficult to establish muscle memory in some usage contexts and in other contexts, the tendency is for the user to remember really slow ways to do things. Yes, actions get committed to muscle-memory, but the outcome is not productive.
The software writer I mentioned above (Tim Negris) has written an application for manipulating photos. It runs on Windows and every effort has been made to design it with muscle memory in mind. Over the next few days I will be using it and I’ll give it a full review when Ive used it enough to comment on its interface.

























This reminds me of how much I would love to love Blacktree’s Quicksilver. More importantly, this explains why I have yet to fully integrate it into my workflow.
Thanks for shedding light on this important topic.
To dig deeper, it seems that the muscle-memory user interface (MMUI) has a few common attributes appearing in most of its manifestations.
1. Task Path – the order in which things must be done to get the desired result. Gun: Ready, Aim, Fire. Game: Find Key, Open Door, Kill Dragon. Car: Check Mirrors, Signal, Change Lanes.
2. Step State – the extant processes and conditions in effect at any point within a task path. Gun: Aiming in Motion. Game: Dodging Fireballs. Car: Lane Merge.
3. Essential Modality – the necessary conditions that must be in effect at any given step state. Gun: Have Ammunition. Game: Know Secret Code. Car: Headlights On.
Thinking more specifically about muscle-memory user interfaces for computer applications, the venerable status quo is the “Desktop/Document” UI. It was created by Xerox PARC researchers more than twenty years ago when storage, memory, and throughput were measured in KBs, not MBs, GBs, and even TBs as they are now.
Despite some valiant attempts to rethink the DDUI along the way, e.g. the IBM/Apple Pink and Taligent projects, it became and still is the norm for most Windows and Mac applications.
Menus, icons, and dialog boxes have their rightful place across computing, but that doesn’t explain why the general UI form and function in Microsoft Word and Adobe Photoshop are substantially the same. The task path for writing a document has little similarity to the one for editing a photograph, and yet both programs have a “File” menu, from which you can “Exit” the program.
In the Desktop/Document model, the function of the application largely follows the form of the UI. Those who find this OK will likely point out that it reduces the learning curve for any individual application when all applications follow the same design guidelines.
To me this sounds like the Golden Hammer (http://en.wikipedia.org/wiki/Golden_hammer).
Be that as it may, it seems that there are many task paths that go un-automated or are poorly automated because they simply cannot be made to conform to the DDUI model.
They tend to be *practical* (as opposed to cerebral or computational) task paths, e.g. music education, auto repair, land survey, or (shameless plug) photo editing.
And then, finally, as the computer itself morphs into a smart phone, where the screen small and typing and pointing functionality are limited, UI interaction is in itself a practical matter and the DDUI model is further taxed, and in a more essential way.
I hope you and readers will continue to explore this topic in the future, as I feel that there is a growth industry to be had in rethinking the UI.