Back in Chaos has Changed & Functional Cultures I described how we get over the plateaus we get stuck on while learning something new. The climber can’t find the crack they need to get further up on their climb. They won’t find it on their own. Learning is social. Someone has to tell you, hey do this, reach over there. We do, we get it and we move on. Once we move on, we forget it. It seems so natural now. I called this process reimplication, the last step in the learning process. It’s the one we don’t notice. Ratcheting up is another term used to describe it.
This ratcheting up is a problem for elicitors.
To make ratcheting up real for you, think about how you drive from the office to your home. You do this everyday. You know the roads you take. You know why you take the particular roads you take.
I remember having to drive from Pasadena down to San Diego during rush hour. My boss knows that side of SoCal, so he clues me in. It only took 1.5 hours, an impossibly fast drive. Hell could have froze over. I had time to kill. I was ratcheted up.
I also remember a rainy day in Houston. I decided there were too many puddles in my usual lanes, so I slowed down drove in unfamiliar lanes, hit a puddle, spun out crossed the lanes twice bouncing off the divider, hitting a sign, sign snaps and hits the other side of my car. I was ok. I drove away. Everyone stopped. No one else involved. The insurance company totaled the car.
So where were we, oh, reimplicated. Forgot didn’t you. But, really, what road did you take this afternoon? Was there some reason you had to take another route? Will you remember that route Monday afternoon. You’ll have some vague notion that it was not a problem, but ordinary. That’s how reimpication feels.
The figure is our drive from the office to our home. We don’t recall the routine. The routine was not memorable. It was implicit. We remember the office, and home. We implicate them as well. Take a vacation. Do you think about the chores?
One night I was coming off a third shift at the grocery store and stopped to get some gas. The clerk was studying for his GRE. He was doing percentage problems. He has to remember three formulas. I can’t do that. I know algebra, so I don’t have to. My life is easier, because of algebra. I was ratcheted up. Examples can be found everywhere.
But, can we really talk about all the stuff we know and do in the most ordinary sense? Can we teach it? Can we teach it to the requirements elicitor? Mostly, we let them ask the questions. Oh! Did I leave off this tiny thing here? Probably.
On to Functional Cultures Visualization, part II.
Back in Building a Dog, Oh, Make that a Cat, I described the triangle model, and in the very last diagram of Visualizing Functional Culture, I left you with two triangles that I called models. Those models were associated with populations having taken different pedagogical pathways into a conceptualization. In this post, we’ll take a look at how the triangle model can be used to illustrate the gaps between our models and our apps.
I use the triangle model to illustrate processes surrounding realization, any realization. Making a concept real involves goals, search, decision making, tools, stuff, learning, teaching. Those tools and that stuff only gets into our hands, because they are realizations as well. And,they are realizations that embed all the decisions, aka knowledge, that was needed to make them. Most of that knowledge is like our drive to work, implicit. We don’t need to know. And, we don’t want to know. No information overload involved.
If you want to have fun, take a look at this slideshow on a website where I posted this stuff, before I moved to my prior, no longer served blog. Fun, did I over promise?
Anyway, enough of that.
Time going down is just weird, so lets do a smooth translation.
There we go. Time is headed in the correct direction. Time always moves left to right, unless you are dealing with the Slavic notion of time which has no arrow. Actually, turning the figure improved its fitness for use. It’s information design. You can imagine where the dollar axis goes. Decisions cost time and money, even the implicit decisions, those miles you drove, but can’t recall. We don’t have to explicate the decisions. The decision tree happens.
An application is a realization. I use two lines at the base of the triangle to illustrate the user interface, and at times, the API. Interfaces are as close to real as we get with software. The two lines will stand for realization throughout this post.
I use a single line at the base of the triangle to indicate an idea or concept. Keep in mind that as a concept can’t travel alone, that single line would be a conceptualization, the thing we used our icons from the last post to map out.
Here I’ve put the idea behind the realization inside the realization. Notice that the idea is a decision tree. In software, the carried idea is the application’s requirements.
A realization might involve more than one idea, or more than one collection of cultural meanings. Ontologies are easily represented as trees, hence decision trees, a triangle, a model. Lexicons can be planned in a discipline called language planning, so the language is a realization, a tool, which might express the concepts in an ontology. Just tying back to the central problem presented by functional cultures.
Notice that the models extend through the realization and into the future, into the depth beyond the interface, into the space of work product, and the stuff we do with work product–the real place where value is found. So no, it’s not UX stupid. I left the burner on, my food is burned, but I won’t have to cope with that until it’s plated and I’m eating in front of my TV–a long way from my stoves interface. But, the burn was a realization.
We use realizations to create realizations. Geeks focus on the former, users on the latter.
I drew this figure with the models extending beyond the realization, because I using the distance from the realization to the base of the model as the gap between my traded off functionality and what my users needed to work within the context of their functional cultures. I have another rep to cover the burned dinner. No, we won’t go there in this post.
So taking it back to people, we can write a software application for one person by eliciting requirements from that person and building what they want. No, gap. No persona. No market segment. No executive sponsor. No tradeoffs. No politics. Still, ratcheting up will be a problem. But, the functional culture is encoded, and no paradigmatic issues arise. Who cares if the elicited person is a dinosaur, or someone that cuts themselves shaving on the edge of the state of their art. No generational issues.
This assumes that the person is not operating in an environment that they don’t control. The person is not preparing income taxes. Everyone is operating in constrained environments, so their processes take that into account or the constraints are blackboxed or implicit. My truck is a blackbox with an automatic transmission, V-8, cup holder, CD changer, and a bench seat. There is just so much space for meaning. Hey, I love my truck. Just don’t make me dive under the hood.
I used the word carrier earlier. That comes from the software as media concept. A media consists of a carrier (gray) and a carried (aqua) component. The carrier is software. The carried is the controls users manipulate to do their work, their rituals. The carried encodes the meanings defined within the functional culture. We’ll bump into this idea again.
Back on the road, you’ll forget, ah reimplicate, the detour.
So here we have an application coded for several people. Their distance from the interface represents their gaps. So we have gaps; personas; market segments; an executive sponsor, sometimes called a product manager or a CEO; tradeoffs; politics; and paradigmatic issues. In short, we have a mess. We’ve managed that mess by pretending it works, and by delivering average functionality that fits no one. We let the time arrow go down. We invented the executive sponsor and personas to cure requirements volatility, but still our requirements are volatile. Yes, even with Agile.
So now we embody those people in their functional cultures.
Once we add the functional cultures back into the figure, we have the requirements, and the expression of those requirements. Each cultural model has its own blue. Each expression involves some distance from the interface, some gap. The person with the thinnest gap won the negotiation game, the political warfare around the meaning tradeoffs made so the developers could efficiently build the application. The tradeoffs cause compensating work, hence compensations. That compensating work creates off budget tradeoffs for the functional unit using the software. Off budget means implicit costs attributed to the functional unit. The IT department or vendor is not billed for the cost of the compensations, so nobody has any motivation to eliminate those costs. Measure it. “Measure what?”
Here we show users and the gaps involved in their use of several different applications in their daily do. The gaps are not the same size for each person using the same application, and the gaps are not the same size from one application to another. It’s a rough world. Those 360 degree gaps are the UXs involved in just getting your work done.
So we have used the triangle model to demonstrate the relations between people, their functional cultures, and the applications they use. I hinted at how the iconic representation of a conceptualization ties to the triangle model. And, we talked about ratcheting up.
And, would you know it, I still have some figures left over. Yet another post on this subject. It should be shorter.
One day, with an appropriate toolset and an ethnographer on board to find the meanings and the ratcheting ups, we can close the gap. We as product managers or the person with another job title who does product management before a product manager shows up can get this done. Try it. Draw it. Spec it. Implement it. Well, get it implemented. Is development already using Aspect-Oriented Programming? If so, it can happen next week.
Comments. Really. A comment long ago set me to find the why behind requirements volatility. Oh, I was mad. Oh, I didn’t like the guy. But, hey, he was key. He challenged my dearly held idea. He made it stronger. Fire away.