One User, Two Conflicting Conceptual Models

At the very end of the Let’s Negotiate Away Some Meaning, I listed four participants that interacted with a conceptual model while it was realized in software. I did not illustrate this with a figure. So let’s start there.

Four Conceptual Models

Four Conceptual Models

In Chaos has Changed & Functional Cultures are Alive and Well, and other posts, I discussed where functional cultures come from. Each of us has subscribed to one or more of them. Each of us are users. As users, each of us has a conceptual model of our functional culture. This conceptual model provides an infrastructure of meaning upon which we build our rituals that we call work, or that Christensen called “Jobs to Be Done,” and that trainers and technical writers call tasks. In the figure, the user (1) maintains the source conceptual model that is realized to some degree in a software application.

In the Negotiate Away post, one of the figures illustrated the requirements elicitation process as being driven by the theory of the application. Elicitors ask users and stakeholders questions in order to validate the theory. This can lead to unfortunate errors. In that post, the theory acted as a filter. It is not shown in the above figure. In this post and that post, I omitted the role of the executive stakeholder and the functional unit manager of the elicited user. The elicitor (2) embeds some portion of the elicited user’s conceptual model in the functional requirements. In practice, the elicitor is not capturing meaning, and the requirements elicitation process is not focused on meaning. Requirements are modeled with tools like UML as opposed to ontological modeling tools.

Requirements come in two flavors: functional (What) and non-functional (How Well). The non-functional requirements deal with carrier issues. The functional requirements deal with both carrier and carried issues. The elicited conceptual model constitutes the carried component.

The arrow from user to elicitor should be filtered by the elicitor’s theory, and the user’s functional managers. The user’s functional managers are acting to select a particular generational paradigm within a functional unit’s culture. We know that a market is organized by the risk tolerance of the firms in a market. For a given firm that risk tolerance is the summation of the risk tolerances and behavior of the people within the firm. A purchase in a given category effects different business units and functional units within a firm, so the category selects the people within the firm whose risk tolerance characterizes the firms risk tolerance in that category. This means that Moore’s technology adoption lifecycle plays out across an organization and across the scales within the organization. A functional unit organizes its staff across generations, each with it’s own version of the unit’s functional culture, each sharing a core, but each different due to the state of the art when these staff members were trained. The state of the art organizes the paradigmatic cultures similarly to that of the category and the firm. The technology adoption lifecycle spans the functional unit.

Eventually, the conceptual model is realized at the view (3), at the interface. This conceptual model represents the outcomes of having communicated the conceptual model described in the requirements through the developers and user interface specialists that contributed to the realization of the interface.

When any user approaches an interface, they use a troubleshooting approach. This idea from Rathmussen. I ran across his book in the NASA JSC library back in the late 80’s. He was writing about operating plant culture.

The idea is that a user forms a hypothesis, takes some action, and then obtains feedback from the outcomes of that action. This teaches the user, the learner, how the application works. It teaches the user it’s meaning. The user builds a user conceptual model (4) of the application. The hypotheses originate in the interface, while the feedback reveals something of the model far removed from the interface.

The user’s hypotheses are based on the functional culture that was elicited from the user back during requirements elicitation. This functional culture is the source of the users expectations, which are embodied in that user’s hypotheses. Given that requirements are elicited from a market segment perspective, rather than a functional culture perspective, the usual expectation is that the outcomes will be distant from the functional culture. The user’s conceptual model (4) built from interactions with the application is really a model of the distance between the user’s functional culture and the application, the gap.

The user’s conceptual model also incorporates any compensations necessary to close the gap. These compensations show up in requirements asking for the ability to export and import from Excel and Access. Look for these type of requirements. They mean that the app doesn’t do what I need it to do. And, they demonstrate that value is actually created at a distance from the application out in the mid ground of the value chain.

An application enables value creation beyond the interface via scripting, macros, and the ability to use APIs and various protocols. These features enable use beyond design. Realize that enabling use beyond design will impact your user support functions spanning technical support, training, and documentation. Enabling use beyond design also seeds the search space beyond the thick tail for subsequent products, releases, and iterations. Build to search.

Do realize that the user is expected to maintain two conceptual models, aka two cognitive models. The conceptual model originating in the user’s  functional culture has been implicated. The user’s conceptual model originating at the interface is more likely to be explicated and incomplete. The user’s attention will limit discovery of the full range of features, and use of those features. The user’s attention and cognitive limits organize the features and concepts into networks. Their frequencies of use end up being organized on long tailed distributions. And, likewise, a factor analysis of those features and concepts will give rise to a discrete distribution echoing those long tails.

Comments? Thanks!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: