Simplicity in Your Mind
Published: May 7, 2008
There is increasing interest in the simplification of information technology (IT). The IT industry is recognizing the need to simplify software technology as businesses express their increased interest in governing the return on their IT investments. Two goals are surfacing as explicit mandates to which all software vendors are responding:
- lowering the skills required of software users
- increasing their productivity
Although this simplification mandate is most essential to small- and medium-sized businesses, where people with high-end technical skills may not be affordable, an awareness of the damage complexity inflicts on users is spreading to the enterprise market as well. Commoditization pressures make it necessary for the IT industry to reduce skills requirements as well as service and maintenance costs.
This article postulates that we cannot address the issue of simplification exclusively by analyzing the physical and computational parameters of technology. Instead, we must understand the goal of simplification in light of the knowledge, tasks, and processing-load demands on its users. We can approach simplicity as an engineering endeavor by controlling the impact on these three usage dimensions.
Software’s Complexity Complex
Software, like any other technology, has an intrinsic tendency to become more and more complex. In response to market forces, software developers struggle to differentiate products from those of their competitors by making them more and more functionally sophisticated. This has become a major problem for software vendors.
What are the dimensions of simplicity in software technology? Can those attributes be engineered? What do we mean by simplifying technology? What is simplicity?
Technology, unlike science, must be understood in light of its usage elements. To understand technology, we need to understand the individuals who use it. We cannot define complexity in technology solely in terms of objective physical parameters. If we accept the assumption that technology intrinsically involves human endeavor, we must accept the ergonomic, social, and mental agents that both build it and consume it. We must accept that its makers construct the complexity in technology.
The impact on technology of the physical and biomechanical properties of our bodies is well understood. The physical characteristics and limitations of our bodies constrain the optimization of users’ sitting postures and hand/arm alignment while physically interacting with hardware devices. For the most part, however, when it comes to information technology, complexity is in the mind.
Since the advent of constructivism in Cognitive Psychology, we have come to recognize the role of the mind in constructing reality.  The mind constructs reality for human beings, literally. This is not simply a matter of interpreting what we perceive—its significance or its meaning. The very perceptual systems through which we see, hear, and feel do more than mirror reality. Perception builds reality from external as well as internal elements. A constructivist view does not imply disassociation between the external world and the way we perceive it. Evolutionary psychology has eloquently made the case that our brains have evolved to meet the challenges of our physical and social surroundings.  The human mind constructs our world, but it doesn’t do it arbitrarily. Its building tools and methods have evolved to keep us alive and adapted to an environment that is subject to physical laws and social covenants. Nonetheless, our minds use the internal elements that are at their disposal. They build current outputs upon previous ones. Human minds project the past into the present, which they then recycle, abstract, categorize, and put to use at every opportunity. We call this knowledge.
The most important factor determining simplicity in software technology is users’ knowledge—at multiple levels:
- common knowledge of the world users have inherited or absorbed in childhood
- conceptual knowledge users have learned through schooling
- semantic networks and categorization schemes users have acquired through secondary and higher education
- facts, generalizations, and abstractions users have accumulated in their professional lives and through specialized training
Software pioneers in the early 1980s used world knowledge their contemporaries commonly shared as their metaphors for the first software user interface designs. The technological transformations personal computers brought to us took place under the impetus of a major leap in simplification: People’s interactions with personal computers became predictable by inference from their well-known behaviors with everyday, common objects such as folders, windows, drawers, pens, boxes, buttons, and so on. By relying on the physical gestures people make when interacting with three-dimensional physical objects such as notebook tabs, calendars, and menus, the tasks of locating, browsing, and changing the properties of complex virtual elements became simpler.
Technological complexity is relative. Although we can describe and measure the complexity of certain chaotic, adaptive systems independently of the observer, we can understand the complexity of any technology only in relation to the user—in the case of information technology, in relation to a user’s information-processing ability.
What a user either knows or ignores is the raw material from which we can engineer technological simplicity or complexity. This becomes even more obvious beyond the realm of the common, knowledge-based metaphors graphic user interfaces exploit. Higher knowledge requirements in specialized domains result in more complex software. For example, what a marketing analyst must know about the productivity applications he routinely uses involves less sophistication than the business-oriented knowledge he has acquired on the job—such as knowledge about procedural and scripting languages, architecture, and the programming models and tools with which he crafts business applications. This knowledge, in turn, is less advanced than the knowledge an object-oriented software developer has accumulated after earning a Masters in Computer Science and polished by working on advanced projects in the research and development division of a multinational software company.
If complexity is in the mind, does that mean it is beyond the realm of software engineering?
A relativistic view of complexity does not mean that we cannot address simplicity objectively, and ultimately, engineer it as part of software design and development. It just means we need to take into account a user's knowledge system.
Cognitive psychology draws a distinction between declarative and procedural knowledge, as follows: 
- declarative knowledge—knowing that—Stores facts, or declarations that we know to be true knowledge; knowledge of semantic structures that we relate and enrich with facts and instances, and categorize, abstract, and enrich through learning and experience.
- procedural knowledge—knowing how—Takes knowledge beyond the realm of the higher mental processes by involving the organism as a whole.
For example, athletes train by making a particular movement over and over, in the hope of instilling muscle memory that will automatically optimize a movement or position without thought—that is, without bringing attention to the task. We can safely leverage this procedural aspect of knowledge. Business users of productivity applications who are skilled at using word processing or email applications can accomplish goal-oriented tasks without necessarily comprehending what it is they are doing. As technology becomes more sophisticated, skills require a more disciplined combination of declarative understanding —in the form of computing architecture, data structures, algorithms, and so on—with arduous practical training. Computer analysts, software developers and architects, and network administrators and designers have learned the conceptual underpinnings of those technologies, but they must also acquire the specific procedures that let them put the technology to work to solve a particular business, application, or system problem. Computer scientists spend many hours solving problems in the classroom or the lab to achieve a level of skill that is similar to that which a gymnast attains after long hours of practice at the rings or parallel bars or a surgical resident gains at a teaching hospital.
The level of knowledge and skills an IT professional must possess has increased dramatically over the last 20 years. The skills today’s professional computer programmers with five years of experience have accumulated are an aggregation of knowledge about operating systems, computer-science architecture, computer-language syntax, data structures, algorithms, tools, and best practices. It also demands skills managing the life cycle of the code produced, its compilation, change, integration, and performance optimization. Moreover, given the incomparable dynamism of information technology, those skills need continuous updates through life-long learning. New APIs (Application Programming Interfaces), languages, architectures, frameworks, tools, and coding practices appear in rapid succession. New technologies supersede existing ones without completely replacing them, resulting in legacy layers of coexisting technologies that interrelate in intricate patterns very few fully understand. The resulting technology is complex because of the knowledge and skill using it requires.
Technology is simple only to the extent that we can efficiently develop and manage the skills to operate it. Are 21st-century automobiles complex? Not to drivers, who need to know only a limited set of skills to operate most of their functions—at least the critical ones that let them get from one point to another. Today’s automotive technology is reliable enough to become transparent to users. How about for the mechanic? Fixing an air conditioning unit or a carburetor failure often requires just a simple turn of a screw. Behind such a seemingly simple maneuver often lies a body of knowledge that guides the skilled professional to the right screw to turn.
We are astonished at the ease with which athletes, artists, surgeons, or craftsmen can accomplish tasks that would be insurmountably complex to the inexperienced. Skills forge simplicity. We can automate cognitive and sensomotor routines as a result of practice. [6, 7] The trained eye can transform complex stimuli into meaningful, easily recognizable patterns whose meaning and significance an experienced person can not only quickly assign, but also include call-to-action routines. Like chess patterns to a master player, x-rays to a diagnostician, or java code to a professional software developer, knowledge informs its possessor what to do next.
Despite its fundamental role, knowledge is not everything. Technology imposes task constraints even on the most skilled user. Complexity is impacted by the number of tasks accomplishing a goal requires, as well as the hierarchical, semantic, and structural relationships among those tasks.
The sheer number of steps a user must perform is the most conspicuous aspect variable in the task dimension. For example, the number of distinct steps a user must follow to migrate an existing document or presentation to the latest version of a productivity application affects the perceived complexity of that application. The ultimate simple solution is to not require any action on the part of a user: Backward compatibility does its job by ensuring that a new piece of software will work with artifacts users created using previous versions. Even a one-button migration increases complexity relative to a totally transparent approach that requires no user action. Could this single button click make a difference? Yes. The consumer needs to be aware that this single action is required. Here is where the need for knowledge surfaces again. The difficulty is not in the need to click that single button—the task itself—but in the fact that users might not know that such a button exists and that they need to click it.
One of the most common and unfortunate assumptions software developers make is that users know what they need to know. They project themselves into the user population. In reality, requiring even trivial pieces of knowledge of users can be very costly to knowledge workers, who may already be overwhelmed by coping with the large amounts of knowledge their core domains demand. The myriad of peripheral, single actions different vendors’ tools require of them in their daily chores can add up. Furthermore, those simple actions are often buried on Web sites, so to reach a simple action, users may need to overcome obstacles that increase their chance of failure or, at least, add complication.
As the number of steps required to accomplish a goal increases, so does the complexity of the task. For example, the number of steps IT administrators must perform to install and configure middleware technology can be very large. First, they need move the files among various media, perhaps involving a number of CD-ROMs, downloads, or archive utilities. During installation, they may face storage, software, or hardware incompatibility problems, which may necessitate their branching into additional installation subtasks. Failures may also result in problem determination tasks that require additional tools or information such as logs or support sources.. Beyond installation, administrators must tune parameters across multiple components. Once setup is complete, administrators must test the system in a staging environment to ensure compatibility with existing technology. Then, finally, they deploy and run the software in a production environment. IT administrators must carry out such tasks in business-critical environments where failure is not an option. The required tasks involve adherence to processes that an IT organization has put in place to preserve its system’s integrity.
Beyond installation and configuration, IT personnel perform routine management and operational tasks that require careful sequences of steps to diagnose, administer, monitor, and update software systems. The tasks involved are many and are constantly changing. The fragility of the technology requires that highly trained personnel perform these tasks. Such tasks require a solid body of knowledge on the part of the consumer.
The interaction of tasks and knowledge becomes even more apparent in software development. Software engineers develop code. The body of knowledge they bring to software development includes the constraints of code practices, programming interfaces, tools, and development processes. Tools and programming interfaces demand a certain number of tasks. Function calls follow a prescribed sequence. Editors, debuggers, and ancillary utilities force software engineers to follow a series of steps to create, import, compile, build, unit test, and debug code.
Besides the total number of steps performing a task requires, the relationships among those steps affect the complexity of the task. Tasks with a fixed step sequence—or without a prescribed sequence—are more demanding than tasks in which the next step depends on the outcome of the previous one. As the number of paths in a decision tree increases, so does the complexity of an interaction.
In addition to knowledge and task demands, there is a third dimension that determines the complexity of technology: the processing load it places on users. Processing load is the information-processing workload a tool imposes on a user’s perceptual and cognitive channels.  Good user interface design is optimized for the user’s perceptual system by taking into consideration color and text perception. Cluttered user interfaces overwhelm users and reduce their ability to focus on the important elements in the visual field. Overuse of animation can overpower a visual system that humans evolved to respond to the intrinsically alerting nature of movement in the visual field. On the other hand, sensible use of color, screen real state, layout, and fonts optimizes a user interface for the human perceptual system.
Notwithstanding the unquestionable role that perception plays in software consumption, most of its processing demands fall on the user’s cognitive channel. Knowledge workers spend most of their daily lives scanning for keywords; reading; recognizing patterns; retrieving knowledge and episodes, or past actions, from memory; making inferences about the meaning of options and actions; generalizing, recognizing, and discriminating options; and comparing decision paths. IT professionals engage in cognitive processing that expands into the realms of pattern recognition, diagnosis, and deductions from antecedents. They apply deductive rules and build mental models from which to predict future behavior. In solving problems, they engage in heuristics that place heavy demands on controlled processing.
Those without advanced expertise and knowledge engage in difference-reduction heuristics, which seek to reduce the difference between the current state of a problem and the desired goal.  For this purpose, novices establish series of subgoals representing states that are closer to the final solution. They focus on operators—such as program variables, configuration attributes, deployment properties, and function parameters—that they deem are relevant in means-ends analysis. Without advanced knowledge, they must maintain all possible states of the problem at hand in an active state, storing all those operators and keeping them active in working memory.
On the contrary, problem solvers who are expert in a given knowledge domain learn over time to recognize common configurations in the problem domain as single perceptual units.  Skilled IT professionals—like skilled chess players or physicists—work forward rather than backward. Instead of intentionally searching the problem space, they recognize common configurations as single perceptual units that trigger applicable knowledge that is relevant to solve their problems.
In summary, the following attributes determine the simplicity of the software technology we consume:
- how much knowledge the technology assumes
- how well the required user interactions suit the strengths and limitations of our perceptual systems
- the cognitive processing demands it places on our limited mental resources
- the length and intricacy of the tasks we perform using the technology
In other words, the complexity of technology is a function of what it demands its users to do, know, and process, as shown in Figure 1. These dimensions are not independent. Knowledge, the gift that keeps on giving, provides context to our perceptions and, in advanced stages, harvests expert skill over time. Expertise, in turn, eases processing demands through the development of recognizable patterns that reduce demands on costly conscious mental processing.
Figure 1—Complexity’s inertia
Since knowledge requirements are fundamental in increasing the complexity of software, should instruction and learning be the primary means of simplification? After all, if increased knowledge demands also increase complexity, diffusing knowledge should be an effective answer. Assisting technology consumers with appropriate instructional materials is an important element in simplification. Software products can and should afford some level of user assistance in the form of courses, tutorials, and other materials. However, much of today’s software technology requires users to build knowledge pyramids on foundations that take years of dedicated and formal training to develop. The educational costs are prohibitive. Advanced knowledge comprises more than problem-specific instruction. It requires aggregations of principles, concepts, relationships, procedures, and practice that only elaborate and expensive curricula can offer. As it turns out, the most important factor in learning is what the learner already knows. Knowledge builds knowledge.
An engineering approach to simplicity counters the inertial forces that drive functional sophistication toward increasing levels of complexity. As user experience engineers, we are equipped to understand and control the effects of software attributes on the three usage dimensions of complexity: knowledge, tasks, and processing load.
 Anderson, John R., Lynne Reder, and Herbert A. Simon “Situative versus cognitive perspectives: Form versus substance.” Educational Researcher, 26, 1997.
 Shaw, Robert, and John Bransford. Perceiving, Acting and Knowing: Toward an Ecological Psychology. Hillsdale, NJ: Erlbaum, 1977.
 Tooby, John, and Leda Cosmides. “On the universality of human nature and the uniqueness of the individual: The role of genetics and adaptation.” Journal of Personality, 58, 1990.
 Ludwig, Jessica. “Stanford Web Site Documents the History of the Macintosh Computer.” Chronicle of Higher Education.
 Anderson, John. Rules of the Mind. Hillsdale, NJ: Erlbaum, 1993.
 Chase, William, and Herbert A. Simon. “Perception in chess.” Cognitive Psychology, 4, 1973.
 Larkin, Jill, John McDermott, Dorothea Simon, and Herbert A. Simon. “Expert and novice performance in solving physics problems.” Science. June 20, 1980.
 McCracken, Jack H., and Theodore B. Aldrich. Analysis of Selected LHX Mission Functions for Operator Workload and System Automation Goals. Technical Note ASI 479-024-84 (b). Fort Rucker: Anacapa Sciences Inc., June, 1984.
 Newell, Allen, and Herbert A. Simon. Human Problem Solving. Englewood Cliffs, NJ: Prentice-Hall, 1972.
 de Groot, Adriaan D., and Ferdinand Gobet. Perception and Memory in Chess: Heuristics of the Professional Eye. Assen: Van Gorcum, 1996.