Context, Cognition, and the Dynamics of Design Thinking: Cognitive Methods for Understanding the Situational Variables Affecting Usable Design

doi: https://doi.org/10.55177/tc796562

By Kirk St.Amant

ABSTRACT

Purpose: Design thinking is a process for identifying solutions to problems in certain contexts. The better one understands contextual factors affecting use and interaction, the more effectively one can use design thinking to address issues at the context and greater systems levels. This article examines how the cognitive science concepts of scripts and prototypes can help realize the potential of design thinking in different settings.

Method: This article compares design thinking approaches for understanding context to concepts of context as examined in the cognitive mechanisms of prototypes and scripts. Through this comparison, the author explains how to integrate scripts and prototypes into design thinking processes in order to enhance understandings of context and the success of design thinking approaches to context-related problems.

Results: The article reveals that prototypes and scripts can expand design thinking approaches and enhance the development of design solutions for addressing problems at local and greater systems levels.

Conclusions: Technical communicators can use the approach presented here to enhance design thinking processes in order to better address problems in or design products for specific contexts.

KEYWORDS: applied theory, cognition, context, design thinking, usability

Practitioner’s Takeaway

An understanding of the psychological processes behind usability in different settings can help technical communicators better research user expectations associated with different settings.
A mechanism that helps technical communicators focus research on cognitive expectations of usability in a context can help them better identify such factors.
An approach for integrating cognitive theory into design thinking processes can help technical communicators better apply design thinking to address problems in and create products for different environments.

CONTEXT AND DESIGN

Context often affects usability, for the setting where individuals perform activities can influence the use of items. Technical communicators can apply an understanding such context dynamics to create more usable designs. Doing so involves observing situations to identify where problems or needs occur and then developing prospective solutions. Such situations have led observation-based approaches like design thinking to become an increasingly prevalent method for problem solving and product development in different situations.

Essentially, design thinking combines observation with the rapid creation and testing of solutions to develop new technologies and processes (Brown, 2008; Kleiner, 2009; Owen, 2006). The better technical communicators can observe settings and identify problems or needs, the more effectively they can design usable products and effective approaches. The cognitive concepts of scripts and prototypes can assist technical communicators with such activities. This article examines what these cognitive mechanisms are and how to integrate them into design thinking when developing processes or products.

COGNITION, PROCESSING, AND ORGANIZING

The human brain is often likened to a computer. This comparison references the brain’s continual organizing and processing of input to achieve a particular—ideally, desired—output (Your Brain, 2017; Sweller, 1988; Schmidt, 1975). The problem for brains and computer alike involves the information they can address at one time (Sweller, 1988; Paas, Renkl, & Sweller, 2004). For humans, the challenge requires balancing input from the senses against the information the brain can process.

Some estimates set the information the senses channel to the brain at millions of bits per second (Wu et al., 2016). Yet neurobiological factors limit the new information the brain can process at any moment (Marois & Ivanoff, 2005; Kirschner, 2002; van Merrienboer & Sweller, 2005). This situation often involves split attention—or how humans balance what to pay attention to and process in a context (Cave, Bush, & Taylor, 2010). Researchers often label this processing limit cognitive load (Sweller, 1988; Paas, Renkl, & Sweller, 2004). From a computing perspective, the situation resembles information overload where data is coming in faster than the system can address it. From a cognition perspective, individuals often refer to this situation as cognitive overload (Wu et al., 2016; Paas, Renkl, & Sweller, 2004). In both cases, this overload often results in a system shutdown.

These instances raise the question: How can individuals interact on a daily basis? The answer is human brains have developed cognitive mechanisms that focus the brain’s attention and its processing power on a fraction of the information the senses take in (Kirschner, 2002; van Merrienboer & Sweller, 2005; Sweller, 1988). This approach affects what individuals pay attention to and how they aggregate sensory data for easier cognitive processing (Sweller, 1988; Paas, Renkl, & Sweller, 2004; Postle, 2016). Such activities often involve a cognitive construct called schemas.

SCHEMAS AND PROCESSING

A schema is a mental model for organizing information into blocks based upon common relationships (Pass, Renkl, & Sweller, 2003; Cook, 2006; van Merrienboer & Sweller, 2010). Specifically, a schema combines the aspects individuals associate with an item into a single interconnected unit for mental processing (Sweller, 1988; Tse et al., 2007; Yamada & Itsukushima, 2013). If, for example, one hears or reads the word “pen,” a variety of things often come to mind including:

activities associated with using a pen (e.g., writing, taking notes, taking a test, etc.);
kinds of pens (e.g., fountain, ball-point, erasable, etc.);
contexts where one uses a pen (e.g., office, classroom, bank, etc.); and
objects with which one uses a pen (e.g., paper, note pads, post-it notes, etc.).

The mind simultaneously accesses these items because the brain has organized them into one unit for mental processing—a schema associated with “pen.” When individuals encounter the word “pen,” their brain accesses the related schema of these associated factors because they exist as a single interconnected unit (Pass, Renkl, & Sweller, 2003; Cook, 2006; van Merrienboer & Sweller, 2010).

By packaging information into such conglomerate units, schemas reduce the data the brain needs to process and help manage cognitive load (Sweller, 1988; Tse et al., 2007; Yamada & Itsukushima, 2013).

These schematic relationships also affect how individuals perceive information. Imagine someone asks you to get a pen from a location. Your mind will likely be primed to enter that space searching for items you associate with your schema for pen. These items could include a writing-related task to perform, materials to write on, and places where one writes. In this way, schemas focus attention and reduce the information the brain needs to consider (Sweller, 1988; Postle, 2016; Yamada & Itsukushima, 2013).

These schemas are not innate. Rather, individuals learn them through exposure over time (Sweller, 1988; Tse et al., 2007; Yamada & Itsukushima, 2013). The more one sees a pen used for writing, the stronger that relationship becomes in one’s schema for pen. Similarly, the more one sees pens used with paper, the more one associates the two in a schematic relationship. As a result, the idea of “paper” can access both “pen” and its related schema as easily as the word “pen” can access the schema associated with paper and so on. This dynamic means the schema individuals use can evolve to address new items they encounter in an environment (Tse et al., 2007; Yamada & Itsukushima, 2013).

These connections between context, perception, and expectation mean schemas help with understanding problems in a particular context—such as when a schema does not match the setting where it is used. Similarly, schemas can help identify context-related needs. Consider a situation where an individual’s schema for “writing” in a space contains “paper.” If there is no paper in a location, then that situation becomes a need to identify and address to help that person perform writing tasks in that setting. In these ways, schemas can help individuals observe contexts to identify issues and design solutions for addressing them. These factors also mean schemas can play an important role in design thinking where observation is central to identifying problems and needs.

DESIGN THINKING

At its core, design thinking involves observing how persons perform a task in a location. The objective is to identify problems or find areas for improvements (Brown, 2008; Kleiner, 2009; Owen, 2006; Buchanan, 1992). Such observation helps in discovering new items or advantages no one realized were needed or beneficial.

After identifying a want or need, the next step in the design thinking is rapid prototyping where individuals create an initial design (i.e., a prototype) of a technology or approach to address the related problem or need (Brown, 2008; Kleiner, 2009; Owen, 2006). Members of the target audience (those who were observed) then try to use the prototype solution in the related location.

This initial prototype likely won’t perfectly match the related need or problem. Rather, the initial design facilitates a second round of observation to assess how the target audience uses that initial item or approach in the associated setting. This second round of observations allows product/solution designers to quickly modify designs or approaches to better address audience expectations and perceptions (Brown, 2008; Kleiner, 2009; Owen, 2006). Members of the target audience then try to use the revised design/approach, and product/solution designers again observe such activities to determine if additional modifications are required. If needed, such modifications are made, and the newly revised design or approach is tested again. This iterative process of observe-(re)design-test eventually leads to a final design that addresses the related problem or need (Brown, 2008; Kleiner, 2009; Owen, 2006; Buchanan, 1992).

This overall process involves three core phases:

Inspiration: The initial phase when observation identifies problems in a system or prospective needs associated with a context.
Ideation: The second phase where rapid prototyping helps devise prospective solutions and iterative, observation-based testing and revision identifies an effective solution.
Implementation: The final phase where individuals chart a path for integrating the identified solution across the greater system where individuals will use it (Brown, 2008).

This process combines the study of users with design to address the contexts where activities occur and the overall system in which such contexts exist.

Designers and content creators can apply this approach with individuals from different backgrounds to address different contextual needs and problems (Kleiner, 2009; Buchanan, 1992). Additionally, the speed with which individuals can test and design prototypes allows for relatively quick product or process development that reflect the context-based experiences of audiences (Brown, 2008; Owen, 2006; Buchanan, 1992). For these reasons, design thinking has become an increasingly important method for examining everything from business practices to engineering research to educational approaches (see, for example, Newman et al., 2015; Mentzer, 2014; Dym et al., 2005). Such applications have prompted technical communicators to also examine design thinking in their own product design, teaching approaches, and curriculum development practices (see Shalamova, 2016; Wickman, 2014; Purdy, 2014). Accordingly, aspects that can enhance design thinking approaches have much to offer different industries and fields. An application of schemas can help with such processes.

Design thinking’s observation-based, iterative approach reflects two central factors of cognition:

knowing what to observe in order to understand the behavior in a location and identify related problems or needs
focusing observation on how individuals use prototype solutions in a setting

Such focused observation can help in revising designs so audiences can easily recognize and use a new item or approach in a setting. These processes involve two particular schemas: scripts and prototypes.

SCRIPTS AND PROTOTYPES

Many daily activities require individuals to navigate several variables. Most involve identifying items and individuals in a location and engaging with these items and individuals in a recognized way to achieve a particular objective in that context. The ease with which humans perform such processes often involves the schemas of scripts and prototypes.

Scripts, Contexts, and Behavior

Certain schemas contain associations for the actions individuals repeatedly perform in a location. When you enter a restaurant, for example, you generally know what events will take place there and the sequence in which they will occur. (You will be seated, place an order, receive food, pay, and depart.) You also know who will play a central role in such events. (You will interact with a greeter who seats you and waitstaff who take your order.) Additionally, you can anticipate what items will be in that space to facilitate such activities. (You know you will encounter menus for selecting food, pen and paper waitstaff will use to take your order, utensils you will use when eating, etc.) These (inter)associated factors for this location represent a single schema known as a script.

Like most schema, scripts combine certain elements into a single cognitive unit to help individuals quickly and easily process large amounts of information (Tomkins, 1978 & 1987; Norman, 2002; St.Amant, 2017). As such, scripts prevent cognitive overload whenever individuals move through various contexts in their daily lives. In so doing, scripts help individuals identify factors essential to achieving an objective in a location. If those factors are present, individuals can easily perform the complex actions associated with achieving that objective (e.g., eating at a restaurant). If factors are missing, however, individuals can become confused and disoriented as they grapple with what information to process and how—a situation that increases cognitive load.

Central script elements include:

Sequence: The order in which the actions/events in a space occur in relation to accomplishing the objective one wishes to achieve in that context.
Roles: The individuals one expects to encounter and play a role in achieving that person’s objective for being in that context.
Props: The items one expects to encounter and use and expects others (i.e., the other roles) to have and use to complete activities in a context.
Entry Conditions: The ways individuals, materials, and information enter a location including how persons, materials, and information not present can enter/be brought into that setting if needed.
Exit Conditions: The ways individuals, materials, and information leave or can be sent from that context including how to send items or information out of that location if needed. (Tomkins, 1978 & 1987; Schank & Abelson, 1977)

These script-related factors become the variables individuals expect to encounter and interact with in a context. They are also foundational to the schemas individuals use to guide their actions in a location and shape their expectations of what they will encounter and can do in that setting. In these ways, script-related factors determine the sensory information individuals focus on in a location.

If these expected variables are present, individuals can readily perform complex actions in that setting as their associated script guides what to focus on and use and whom to interact with in that context. If, however, one or more of these variables is missing, individuals often become unsure of how to act or what to do. In such cases, persons generally search their surroundings for the missing item in order to continue the process per the related script. Individuals might also seek guidance or explanation from others there to determine what to do based on the absence of a script-related variable.

If, for example, individuals enter a room but don’t know where they are or what they are expected to do in a location, they often:

wait until they find a marker (e.g., a sign) identifying the location and then initiate the related script; or
locate someone who can identify that space (e.g., “It’s a restaurant.”) in order to access the desired script.

Even then, without certain props/variables that indicate how to proceed in that context, breakdowns can occur. (What do individuals do if they cannot find a sign or person to clarify if one should “wait to be seated” or to “seat yourself” upon entering a restaurant?) In such situations, individuals might do nothing and wait for someone to explain how to proceed. Alternatively, individuals might watch other persons to determine what those individuals do in that location and then mimic that behavior while hoping such actions are correct. These expectations of the script variables individuals expect to encounter involve another schema: prototypes.

Prototypes, Identification, and Action

Accessing the desired schema for a process often involves identifying the items in that schema in order to access the desired process for something. The process generally works as follows: If I tell you to “Find a cup” in a space, your mind will access a mental model—perhaps an image—for “cup,” and you will survey your surroundings to identify objects that resemble that model. The more closely something in that location mirrors your mental representation for “cup,” the more readily you can identify the item you are seeking and achieve your purpose for being in that location (St.Amant, 2017).

Upon finding the cup, you generally know how to use it. If I ask, “Please go into a location and use the cup you find there to get coffee for a guest,” I don’t need to explain how cups are used for holding fluids. Similarly, I don’t need to provide instruction on how to pour liquids into a cup or carry the cup by the handle if the contents are hot. Rather, I assume that once you’ve identified a cup (i.e., recognition) you understand what it is used for and how to use it (i.e., attribution). This ability to readily identify and use items in a context involves a particular schema—a prototype—that connects the identification of an item to its associated use(s).

Like other schemas, prototypes combine complex pieces of information into a single cognitive unit for processing. Specifically, prototypes combine the features or characteristics of an item into a model of what the overall item should resemble (Rosch, 1978; Aitchison, 1994; St.Amant, 2005). As such, prototypes:

help individuals identify objects by noting, “If an object has these characteristics, then it resembles and should be identified as X.” Per a classic example from Aitchison (1994), if an item has feathers, wings, and a beak, most individuals recognize it as a bird.; and
tell individuals what objects to search for in a context by focusing attention on items that have the characteristics they associate with a particular object. Per Aitchison’s (1994) example, if I say, “Go into that room and find the bird,” you will likely enter that space and search for an object with feathers, wings, and a beak—the characteristics of a prototypical bird.

Additionally, prototypes combine certain attributional aspects into the expectations individuals associate with an object. The reason you know cups are used to hold fluids is because that characteristic (vessel used to hold liquids) is part of the overall prototype you have for cup (Aitchison, 1994; St.Amant, 2005). Similarly, the factors associated with a cup’s uses such as cups usually have handles that help individuals avoid burning their hands if contents are hot are also part of this prototype for “cup.”

The prototype individuals have for an item also contains information on the appropriateness of an item (Aitchison, 1994; St.Amant, 2005). A square vessel, for example, could be a kind of cup one might recognize. It is not, however, a typical cup and would probably be considered an oddity in most situations where one expects to encounter cups. In such cases, individuals might recognize what the object is and what it does, but it would likely be seen as a different, unexpected, and even inappropriate version of the item to use in certain contexts (e.g., formal business events).

In most situations, scripts and prototypes are entwined so individuals can perform regular activities reflexively (St.Amant, 2017). In these situations, scripts identify what individuals will do, who they will encounter, and what they will encounter. They also identify how items can enter or exit a context. Prototypes, in turn, help individuals identify and use expected items or identify and interact with expected persons in that setting according to the related script. Similarly, prototypes help individuals identify mechanisms for bringing items into or sending items out of that context per the related script. An individual’s prototype for cell phone, for example, tells them what to locate if they wish to call out to access information when in certain places. Similarly, that prototype tells individuals what mechanisms others can use to call in to a setting in order to provide needed information.

For individuals engaged in design thinking, scripts and prototypes can facilitate the observation of different contexts. They can also help with the creation of initial products or processes to address problems or meet needs in a setting. These benefits involve:

identifying key elements associated with activities in a setting; and
creating materials audiences can easily identify and use in a context

This integration of scripts and prototypes into design thinking can occur in four ways: mapping, aligning, designing, and systematizing.

INTEGRATING COGNITIVE FACTORS INTO DESIGN THINKING APPROACHES

Connecting cognitive concepts to design thinking involves integrating prototypes and scripts into the observation and understanding processes to:

first, determine the parts of the process being observed.
next, identify the variables affecting activities in each part.

I call this process script mapping (St.Amant, 2017).

Mapping

Scripts organize an activity into a sequence of events (i.e., steps) with certain actions preceding others. Each step contains variables for performing the activities expected in that step. These variables include the individuals who perform certain tasks at each step (roles) and the materials they expect to use (props) for these tasks. These expectations include the means and methods for:

obtaining or bringing needed items or information into that context (entry conditions); and
transmitting/sending needed items or information from that context (exit conditions).

Script mapping involves first identifying the major actions or steps in the overall script for that context and then identifying the variables expected for each step.

Integrating script mapping into design thinking begins with identifying the steps in the overall sequence/process of a script. This situation might resemble Table 1.

During the initial observations phase of design thinking, one would note (and document) the steps in the process being observed.

The next aspect becomes identifying the script-related variables observed at each step. This round of mapping might resemble Table 2.

To use the restaurant example, this mapping might resemble Table 3.

Creating script maps of observed processes can enhance design thinking by identifying where problems might occur or where to address a need.

Per the restaurant example, script-based observations might identify if part of the overall process seems to be missing. One might notice no formal step exists for providing food to the customer; this situation could result in customers experiencing different levels of quality when receiving their food. In other cases, mapping could identify unnoticed needs. For example, the mapping of “ordering at a restaurant” could reveal printed “Menus” provided by a “Greeter” are the only way customers can access information on meal options. This observation could identify an unnoticed need (e.g., the need for other ways to check menu options). It could also identify a space for introducing a new approach when addressing this need. In the menu example, the design solution might involve creating an app that allows customers to check the menu via mobile phone at any time. This step could save time and increase customer satisfaction by reducing dependence on waitstaff to provide customers with printed menus.

Aligning

To interact in a context, individuals often need a common understanding of:

what all parties are expected to do in a setting; and
what items individuals are expected to use to perform these tasks in that setting.

Disconnects involving such factors can create confusion and cause problems. They can also reveal needs for new materials such as items that clarify the roles of individuals.

The issue involves alignment. Essentially, one needs to confirm the scripts of all parties interacting in a location are common, or aligned, per the expected script variables. One must also confirm the use of common characteristics for identifying variables within a script. Design thinking can make meaningful contributions in these situations. These situations also represent instances where unseen problems can occur, or unanticipated needs might arise—areas where script mapping can provide important design insights.

Such processes help determine if all parties use a common script to guide behaviors and interact with others in a setting. The context-based script map researchers create can help examine such factors. The goal is to a) create a map of the script each party has for interacting in a location and then b) compare these maps to determine if discrepancies in script expectations exist. Such a comparison could reveal disconnects in what the persons think they—or others—should do in a context. For example, a comparison of script maps for ordering at a restaurant might reveal the restaurant’s owners expect customers to ask a greeter about seating preferences upon entering. Yet the maps of customers might indicate they do not realize they need to do so unless prompted by a sign stating, “Please wait to be seated.” The resulting problem is some customers seat themselves upon entry—which affects how greeters and waitstaff identify available tables and determine which waitstaff serve particular patrons. The script mapping and comparison process here identifies a new design need: A sign stating seating policy.

Aligning the divergent scripts of owner and of customer involves creating a new item (e.g., a sign stating seating policy) to address a need previously unrecognized by one script. This item, the design solution of a sign stating seating policy, could be developed and user tested to:

identify a final design that is recognized (i.e., prototypes); and
determine where to place that design so individuals can locate it (i.e., script).

The result is a product that addresses the user needs and design expectations for that context.

In other cases, the prototypes within a script could cause problems design thinking can resolve. All involved individuals, for example, might have common expectations of the variables they expect to encounter at different steps within a script. However, what a particular variable should resemble might differ from person to person. Such variations could affect how individuals interact in and what they do in a context.

Consider the example of waitstaff in the script for restaurant. The customer, the owner, and the waitstaff at a restaurant might have a common role expectation that a waitperson takes customer orders and attends to customers. Yet these parties might have different ideas of the prototype for “waitperson”—specifically what characteristics identify individuals as “waitstaff” in that script. The owner and the waitstaff might think persons dressed in street clothes and carrying a pad and pen sufficiently identifies “waitstaff” in that context. Customers, however, might expect a certain dress (e.g., white shirts with black pants) to be the characteristics identifying “waitstaff” in that script. As such, customers might be unable to identify waitstaff when needed in this situation. This situation could lead to delayed service and customer dissatisfaction that might affect the related organization (e.g., poor customer reviews).

Addressing this problem involves a design solution that lets all involved readily identify roles related to performing expected activities in that context. Per the restaurant example, this design solution could involve implementing a uniform policy for waitstaff. From a design thinking perspective, it is a situation where one’s observations identify a problem by understanding how prototypes can cause confusion in a context. This situation also involves applying an understanding of prototypes to develop a design solution that address a problem.

Designing

In design thinking practices, after individuals identify a problem or need, they do rapid prototyping—a process of creating a rough design of a proposed solution. Individuals next test this initial design with the related users to collect feedback and identify modifications needed to make the design more usable. Individuals then create and test a revised design, and this process of test, revise, test again, etc. continues until testing results identify an effective design.

For designs to be effective, users need to identify what an item is (recognizability) in order to understand how to use the related design. If, for example, the online menu one creates for a restaurant has features that resemble a conventional menu (e.g., meal option, description, and related price), it might be easier for patrons to recognize that item as a menu and know how to use it at that restaurant. If, however, the design makes that online menu look like something else (e.g., a video game where users compete to access menu options), customers might experience difficulty recognizing what that item is and understanding how to use it.

The ability to use an item often involves how well individuals understand its relationship to the context for which it has been designed (contextualization). Per the menu example: To address an identified need, one might create a digital menu for ordering at a restaurant. If the user does not understand how this digital option fits into the process of ordering a meal (e.g., Does one view it before ordering to check options? After the order arrives to confirm it is correct?) that person will be less likely to use it. This situation results from the user not knowing how this new item connects to the context where this overall process occurs. Prototypes and scripts can help address such situations

One must first consider contextualization—or at what point to integrate a new item into an existing process. Knowing where in the process individuals will use the new object lets one understand how to design that item to fit into that process. A restaurant owner, for example, might know customers will access the restaurant’s digital menu upon receiving their order to confirm the meal is correct. One might design the menu’s interface to display both:

the entry as it appeared on the menu from which customers ordered; and
the order as it was received by the chef.

This design allows customers to confirm that the order they made and the order the chef received aligned. The resulting design contextualizes this new online menu to address the script expectations patrons have at that point in the overall sequence of events, and the resulting design better meets the user’s needs. I call this application of scripts to integrate design solutions into an existing script process script transfer. The idea is to design new items users can readily transfer into or integrate into an existing script they have.

Schema-related prototypes can help with these design processes. As noted, users identify items based on how closely the features of an item match the prototype for an object the users know and recognize (Rosch, 1978; Aitchison, 1994). Upon identifying an item, users also determine what that item does and how to use it. If a new design has enough features in common with recognized prototypes, it is easier for users to identify what that item is (recognizability) and understand what that object does and how to use it (attribution). From a design thinking perspective, the process involves determining the characteristics new items must possess to match the existing prototypes users rely on to identify items and determine their use. Additionally, such prototype matches in design can help users contextualize new items within an existing script based upon what actions one performs at a particular point in a process.

To achieve these design objectives, individuals might begin design thinking’s development and design phase by asking users to note features they associate with certain items. (For creating a digital menu, this process could involve asking questions like, “What characteristics do you use to determine that something is a menu?”) The design of the initial product would then include these features, and one would test this design by asking users:

if they know what the item is
if they know what the item is used for
if they know how to use the item

Each step has users note the characteristics or features they associate with identifying what a new item is (e.g., “If I wanted to revise this item to look more like a menu, what would I need to add? To remove? To modify?”) Such processes help align the design of new items with user expectations and help users identify what an item is, what it does, and how to use it within the related script. Ideally, such testing can lead to the development of a product individuals can readily recognize and use in the related context.

Systematizing

Design thinking encompasses both creating new items for a process and viewing processes as part of a greater system in which individuals use such items. The idea involves developing a new product and considering how to integrate that product into an organization’s marketing strategies and associated logistics of production and transportation (Brown, 2008; Kleiner, 2009; Owen, 2006; Buchanan, 1992). Thus, design thinking integrates systems thinking into the design and development processes, and scripts and prototypes can facilitate such practices.

Transferring new ideas/products from one domain to another involves the script concepts of exit and entry conditions. Essentially, certain factors govern how individuals expect items and materials to exit one context and enter another. When materials move from context—or script—to context, they straddle an area where exit and entry conditions overlap. In a restaurant setting, for example, how an order leaves the dining area (exit conditions) to go to the kitchen for processing represents how meal requests from the dining room enter the context of the kitchen (entry conditions). Here, exit and entry conditions overlap as items or information must move from one context to another within the overall system. This situation involves particular props—the written order for the meal—traversing two contexts.

These factors mean certain items can be transitional items—or mechanisms used to pass information or materials from one context to another in a greater system (i.e., exit one, enter another). If individuals can identify such transitional items, they can better create and test draft designs with two groups:

The users who consider these items connected to exit conditions (i.e., sending items and information out of a context)
The users who associate these items with entry conditions (i.e., items used to bring new, needed information into a context)

Testing the same item/design with both groups helps determine if each group recognizes what that item is and knows how to use it within the greater context of events.

Per the example of ordering a meal, both waitstaff and kitchen staff need to recognize what a slip with a meal order is to use that item to convey information from one context (i.e., dining room) to another (i.e., kitchen) within the overall system of a restaurant. The waitstaff must recognize such a slip as central to exit conditions (i.e., sending the order out of the dining room). Kitchen staff must recognize that slip as central to entry conditions (i.e., sending information into the kitchen). For this reason, both groups need to correctly recognize the same item (i.e., a slip with a meal order) as well as correctly associate that item with a related script (i.e., sending an order to the kitchen or receiving an order from the dining room). So, related testing of the design of that item must include members from both groups with each group confirming the design of that item connects to the correct script within a greater system. (For waitstaff, this connection would be to sending an order to the kitchen; for kitchen staff, it would be receiving an order from the dining room.)

Addressing such design factors involves the schema of prototypes. Each group in such exit-enter transitions must note the characteristics used to identify what the item is to know how to use it. Design thinkers can then apply this prototype-related information to create designs containing characteristics each group needs to identify and use materials. The resulting design can help items and information move easily from context to context within a greater system.

In such cases, script mapping helps identify context factors affecting if and how individuals use a new product. Essentially, mapping helps identify where scripts overlap along the exit/entry condition boundary. Design thinkers can then create materials, track how they move across a system, and determine essential the prototype expectations so all individuals involved in a process can recognize these items during such movements.

Such mapping can also help anticipate where to develop new services or products individuals can use across script contexts. Imagine someone wanted to develop an online menu that allows customers in the script “restaurant dining area” to order a meal. Doing so means providing related service for supporting this new technology—services that require modifying a script for “provide technical support.” The design thinker would therefore need to modify this affiliated script—or script a new product now connects to another context. If, for example, someone added an online menu to the script for “dining at a restaurant,” that person would also need to modify a related script for “provide technical support” (i.e., expanding an existing script for technical support to include providing such support for this new online menu). Doing so might also mean creating materials for this affiliated script (e.g., a manual on how to provide technical support for this new menu).

EXAMPLE APPLICATION IN SOCIETY

Drive-through COVID-19 testing represent an example of integrating script mapping into design thinking to create innovative solutions (St.Amant, 2021). In early COVID-19 situations, many societies needed to do large-scale disease testing effectively, efficiently, and safely. Such practices had to integrate easily into:

the everyday lives of individuals to achieve the scale of testing needed; and
the infrastructure of a society to avoid overwhelming existing medical facilities.

One solution was drive-through testing stations. Essentially, different national health authorities developed a design solution involving a new script. The result was a testing method that integrated effectively into greater society without straining healthcare facilities or requiring radical changes in individuals’ daily lives.

Drive-through testing stations addressed script elements by creating experiences that matched existing expectations individuals associated with certain contexts. The new testing process began with entry conditions—signs indicating where and how to enter a drive-through testing station (e.g., “Enter here for COVID-19 testing”). Individuals then often encountered factors that established roles in this script:

a sign instructing individuals to remain in their cars (i.e., indicator of role of individual) and noting only drivers would receive testing (i.e., identifying role of any passengers)
a PPE-clad healthcare worker (i.e., roles as identified by prototype for who “healthcare workers” are) who did the testing

Generally, these facilities noted the props parties (roles) used for this process. Signs requesting individuals remain in their car throughout the process identified the props drivers (and passengers) would use in this process/script. Clipboards or iPads (recognized prototypes for collecting data) and nasal swabs (recognized prototypes associated with medical process/medical testing) identified the props healthcare workers would use and (via prototype association) the uses of such items. Exit conditions included:

signage indicating how to leave (drive out of) the testing area; and
information healthcare workers provided that noted the person’s samples would be sent to a lab for testing (explaining exit conditions for information taken at site).

Such situations often included an explanation that individuals would later receive their test results via a specified method such as text message, email, or phone call (entry conditions for how information gets into another location and to the individual).

This process created a new script that allowed individuals to move easily into and through a new process in a location. This situation, moreover, was not truly new. Rather, it tapped existing scripts (alignment) for “drive through service” that prompted individuals to search for signs noting where to enter and exit drive-through areas. Such signs initiated a script-related behavior that identified the role of drivers (drive-through patron), so drivers knew to stay in their cars, roll down their window, and remain in the car when interacting with service providers in that setting.

Additionally, the process did not require individuals to re-arrange their daily lives to engage in a new activity. The drive-through testing process mirrored practices many individuals already engaged in when driving to or from work (e.g., getting coffee at the drive-through) or during lunch (e.g., ordering lunch at the drive-through). The drive-through testing process thus fit readily into existing scripts that were part of most individuals’ regular routines. Finally, this new testing process mirrored existing design expectations to initiate an established script for starting, moving through, and completing a process. This mirroring involved signs (design) indicating entry and exit points for the process. Essentially, the design of these signs paralleled existing prototypes individuals used to identify and enter drive-through services (e.g., “Enter here for drive-through”) and exit them (e.g., “Drive-through exit”).

The result was a design thinking solution: A process based on observations of how humans act in contexts (i.e., engage with drive-through services) that led to a design solution (i.e., drive-through testing stations). Individuals could rapidly test and update this solution (e.g., revising the design of or moving the location of signs based on driver reactions) to create a process that addressed a need (rapid, effective testing facilities) and a related problem (a public health crisis). This design solution came via a new script based on cognitive models for existing practices in recognized contexts (i.e., how to act in drive-through lines). It did so through developing materials (signs) and activities (roles) participants recognized and knew how to use as they paralleled mental models (prototypes) individuals instantly recognized and used.

The rapid international adoption of drive-through COVID-19 testing facilities reveals how scripts and prototypes can lead to design solutions that solve problems and address needs. This situation also reveals how such approaches can be readily adapted for different audiences—as they have been for nations from South Korea to the U.S.—based on knowing and addressing an audience’s script and prototype expectations when designing products and solutions.

FINAL THOUGHTS

Design thinking pioneer Tim Brown (2008) notes one beauty of design thinking is almost anyone can use it. This is because design thinking focuses on observation, rapid prototyping, and iterative testing processes individuals can implement at a systems level. While simple to explain, enacting design thinking solutions involves understanding contextual dynamics that create problems or needs. Accordingly, the better one can observe and identify problems or needs in a context, the better one can implement design solutions. An understanding of cognitive factors affecting perceptions of contexts can facilitate these processes.

By applying cognitive concepts, individuals can enhance design thinking practices to better assess the dynamics affecting different contexts. The schemas of scripts and of prototypes can help with identifying context-related problems or needs and designing related solutions. These cognitive mechanisms can also help individuals understand the systems where contextual factors overlap and create designs that work at a greater system level. Through integrating scripts and prototypes into design thinking, individuals can create materials that better address the needs of workplaces, industries, and greater society.

REFERENCES

Aitchison, J. (1994). Bad birds and better birds: Prototype theory. In V. P. Clark, P. A. Eschholz, & A. F. Rosa (Eds.), Language: Introductory readings (4th ed., pp. 445–459). St. Martins.

Brown, T. (June 2008). Design thinking. Harvard Business Review, 84–92.

Buchanan, R. (1992). Wicked problems in design thinking. Design Issues, 8(2), 5-21.

Cave, K. R., Bush, W. S., & Taylor, T. G. G. (2010). Split attention as part of a flexible attentional system for complex scenes: Comment on Jans, Peters, and De Weerd. Psychological Review, 117(2), 685–695.

Cook, M. P. (2006). Visual representations in science education: The influence of prior knowledge and cognitive load theory on instructional design principles. Science Education, 90(6), 1073–1019.

Dym, C. L., Agogino, A. M., Eris, O., & Frey, D. D. (2005). Engineering design thinking, teaching, and learning. Journal of Engineering Education, 94(1),103–120.

Kirschner, P. A. (2002). Cognitive load theory: Implications on cognitive load theory on learning and design. Learning and Instruction, 12(1), 1–10.

Kleiner, A. (2009). The thought leader interview: Tim Brown. Strategy+Business, 56, 1–8.

Marois, R., & Ivanoff, J. (2005). Capacity limits of information processing in the brain. Trends in Cognitive Sciences, 9(6), 296–305.

Mentzer, N. (2014). Team based engineering design thinking. Journal of Technology Education, 25(2), 52–72.

Newman, P., Ferrarioy, M. A., Simm, W., Forshawz, S., Friday, A., & Whittle, J. (2015). The role of design thinking and physical prototyping in social software engineering. Proceedings of the 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering Vol. 2 (pp. 487–496). IEEE Computer Society.

Norman, D. (2002). The design of everyday things. Basic Books.

Owen, C. (2006). Design thinking: Notes on its nature and use. Design Research Quarterly, 1(2), 16–27.

Pass, F., Renkl, A., & Sweller, J. (2003). Cognitive load theory and instructional design: Recent developments. Educational Psychologist, 38(1), 1–4.

Pass, F., Renkl, A., & Sweller, J. (2004). Cognitive load theory: Instructional implications of the interaction between information structures and cognitive architecture. Instructional Science, 32(1), 1–8.

Postle, B. R. (2016). How does the brain keep information “in mind”? Current Directions Psychological Science, 25(3), 151–156.

Purdy, J. P. (2014). What can design thinking offer writing studies? CCC, 65(4), 612–641.

Rosch, E. (1978). Principles of categorization. In E. Rosch & B. B. Lloyd (Eds.), Cognition and Categorization (pp. 27–48). Lawrence Erlbaum.

Schank, R. C., & Abelson, R. P. (1977). Scripts, plans, goals, and understanding. Erlbaum.

St.Amant, K. (2005). A prototype theory approach to international web site analysis and design. Technical Communication Quarterly, 14, 73–91.

St.Amant, K. (2017). Of scripts and prototypes: A two-part approach to user experience design for international contexts. Technical Communication, 64(2), 113–125.

St.Amant, K. (2021). Connecting crisis to community: COVID-19 and beyond. Journal of Business and Technical Communication, 35(1), 126–133.

Schmidt, R. A. (1975). A schema theory of discrete motor skill learning. Psychological Review, 82(4), 225–260.

Sweller, J. (1988). Cognitive load during problem solving: Effects on learning. Cognitive Science, 12, 257–285.

Shalamova, N. (2016). Blending engineering content with design thinking and US to maximize student engagement in a technical communication class. 2016 IEEE International Professional Communication Conference (IPCC), (pp. 1–5). IEEE.

Tomkins, S. S. (1978). Script theory: Differential magnification of affects. Nebraska Symposium on Motivation, 26, 201–236.

Tomkins, S. S. (1987). Script theory. In J. Arnoff, A.I. Rabin, & R.A. Zucker (Eds.), The emergence of personality (pp. 147–216). Springer.

Tse, D., Langston, R. F., Kakeyama, M., Bethus, I., Spooner, P. A., Wood, E. R., Witter, M. P., & Morris, R. G. M. (2007). Schemas and memory consolidation. Science, 316(76), 76–82.

van Merrienboer, J. J. G., & Sweller, J. (2005). Cognitive load theory and complex learning: Recent developments and future directions. Educational Psychology Review, 17(2), 147–178.

van Merrienboer, J. J. G., & Sweller, J. (2010). Cognitive load theory in health professional education: Design principles and strategies. Medical Education, 44(1), 85–93.

Wickman, C. (2014). Wicked problems in technical communication. Journal of Technical Writing and Communication, 44(1), 23–42.

Wu, T. Dufford, A. J., Mackie, M. A., Egan, L. J., & Fan, J. (2016). The capacity of cognitive control estimated from a perceptual decision-making task. Scientific Reports, 6(34025), 1–11.

Yamada, R., & Itsukushima, Y. (2013). The effects of schema on recognition memories and subjective experiences for actions and objects. Japanese Psychological Research, 55(4), 366–377.

Your brain is like a computer. (2017). Ohio Valley Center for Brain Injury Prevention and Rehabilitation.

ACKNOWLEDGEMENTS

The author would like to thank the anonymous reviewers for their comments on how to shape and focus this entry to convey key ideas. The author would also like to thank the Eunice C. Williamson Endowment in Technical Communication for its support of this project.

ABOUT THE AUTHOR

Kirk St.Amant is the Eunice C. Williamson Chair in Technical Communication at Louisiana Tech University and is a member of the University’s Center for Biomedical Engineering and Rehabilitation Science (CBERS). Kirk serves as the Director of Louisiana Tech’s Center for Health and Medical Communication (CHMC) and is also an Adjunct Professor of Health and Medical Communication with the University of Limerick and a Research Fellow in User Experience Design with the University of Strasbourg. He is available at kirk.stamant@gmail.com.