In Bernard J. Baar's book "A Cognitive Theory of Consciousness," he describes the brain as having a single conscious area that can be occupied by one thought at a time. The unconscious part of the brain stores memories and experiences and, like the conscious brain, is capable of performing tasks; however, it does so automatically, unlike the conscious area that requires the intervention of the "self." The first time we are given a new input, sensation, or experience to deal with, the conscious brain is responsible for analyzing it, comparing it to something that has occurred before, and dealing with the action accordingly. Repeated exposure to the same input drives the response into the unconscious area of the mind, so the next time the same experience is encountered, an automatic reply can be recalled without requiring conscious intervention.

An example of this is driving a car; an extremely complex function to perform that deals with multiple inputs - many different feedback loops to control speed, direction, and so forth. Only once you have mastered how to control the mechanics of a car, via repetition and practice, can you begin to drive it around using unconscious thought and start to concentrate on inputs such as road signs, other drivers, and assorted day-to-day driving hazards. A very real problem exists that when driving the same route over and over, what should be a conscious thought process becomes unconscious, leading to more traffic accidents occurring in your own neighbourhood on familiar roads than, ironically, far from home where conscious thought needs to be engaged. The fact that the brain can only single task can be exacerbated by functions such as talking on the phone while driving; advanced driving schools recognize this when they teach better road skills by making drivers repeat to themselves everything they are seeing as they drive, helping to ensure that it's the conscious and not unconscious brain behind the wheel.

This model of how the brain performs tasks causes problems for GUI designers in two ways: the wrong consciousness is active when input or response is required, and too much conscious thought slows down the user, creating slow and costly context switches.

An example of where things break down is with dialogs that pop up and require a response. From a design point they're the equivalent of a road user driving along happily in an unconscious mode, thinking about what they're going to do at their destination, when a deer runs in front of the car. Immediately, conscious thought is required to create a response, and as the driver creates the correct response, their locus of attention is changed from their day dreaming to the more pressing situation at hand. When you delete a file in Windows Explorer it puts it in the recycle bin asking if you to confirm you're sure. From here you can retrieve it later if you want to. If you don't want to fill up the recycle bin you can press Shift+Delete together to do a "delete and don't recycle". This too asks if you're sure with a "Yes/No" response, however the problem is that because pressing Yes to the modal dialog that follows delete has become an automatic part of deletion you don't read the dialog, and don't read and process the Shift+Delete different, potentially more severe with no recovery, question. The problem is that conscious actions, through repetition, can become unconscious, so each time a user sees the dialog they will become more accustomed to just pressing OK to dismiss it, so that dealing with the "Are you sure you want to delete?" just becomes an automatic part of the delete action. For an application that uses dialogs to grab the user's attention, which they have learned as part of the normal operation, what then must it do to really get the user woken up ? One such way is to actually stop the user from proceeding, a technique used by wizards, for example, that disables the Finish button until enough information has been completed. Again, though, the desire to spend as little time being interrupted leads the user to learn all that is required is the minimum set of input to make the Finish button enabled and get the dialog to dismiss itself. Despite this, I find that it's a rare GUI designer who will avoid the knee-jerk decision to use a modal dialog to report a situation that, while exceptional to the application, is just a distraction and annoyance to the user, and for modal screens to be used for dialogs such as property pages, creation wizards, and so forth.

The second problem with mapping brain function to GUIs is that the mind is not a pre-emptive parallel multi-tasking machine, but it is basically capable of serial thought. Switching between one thought and another requires moving the locus of conscious attention, rather like moving an imaginary cursor inside the mind to a new position. This takes time to do and, for the task being left behind, this will either fade from short-term memory in a few seconds, or else must be moved to unconscious thought by repetition or reinforcement.

GUIs that work well are those that embrace the way the mind works, and only invoke conscious thought for the experienced user as and when required. The problem that GUIs often encounter is that they're sold on the basis of how they look, the sparkle and up-front razz, and how quickly they can simplify tasks they're engineered specifically to demo well. However, the true test comes when a skilled user can operate them with unconscious efficiency to mirror the speed at which touch typists can capture information into a console-based text app. I've worked on several failed applications for financial institutions where we wrote superb GUI applications that the users just rejected out of hand because there were too many screens presented in a manner that, while familiar to IDE users' unconscious brains, were just over complex to end users who reverted to spreadsheets to capture all their data and create outputs. To get the edge over basic tools it needs to replace, GUI design must engage the user's brain on their terms, not that of the designer or the framework and language on which it runs.