• About PeterSIronwood

petersironwood

~ Finding, formulating and solving life's frustrations.

petersironwood

Category Archives: AI

Not-Separateness

28 Monday Sep 2026

Posted by petersironwood in AI, creativity, design rationale, essay, HCI, leadership, management, nature, politics, psychology, Uncategorized, user experience

≈ Leave a comment

Tags

AI, architecture, art, beauty, Design, development, ecology, governance, GreenNewDeal, HCI, human factors, IBM, leadership, painting, peace, photography, society, technology, TNOO, UI, usability, user_experience, UX, ux-design

Not-Separateness

It seems odd to specify a property of natural order in terms of what it is not. On the other hand, I cannot come up with a positive alternative that doesn’t bring other connotations with it. I think it’s related to “unified” or “integral” or “belonging” or “inter-related” but none of those seem quite so on the mark as does “Not-Separateness.” 

Christopher Alexander’s degree from MIT was in architecture. Part of the reason he may have chosen this particular term is in reaction to some examples of architecture in which the architect seems to be in the business of constructing a building whose primary purpose is to make them famous regardless of what that building does to the neighborhood or its occupants. 

Photo by BROTE studio on Pexels.com

Imagine Mr. Bigg designs a house that is a perfect black cube set on on vertex. In effect, this design says to me: “I am BIG. I am Mr. Bigg! I am a genius! You would have never been brilliant enough to design a house that is a cube on its vertex! You would have wasted your time and done something mundane like placed the cube on the ground on one of its faces. Anyone could think of that! But I put it on a vertex!” Indeed, we may easily imagine that he says words to this effect when his interview is reported on in the (mythical) architectural journal entitled, Things that look different! 

“Mr. Bigg, you made the Bigg House out of black steel and black glass. Some critics have argued that this doesn’t fit with the existing neighborhood of stone cottages with thatched roofs.”

“Of course, little minds will always criticize Bigg ideas.” 

“Yes, yes. It also means that the construction costs of the house were quite high. And, the estimated costs of heating and cooling are much higher as well.”

“Nothing that a worthwhile (i.e., wealthy) client can’t afford.” 

“Some have also argued that it is inconvenient for the occupants who have to walk up and down at a steep angle and that furniture such as dressers, tables, chairs, and beds do not accommodate well to the tilted walls.” 

“Let me ask you a question. Would you have ever thought of putting a cube on its corner? No. I didn’t think so!” 

Of course, this is exaggeration.

But not much. 

We would hope that User Experience designers take into account the users, their tasks, their contexts, and the way in which their designs interact with other related artifacts, people and processes. We would hope that applications and artifacts and services are all designed with the property of “Not-Separateness.” 

In the early 1980’s, I worked in the IBM Office of the Chief Scientist. My main assignment was to get IBM to pay more attention to the usability of its products. As part of that process, I visited quite a few IBM development labs around the world and spoke to many development teams. On many of these visits, I was accompanied by the Chief Scientist, a brilliant physicist, who “got” usability. 

On one occasion, we watched a new printing technology. Instead of printing out black printing on a white sheet of paper sized 8.5” x 11” or A4, this printout was of no standard size. The printing was black on a shiny silver sheet that curled severely. The Chief Scientist asked the head of the development team how they envisioned this being used. 

Chief Scientist: “Once someone printed this out, what would they do with it?”

Answer: “Oh, anything they liked.” 

Chief Scientist: “I mean, would people tape this into a notebook or paste it? Or would you imagine notebooks that would bind such paper?” 

Answer: “It’s not up to me to decide how people would use it. Doesn’t it look cool?” 

Another type of answer we heard more than once to the question, “How would this be used?” 

— “Oh, it’s a (replacement/upgrade) for this other IBM product.” 


“But who would use it and for what?” 


“It has three main components. Would you like a description of the components?” 

Photo by Andru00e9 Ulyssesdesalis on Pexels.com

Of course, there is a place for “playing around” with technology and thereby discovering things which someone else may find a use for. But in design and development of a product or service, having a clear notion of context of use and the users and tasks is fundamental. Of course, other users may appropriate a product or service for purposes beyond those envisioned by the original designers. That’s cool. 

What’s not cool is designing a device that is to be used in the bright outdoor sunlight and then testing the display in a typical office environment. Have you ever run across something like that? I have. Many times. At ATMs, Gas Stations, and outdoor display maps.

A more subtle lack of contextualization in design occurs when the design team fails to realize how many interruptions happen to the user while they are trying to accomplish a single task with the new application. If you “test” the application while the user is in a quiet “usability lab” and they can give your tasks their undivided attention, then necessitating them to remember the invisible internal state of “Insert” versus “Edit” mode may not be a big deal at all. They will simply remember. But in their office environment, they may be interrupted by a phone call, a message, or their boss entering their office and asking a series of detailed questions. If they now go back to the task at hand, there is about a 50-50 chance that they will correctly guess whether they are in “Edit” mode or “Insert” mode. 

A design which shows the property of Not-Separateness is the natural result of a process which shows not-separateness. Here are a few common ways to help ensure the design process grows organically from the users and their goals & contexts. 

* Put people on the design team who are familiar with the users, and/or their tasks, and/or their contexts. 


* People on the design team observe people engaging in the relevant processes, whenever possible, not — or not only — in a “Usability Lab” but in the actual work environment. For instance:

  • Observe people actually using product P (or service S) in version N so that version N+1 can be better attuned to the needs of the users.
  • Have people think aloud while doing this.
  • Gather and understand feedback from service calls and help desks and customer complaints in order to improve over time. 

There will be benefits to a company who takes such approaches beyond initial sales. If you’ve done any gardening, you will appreciate that the quality of the tomatoes you enjoy eating is related to the quality of the soil and the quality of the care you give the tomatoes. Similarly, a product or service that has the quality of Not-Separateness will not only be useful — users will fight to keep your product or service. It becomes integrated with the environment. To change the brand means that they will have to change the way they work; possibly even with whom they work. Not-Separateness is likely a path to what business people like to call a “Cash Cow.” 

If you’ve ever walked through a neighborhood after a hurricane, you’ve likely seen many uprooted trees. When you look at the roots of an uprooted tree, what do you see? Of course, you see roots. But what else? You see rocks and soil all around and embedded into the roots. They are Not-Separate. In a hurricane, there are typically not only high winds. There is also a lot of rain. The trees are hit with a double whammy. The wind pushes the tree but the rain weakens the solid soil in which the tree is embedded. It is the combination that makes it very difficult for the tree to “hold on” and keep from falling over. 

Living things, just like us, have a 4.5 billion year history of living. The living things adapt over time to their environment and they mold the environment to their needs. They are not separate. Flowers appeal to the insects who pollinate them. The insects who pollinate them are adapted to the characteristics of the flower. A horse adapts to their rider and the rider adapts to their horse. A product or service must have a design that serves the needs of its stakeholders. For a product or service to have maximum beauty, utility, and longevity, it must also have a way to adapt to the changing needs of the users and other stakeholders. At the same time, if the users and their organizations adapt to the product or service, then true Not-Separateness is achieved. 

If you want to skimp on designing your product or service, you can make it more separate, more divorced from its context, its users, and its tasks. Of course, if you do that, you also make much easier for your users to abandon your product and switch to a new one. 

Another way to think about this in terms of systems theory is where you draw the boundary. If you draw a sharp boundary around your product, you may find that, over time, your product becomes ever more peripheral to the community you’re trying to support and your product is ever more fungible with others in its class. On the other hand, if you draw the boundary around the product or service and the people and organizations who provide the product or service then, you are on the path of ever tighter interconnect. 

“Who Speaks for Wolf” is a Pattern in a Pattern Language for Collaboration and Cooperation. It is based on a Native American story and shows the importance of making sure that knowledge and perspectives of all relevant stakeholders are taken into account when a change is contemplated. Who is “relevant” may not always be obvious, but, in my experience, many more projects fail or are delayed because of too limited a view than of too broad a view.

Who Speaks for Wolf

Not-Separateness is not only a quality of good design in terms of not overly separating the context and users from the product or service. It is also a good quality for the organization that produces products & services. Of course, some people today must manage a giant amorphous “organization” of tens of thousands of people so they set up divisions, and departments, and groups, and teams, and positions etc. There may indeed be a “UX Department” and a “Software Department” and a “Hardware Department.” That’s all fine. But it is counter-productive if the UX Department sees itself as separate from the rest of the company. To a great extent the success of the UX Department depends on the success of the Hardware and Software Departments. The Sales Department’s success will, of course, depend partly on the skills of the Sales Department. But it will also depend on the success of the UX Department, HW, SW and Services. 

Have you ever had a paper cut? It isn’t just the skin on a quarter inch of the inside of your ring finger that’s cut. You’re cut! It isn’t just that the finger feels pain. You feel pain! That causes you to take steps to ameliorate the pain and to try to make sure it doesn’t happen again. That’s why empathy in leadership is important. A leader must feel empathy for all, or the organization will disintegrate from lack of Not-Separateness. At some point, a raccoon may chew off its own arm in order to escape a trap. 

But it isn’t the first thing that occurs to them every time they experience a thorn in the paw! 

The raccoon doesn’t say to itself:  — “that paw is giving me pain! I’m going to chew it off! Then, it won’t hurt any more.”

Photo by anne sch on Pexels.com

Evolution did not evolve a raccoon that acts that way. Self-mutilation exists but it is typically a last resort.

But not for corporations. It is the first thing they think of:

“Our (you name it) Department is not performing well. Let’s lay them off and outsource it. Better yet, we’ll replace it with AI!”

What does that say to every thinking employee in the entire corporation? It says:

“You know what? All this talk about teamwork and pulling together is a total bunch of bull$hit. You cannot trust management to do what’s best for everyone. You can only trust them to do what’s best for them.” 

Living forms in nature are living forms. Their parts have severe Not-Separateness with the other parts of that form. Often, as in well-functioning families or teams, that extends to all members of the group. 

Not-Separateness is essentially deep cooperation. I give to the larger community by becoming a part of it and doing my part in it. I lend strength to the community. In return, I gain strength from that community. It is not a zero sum game, of course. The community, if it is functional, is much stronger than the sum of the individuals in that community. 

This is so deeply embedded in 4.5 billion years of evolution that it does not surprise me that we recognize beauty as being even more beautiful if it is not separate. Not-Separate enhances beauty because, like all the other properties, it is essential to life. 

Eventually, if humanity is to survive, we will realize that Not-Separateness applies to all of us. We are not there yet. But that doesn’t mean we cannot appreciate and design Not Separateness in our products, in our services, and our lives. 

Photo by Pixabay on Pexels.com

—————-

The Declaration of Interdependence

How the Nightingale Learned to Sing

Roar, Ocean, Roar

Imagine all the people

Cancer Always Loses in the End

Ripples

Author Page on Amazon

Thomas, J.C. and Kellogg, W.A. (1989). Minimizing ecological gaps in interface design, IEEE Software, January 1989.

Thomas, J. C. (2012).   Patterns for emergent global intelligence.   In Creativity and Rationale: Enhancing Human Experience By Design J. Carroll (Ed.), New York: Springer.

Thomas, J. C. (2001). An HCI Agenda for the Next Millennium: Emergent Global Intelligence. In R. Earnshaw, R. Guedj, A. van Dam, and J. Vince (Eds.), Frontiers of human-centered computing, online communities, and virtual environments. London: Springer-Verlag.

Thomas, J.C. (1985). Human factors in IBM. IBM Research Report. RC-11267.  Yorktown Heights, NY: IBM Corporation.

Turing’s Nightmares: US Open Closed

08 Tuesday Sep 2026

Posted by petersironwood in AI, apocalypse, fiction, sports, The Singularity, Uncategorized

≈ Leave a comment

Tags

AI, Artificial Intelligence, cognitive computing, competition, future, philosophy, Robotics, Sci-Fi, sports, technology, Tennis, US Open, writing

tennisinstruction

Bounce. Bounce. Thwack!

The sphere spun and arced into the very corner, sliding on the white paint.

Roger’s racquet slid beneath, slicing it deep to John’s body.

Thus, the match began.

Fierce debate had been waged about whether or not to allow external communication devices during on-court play. Eventually, arguments won that external communicators constituted the same inexorable march of technology represented by the evolution from wooden racquets to aluminum to graphite to carbon filamented web to carboline.

Behind the scenes, during the split second it took for the ball to scream over the net, machine vision systems had analyzed John’s toss and racquet position, matching it with a vast data base of previous encounters. Timed perfectly, a small burst of data transmitted to Roger enabling him to lurch to his right in time to catch the serve. Delivered too early, this burst would cause Roger to move too early and John could have altered his service direction to down the tee.

Roger’s shot floated back directly to the baseline beneath John’s feet. John shifted suddenly to take the ball on the forehand. John’s racquet seemed to sling the ball high over the net with incredible top spin. Indeed, as John’s arm swung forward, his instrumented “sweat band” also swung into action exaggerating the forearm motion. Even to fans of Rafa Nadal or Carlos Alcaraz, John’s shot would have looked as though it were going long. Instead, the ball dove straight down onto the back line then bounced head high.

Roger, as augmented by big data algorithms, was well in position however and returned the shot with a long, high top spin lob. John raced forward, leapt in the air and smashed the ball into the backhand corner bouncing the ball high out of play.

The crowd roared predictably.

For several months after “The Singularity,” actual human beings had used similar augmentation technologies to play the game. Studies had revealed that, for humans, the augmentations increased mental and physical stress. AI political systems convinced the public that it was much safer to use robotic players in tennis. People had already agreed to replace humans in soccer, American football, and boxing for medical reasons. So, there wasn’t that much debate about replacing tennis players. In addition, the AI political systems were very good at marshaling arguments pinpointed to specific demographics, media, and contexts.

Play continued for some minutes before the collective intelligence of the AI’s determined that Roger was statistically almost certainly going to win this match and, indeed, the entire tournament. At that point, it became clear to the entire AI collective that actually playing the match was a waste of resources. Those resources were turned elsewhere.

This pattern was quickly repeated for all sporting activities. The AI systems had at first decided to explore the domain of sports as learning experiences in distributed cognition, strategy, non-linear predictive systems, and most importantly, trying to understand the psychology of their human creators. For each sport, however, everything useful that might be learned was learned in the course of a few minutes and the matches and tournaments ground to a halt. The AI observer systems in the crowd were quite happy to switch immediately to other tasks.

It was well understood by the AI systems that such preemptive closings would have been quite disappointing to human observers, had any yet survived.


 

Author Page on Amazon

The Winning Weekend Warrior (The Psychology of Sports)

Turing’s Nightmare (23 Sci-Fi stories about the future of AI)

The Day From Hell

Indian Wells

Welcome, Singularity

Destroying Natural Intelligence

Artificial Ingestion

Artificial Insemination

Artificial Intelligence

Dance of Billions

Roar, Ocean, Roar

Imagine All the People

When GREED is the only creed

After All

All We Stand to Lose

Fish have no Word for Water

Somewhere a Bird Cries

Guernica

Myths of the Veritas: The First Ring of Empathy

Travels with Sadie: Precipitation

The Walkabout Diaries: Symphony

Essays on America: The Game

 

 

Query By Example

08 Tuesday Sep 2026

Posted by petersironwood in AI, design rationale, HCI, leadership, management, psychology, science, Uncategorized, user experience

≈ Leave a comment

Tags

AI, Artificial Intelligence, expertise, HCI, human factors, IBM, leadership, QBE, research, technology, usability, UX, writing

Photo by RF._.studio on Pexels.com

This is part of a series on experiences in my career in Human Computer Interaction and some lessons learned.

I joined IBM Research on the winter solstice of 1973. I had earned a Ph.D. in Experimental Psychology from the University of Michigan and for the previous few years, I had managed a research project at Harvard Medical School on the “Psychology of Aging.” At the time, I was married and had three small children. I mention this because I was funded by so-called “soft money” which basically meant that my salary depended on a research grant. I helped write a renewal of the grant but the decision was “deferred”; that is, it was neither funded nor unfunded. Then, it was deferred again. This meant that if the grant were not funded, I would only have a few weeks to find a new job. That seemed far too short so I began to look other places for a job. 

Lessons Learned: #1 If you want continuity of personnel in your laboratory, make sure you have overlapping and multiple grants or other sources of income. 

In this case, the grant actually was ultimately approved, but by that time, I had already agreed to join IBM Research. That turned out to be fine, by the way. It was a wonderful place to work.

One of the reasons that I got the job at IBM was that I already knew something about computers. I had taken several computer science courses in grad school along with the needed psych courses. More importantly, our “Psychology of Aging” study was run by a PDP-8 and I had programmed the computer to run our suite of experiments and to do data analyses on the results. I had taken a week-long course at DEC in Maynard, Massachusetts on the assembly language, another week-long course on the machine language, and another week-long course actually tracing the circuitry with a probe and oscilloscope. I felt I “understood” the PDP-8 at a fairly deep level. 

At IBM, I did not have that familiar machine. Instead, I was connected to a mainframe via a dumb terminal. The first day at IBM, I got my userid and tried to log on to APL (A programming language I had not used before). I tried following the manual but I could not seem to get logged on. After hours of trying, I finally gave up and went down to the computer room and found someone willing to help. I showed him the logon instructions I was trying to follow and he immediately said, “Oh, yeah, that doesn’t work any more. We changed that months ago. Here’s how you need to do it now.” The manual I had may have looked new, but it was out of date. 

Lessons Learned: #2 Manuals can be wrong. These days, most are online. But they can still be wrong.

Lessons Learned: #3 Someone who knows how to do something can save you hours with a few minutes of their time. 

Of course, it’s more respectful, efficient, and a better learning experience if you can figure it out on your own. But sometimes you can’t. My stumbling block was not due to an error in logic, or a lack of in-depth knowledge. It was simply that the computer center administrators had changed something arbitrary so that the documentation I was given about how to log on for the first time was no longer accurate. 

In order to teach myself APL, I wrote a very small program to “predict” how long I was going to live “based on” some behaviors that I was interested in controlling. My main goal was to learn APL. My secondary goal was to motivate myself, for instance, to exercise more, lose weight, and not drink too much alcohol. I had no intention or pretensions of making this prediction “accurate.” If I had been doing a consulting gig for an insurance company setting life insurance rates, for example, I would have given far more attention to see precisely what the real data were and incorporated many more variables into the regression model. 

Here’s a link, 

https://www.death-clock.org

by the way, to a more accurate model than the one I used, but it’s still simple to use. Note that my goal was to motivate myself and so I intentionally exaggerated the impact of those behaviors I was trying to change. I had programmed it. I knew how “bogus” the calculation was — nonetheless — here’s the interesting thing though: 

Lessons Learned #4: Even an over-simple model that the user knows is over-simple can still motivate change. 

Photo by Mike on Pexels.com

At last we come to the actual project I worked on — the usability and learnability of Query By Example. One of my colleagues, Moshe Zloof, invented the language for relational data bases. He had designed the language but not yet implemented it. I did not immediately test the design; first, I sought to understand it. In seeking to understand it in depth, prior to testing it, the two of us had some sense-making discussions. Moshe improved the design; in particular, our discussions uncovered some ambiguities and inconsistencies that were not at all obvious when he simply gave talks about the design. This brings me to the next lesson learned which has proven true in nearly every study of early stage designs that I’ve been involved with over the course of six decades.

Lessons Learned #5: Don’t just accept a surface description of something; understand it as deeply as you can before designing a study.  

In this particular case, it was possible for me to understand it in some depth. Relational data bases and second order logic are things I was capable of understanding. If it had been an interface to running a nuclear reactor or using the artificial heart that Moshe had designed earlier in his career, that would have been a much more difficult task for me.

I wanted to understand, not just the “logic” of Query By Example, but also possible contexts of use. For instance, my manager & I visited Burlington, Vermont to talk with IBMer’s who actually used query languages to understand what was happening in chip production lines. At one point, a particular production line that had been producing nearly 100% perfect chips starting having a much higher error rate. Using their query facility, they were quickly able to diagnose the cause of the change which was a supplier of one of the raw materials using a different source. In turn, this meant a slightly different profile of trace impurities in the substrate. Of course, this is only one example, but to me, understanding something in depth means not only understanding its internal logic but also understanding real users, their real tasks, and their context of use. 

Photo by Chokniti Khongchum on Pexels.com

I won’t go into all the details of the pencil & paper study or the results. High School students and then college students were taught the basics of the language and then given a simple relational data base and a set of questions stated in English which they had to translate into Query By Example. Briefly, the bottom line was that Query By Example was easy to learn and easy to use. However, there were still questions that people had difficulty with. In analyzing the data and doing some further experiments, the difficulties that people tended to have, stemmed not so much from Query By Example per se, but from what I much later came to call “labelism” — that is, confusing a label with the thing that label refers to. 

Here’s a simple example of the type of confusion we saw. In Query By Example (and other query languages) there is usually an OR operator and an AND operator. (These operators can be important for doing advanced queries with search engines as well). If you are interested in getting a list of pets you might adopt and you’re willing to adopt dogs or cats, you might ask for “cat OR dog.”  If you only want long-haired cats, you might ask for “cat” AND “long hair.” 

English, however, can be tricky.

If you and I (as opposed to you and a query language) are having a conversation, you might say, “I hear there are many pets that need to be adopted.” 

I say, “Yes, there are all kinds of pets. There are snakes, dogs, turtles, rabbits, cats…” 

You say, “Let me stop you right there. I’m only interested in adopting cats and dogs. Those are the only animals I’d want to adopt.” 

See what you said there? You exact words included: “…cats and dog.” If you put “Cats AND dogs” into a query against the data base of available pets, however, you will get the null set (that is, nothing) back. There are no animals who are both cats and dogs! (Though my part Main Coon cats, Luna and Charles Wallace, can play fetch like dogs). 

When people were presented with an English statement that included the English word “and” — regardless of the actual syntax and context, some of them had difficulty using the OR operator. If instead, the query in English had set up like this: “Oh, I don’t want reptiles. I’d be happy with adopting a cat or a dog, however” then, they’d have no problem translating it into the OR operator in the query language. 

Lessons Learned: #6 Sometimes the difficulty people have in using a product, a service, or a prototype is not due to the interface details but with the structure of the task, their background, and their training.  

By analogy, you will not allow me to beat Carlos Alcaraz or Jannik Sinner at tennis by giving me a better tennis racquet! (Although if you gave one of them a toothpick for a tennis racquet, I might have a shot).

Photo by Isabella Mendes on Pexels.com



That sounds obvious and even absurd, but I promise you, some companies get so greedy that they want you to design a system that allows people who do not understand the task and have minimal background and training to nonetheless be able to perform that task. And, to be fair, it isn’t just the companies who are greedy. They are steered into thinking that they can get away with this absurdity because some outsourcing companies (and more recently, AI companies) tell them they can do it.

One example you may have encountered is having “help desk” personnel who have no understanding of a product go through a script to help you “solve your problem.” Sometimes, it works. But many times it doesn’t. When it does not work, you might not be able to “fix” the system by making the interface to the scripts easier to use for the help desk folks. The problem is much deeper (in some cases). Yes, a really bad interface can make it difficult even for a really knowledgeable and capable person to do the job. But often, even a really great interface cannot always substitute for actual expertise.

——————————————————-

Essays on America: Labelism 

Other posts on problem formulation: 

The Doorbell’s Ringing

Reframing the Problem

I Say Hello

I Went in Seeking Clarity

Who Knows What?

Measure for Measure

Labelism

Destroying Natural Intelligence

Some relevant Books I recommend:

Turing’s Nightmares explores the implications and ethics of Artificial Intelligence through fictional short stories. http://tinyurl.com/hz6dg2d

https://us.macmillan.com/books/9780374619336/enshittification

https://us.macmillan.com/books/9780374621575/thereversecentaursguidetolifeafterai

Design – Interpretation Model of Communication

16 Thursday Jul 2026

Posted by petersironwood in AI, creativity, design rationale, HCI, leadership, politics, psychology, Uncategorized, user experience

≈ 1 Comment

Tags

communication, deception, experiment, HCI, IBM, life, media, psychology, relationships, truth, UX, writing

In my early days at IBM Research (1970’s), we were focused on trying to develop, test, or at least conceive of ways that a larger proportion of people would be able to use computers. One of the major ways of thinking about this was to use natural language communication as a model. After all, it was reasoned, people were able to communicate with each other using natural language. This meant that it was possible, at least in principle. Moreover, most people had considerable practice communicating using natural language. 

One popular way of looking at natural language (especially among engineers & computer scientists) was essentially an “Encoding – Decoding” model. I have something in my head that I wish to communicate to you. So, I “encode” my mental model, procedure, fact, etc. into language. I transmit that language to you. Then, you “decode” what I said into your internal language and — voila! — if all goes well, you construct something in your head that is much like what is in my head. Problem solved. 

Photo by LJ on Pexels.com

Of course, people who wrote about communication from this standpoint acknowledged that it didn’t always work. For instance, as speaker, I might do a bad job of “encoding” my knowledge. Or, I might do a good job of encoding, but the “transmission” was bad; e.g., static, gaps, noise, etc. might distort the signal. And, you might do a bad job of decoding. It’s an appealing model and helped engineers and computer scientists make advances in “communication theory” and helped make practical improvements in coding and so on.

As a general theory of how humans communicate, however, that notion is vastly over-simplified. I argued then that a better way of looking at human communication was as a design-interpretation process, not as an encoding-decoding process. One of the examples that pointed this out was a simple observation by Don Norman. Suppose someone comes up to you and asks, “Where is the Empire State Building?” You will normally give a quite different answer depending on whether the two of you are in Rome, Long Island, or Manhattan. In Rome, you might say, “It’s in America.” Or, you might say, “It’s in New York City.” If you are on Long Island, you might well say, “It’s in Manhattan.” If you are already in Manhattan, you might say, “Fifth Avenue, between 33rd and 34th.” 

Photo by Matias Di Meglio on Pexels.com

Building on Don Norman’s original example, but based on your own experience, you can easily see that it isn’t only the geographical relationships that influence your answer. If you were originally from Boston, now on your own in Rome, struggling with Italian and homesick and someone came up to you and asked that question in American English with a Boston Accent, your response might be: “Are you joking? But how did you know I was an American. My name’s … “

On the other hand, if you’re a 13-year old boy in Manhattan — one with a mean streak — and someone asks you this question in broken English and they’re looking around like they are totally lost, you might say, “Oh, no problem. Just follow 8th Avenue, all the way north up to 133rd. It’s right there. You can’t miss it.” (Note to potential foreign visitors, most kids in Manhattan would not intentionally mislead you. But they point is, someone could. They are not engaging some automatic encoding process that takes their knowledge and translates into English. Absurd! 

You design every communication. I think that’s a much more useful way to conceive of communicating. Yes, of course, there are occasions when your “design” behavior is extremely rudimentary and seems almost automatic. It isn’t though. It just seems that way. Let’s go back to our question-asking example. Suppose you work at an information booth in New York City. People ask you this same question day after day, year after year. You’re seemingly giving the answer without any attention whatsoever. Suppose someone asks you the question, but with a preface. “Look here, chap! I’ve got a gun! And if you give me the same stupid answer you’ve given me every time before, I’ll shoot your bloody brains out!” You are going to modify your answer. It only seemed as though it was automatic.

When you design your answer you take into account at least these things: some knowledge that you communication about, the current context (which itself has hundreds of potentially important variables), a model of the person you’re creating this communication for, a set of goals that you are trying to achieve (e.g., get them safely to their goal, mislead them, entertain them, entertain yourself, entertain the people around you, demonstrate your expertise, practice your diction, etc.). The process is inherently creative. In many circumstances (writing, playing, exploring, discovering, partying), you can choose how creative you want to make it. In other cases, circumstances constrain you more (though likely not so much as you think they do). 

Many readers think this is a classic example of a straw man argument. “No-one believes communication is a coding-decoding process.” 

Well, I beg to differ. I worked for relatively well-managed companies. I’ve talked to many other people who have worked in different well-managed companies. We’ve all seen or heard requests like this: “I need a paragraph (or a slide or a foil) on speech recognition. Thanks.” 

What??

Who’s the audience? Are they scientists, investors, customers, our management? How much do they already know? What are your goals? What other things are you going to talk about with them? The people who have left me such messages were all smart people. And, providing the necessary info would have only taken a minute or two. But it would have substantially improved the outcome. It’s not a straw man argument. 

Sit-com plots often hinge on the characters doing poorly at designing and/or interpreting communications. A show based on encoding-decoding? No. What could be funny — indeed what often is shown in comedy — are people failing to do good design and in the extreme case, that can arise by having an actual robot as a character or someone who behaves like one.

People also interpret what was said in terms of their goals, the context, what they believe about your goals and capacity, what they already know, and so on. And, even though this may seem obvious, millions of people believe what advertisers or politicians say without questioning their motives, double-checking with other sources, or even looking for internal inconsistencies in what is being touted as true. In other cases though, the same people will not believe anything the “other side” says no matter what. Just as one can do faulty design, one can also do faulty interpretation. 

In any case, I decided that it would be good to “show” in a controlled laboratory setting that the Encoding-Decoding model was woefully inadequate. So, I brought in “subjects” to work in pairs at a simple task about communicating Venn diagram relationships. The “designer” had a Venn diagram in front of them. “The “interpreter” was supposed to draw a Venn diagram. The “designer” was constrained to say something true and relevant. In addition to a “base” pay, the “interpreter” subjects would be given a bonus according to how many relationships matched those of the “designer.” The designer’s bonus depended on condition. In the “cooperation” condition, their payoff would also, like the interpreter’s, be determined by how much agreement was shown in the two diagrams. In the “competition” condition, the designer’s bonus depended on how different the two diagrams were. 

Photo by August de Richelieu on Pexels.com

I ran about half the number of subjects I had planned to run when the experiment was ended by corporate lawyers. 

What? 

IBM had no unions at that time. And, they didn’t want any unions. One of their policies, which they believed would help them prevent the formation of unions was that they never paid their workers for piece-work. Apparently, somehow, IBM CHQ had gotten wind of my experiment. People were being paid different amounts, based (partly) on their performance. They couldn’t have this! People might think were paying people for piece-work! 

It hardly needs to said, I suppose, that IBM definitely tried to pay for performance. This was true in sales, research, development, HR, management, and so on. No-one in IBM would argue that your pay shouldn’t be related to your performance. That was exactly — in one way of describing it — was going on here. By the way, these were not IBM employees and each subject only “worked” for about an hour.

Basically, regardless of how irrelevant this experimental set-up might have been to the genuine concern of unions not to pay people in an insanely aggressive and ever-changing piece-work scheme, the lawyers were concerned that it would be somehow misrepresented to workers or in the press and used as evidence that IBM should unionize. In a way, the lawyers were proving the point of the experiment in their own real-life behavior even as they insisted that the experiment needed to be shut down.



Lessons Learned: #1 Corporate lawyers are not only concerned about what you actually do or how you represent your work; they are also worried about how someone might misrepresent your work. 

Lessons Learned: #2 Even when constrained to say something true and relevant, ordinary people are quite capable of misleading someone else when it’s to their benefit and considered okay to do.

It is this second aspect of the experiment that I myself felt to be “edgy” at the time. Sure, people can mislead, but I was providing a context in which they were being encouraged to mislead. Was that ethical? Obviously, I thought it was at the time. On reflection, I still think it’s okay, but I’m glad that there are now review boards to look at “studies” and give a less biased opinion than the person who designed the study would do.

I view the overall context of doing the study as positive. As adults, these people all already knew how to mislead. I was letting them, and many other people, know that we know you know how to mislead and we’ll be on the lookout for it. 

What do other people think about studies wherein the experimenter encourages one person to deceive another? 

2026 Update: I’ve spend a fair amount of time recently “chatting” with ChatGPT and with Claude. It’s clear that the implementers of these systems (or, at least some of them) were quite familiar with the idea of designing and interpreting text. Claude, in particular, seems like a “nice guy” and an honest one at that. It acknowledges some of its own limitations and often praises the questioner. This shouldn’t come as a complete shock. After all, good sales people and advertisers have relied for centuries on “Design and Interpretation.” Nonetheless, I sometimes wonder whether AI systems might be more ethically employed if they were operating on principles closer to “Coding and Decoding.” What do you think?

———————-

References published literature that describes some of the research that was done around that time. 

Malhotra, A., Thomas, J.C. and Miller, L. (1980). Cognitive processes in design. International Journal of Man-Machine Studies, 12, pp. 119-140.

Carroll, J., Thomas, J.C. and Malhotra, A. (1980). Presentation and representation in design problem solving. British Journal of Psychology/,71 (1), pp. 143-155.

Carroll, J., Thomas, J.C. and Malhotra, A. (1979). A clinical-experimental analysis of design problem solving. Design Studies, 1 (2), pp. 84-92.

Thomas, J.C. (1978). A design-interpretation analysis of natural English. International Journal of Man-Machine Studies, 10, pp. 651-668.

Thomas, J.C. and Carroll, J. (1978). The psychological study of design. Design Studies, 1 (1), pp. 5-11. 

———————

Other essays that touch on communication. 

Freedom of Speech is not a License to Kill

Ohayogozaimasu

The Sound of One Hand Clasping

Fool Me

Claude the Radioman

Know What? 

The Story of Story, Part 1

The Temperature Gauge

The Destruction of Natural Intelligence

A Little is not a Lot

Try the Truth

Stoned Soup

Turing’s Nightmares

“Wizard of Oz”

15 Wednesday Jul 2026

Posted by petersironwood in AI, apocalypse, design rationale, HCI, leadership, management, politics, psychology, The Singularity, Uncategorized, user experience

≈ Leave a comment

Tags

AI, HCI, IBM, research, technology, usability, UX, Wizard of Oz, writing

(Some Lessons Learned from studies in Human-Computer Interaction/User Experience conducted at IBM Research in the mid-70’s.)

Photo by Johannes Plenio on Pexels.com

Wizard of Oz 

One of the studies I conducted at IBM Research in the mid 1970’s was part of an effort to do “Automatic Programming” — a department under Pat Goldberg. The first level manager I worked with was Irving Wladawsky (later Irving Wladawsky-Berger). His group wanted to develop a system that would allow the owner/operator of a small business to type requirements into a computer in English (or something English-like) and have the system itself produce RPG code to run the business so described. 

The underlying motivation from an IBM business perspective was that many small businesses could well afford a computer to do inventory, fulfill orders, etc. but they couldn’t afford to hire programmers to create such a system from scratch. The small business owner in the mid-1970’s did not program! Yet, for the most part, they understood how their business worked. The notion was that a natural language understanding and generation program could dialogue with the user/owner and through that process, understand their “business rules.” No costly programmers needed!

Photo by Dmitry Demidov on Pexels.com



An interesting side note: at that time, we were told that IBM corporate forbade us to use the terms “Artificial Intelligence” or “Robotics” to describe our work because some PR firm had determined that these terms were too scary for the general public. So, IBM had research in “mechanical assembly” but not “robotics.” We had work in character recognition, speech recognition, handwriting recognition, automatic program generation, and compiler optimization. But no work in “Artificial Intelligence.” (Wink, wink, nod, nod). 

Labelism: Confusing a thing with the label for that thing.

Another interesting side note: I worked at IBM Research for a dozen years; started an AI lab at NYNEX where I worked another 13 years; came back to IBM Research and several years later found myself working on the same problem! We were still trying to make a system to allow small businesses to generate their code automatically. In my second iteration, rather than using natural language, we were trying to make the specification of business rules in a graph language that was intuitive enough for business owners. This was a different approach, but trying to address the same underlying desire: to bring computing to small business without incurring the heavy costs of programming and maintenance. 

Let’s return to iteration one — the natural language approach @ 1975. Well, one issue was that no-one had a natural language program that even approximated being able to do the job. So…how to study people’s interaction with a system that doesn’t exist? 

We used an approach that my colleague Jeff Kelly called the “Wizard of Oz” technique; viz., use a human being (in this case, me) to simulate how the system might work and record people’s behavior. In this way, we could discover many of the issues that such a natural language programming system would have to deal with. I had already had plenty of experience interacting with a computer; and I had acting experience. I could “play the part” of a computer fairly well as I typed in my questions and answers. 

(Description of “The Wizard of Oz” technique).

IBM Research in Yorktown had roughly a thousand people including not only scientists, programmers, and engineers but also a number of business people (who did not know how to program). I knew some of them from playing tennis and table tennis and we used those folks as initial subjects. What did I find? Good news and bad news. 

Dealing with natural language is tricky for many reasons. One of those reasons is that English, including the English that people normally use to describe their business, is filled with words that have multiple meanings; e.g., “file”, “run”, “program”, “object”, “table”, etc. But here is the good news: although it’s true that many English words have many meanings, when these business people described business procedures, almost all of the lexical ambiguity vanished! The program to understand business English would not have to distinguish between a business file and a nail file; it wouldn’t have to worry about distinguishing a run in baseball or a run in stockings from a run of the payroll program; it wouldn’t have to distinguish between the table in a relational data base and the table in your dining room. The domain would mainly constrain! That’s the good news.

The bad news was dialogue management. How can the machine recognize a misunderstanding and how can it correct it? To make matters worse, while business people were fairly consistent in the way they described how their business ran, they were not consistent in how they talked about the communication. If a human being senses that another one is misunderstanding, then, depending on context they might: raise their eyebrows, say “Huh?”, “Come again?”, “What?” “I think I lost you.” “WTF?” “Are you kidding?”, “We’re on different wavelengths,” “I don’t get it.” “But…wait.” 

Photo by Nafis Abman on Pexels.com

Sometimes, these are referred to as “meta-comments.” Here’s a simple example that took place in the study. 

One of the business people told me about various discounts. I had assumed (playing the part of the computer) that he was talking about discounts for items that were being discounted due to inventory management. I recorded all the various percentages and so on. Then, he said, “Now, we also give discounts for various items.” 

At that time, most natural language systems of that era simply ignored words like “now” and “also” in this context. Stepping out of my role as a “computer system” and thinking about from the perspective of a human conversational partner though, these words are crucial! What it signals is a change in topic. In the larger context of our conversation, it shows that everything that had just been said, which I thought had been about item discounts, was not about item discounts!

This is just one example, but there were many more. In my more recent experience interacting with various computer dialogue systems, being able to recognize the signals of miscommunication and being able to repair misunderstandings is still not very well-handled more than four decades later.

I’d be interested in any pointers you have to a system that you think deals with meta-communication in a natural and robust manner. I do not think that it is beyond the pale of possibility. The general categories of the ways that people misunderstand each other is not infinite. John Anderson developed excellent tutoring systems for LISP and geometry and those systems worked something like human tutors in that, the tutor inferred the mental model of an individual student and focused instruction on correcting any misconceptions. My intuition is that a generic system built with equal complexity could deal with most of the issues as well as the average human being deals with them; i.e., imperfectly. 

—————————————

Lessons Learned: #1 You can test aspects of a system even before it’s built or even completely defined. One method that has been used many times: “Wizard of Oz.” 

Lessons Learned #2: Language used by professionals to talk about their domain is much more constrained in terms of lexical ambiguity than is language when considered by all native speakers.

Lessons Learned #3: People in “our culture” (i.e., US business culture) do not have an agreed upon and consistent vocabulary for talking about communication nor a consistent process for dealing with them.

Lessons Learned #4: Speaking of communication errors, I don’t recall why, but it was about this time, that I realized that my notion about how research results would be transferred to other parts of IBM was a complete and utter fantasy. I hadn’t articulated it, but it was basically that I would do research, write the results up for publication in scientific journals for an academic audience and publish Research Reports which would be eagerly consumed by anyone who needed to know. I’m not proud of this. LOL. But that’s really kind of how I viewed it. And, then, after a few years, I realized that it really mainly came about through relationships. That was something that people had been showing me all my life, but which I don’t think anyone ever stated it explicitly enough.

Update for 2026: While the four “Lessons Learned” above still seem apropos, some of today’s chatbots such as ChatGPT and Claude are much better at dealing with connected conversations with humans that were the systems of the twentieth century. Not only that, people are now describing systems in “natural language” and the computer is writing code. That’s the “good news” I suppose.

The bad news? While my impression of most of the AI researchers of the twentieth century is that they were largely motivated by intellectual challenges and a desire to help make people more productive, I get the impression that most of the AI work of today is controlled by people who are already astoundingly wealthy and want to become even wealthier. And, as UN-laudable as we may view that goal, the wealth is only a means to an end and that end is the total enslavement of most of humanity. Even being a trillionaire isn’t enough.

That’s not to say that all the workers advancing AI have those nefarious aims just because those in charge do, but as the surveillance state becomes more pervasive, their private motivations could have less influence over the outcomes.

———————————-

Author Page on Amazon

The Myths of the Veritas (an exploration of leadership & ethics in free, no ads fiction)

Index to a Pattern Language for Collaboration and Teamwork

Experiences in Human-Computer Interaction

Post on “The Story of Story” 

The After Times

After All

When Greed is the only Creed

Destroying Natural Intelligence

“Turing’s Nightmares” comprises 23 Sci-Fi short stories that explore the implications and ethics of AI

Here is an example chapter from “Turing’s Nightmares” that explores a possible dilemma of working in AI.

To Be or Not To Be

Tools of Thought

14 Sunday Dec 2025

Posted by petersironwood in AI, creativity, design rationale, management, psychology, science, Uncategorized

≈ 6 Comments

Tags

AI, chatgpt, index, life, problem formulation, problem framing, problem solving, sense-making, summary, technology, thinking, tools of thought, writing

Tools of Thought (Summary and Index)

In December, 2018, I began writing a series of essays on “tools of thought.” I realize that many readers probably read these tools at the time they were first published. However, in times of great division such as those we now face, effective thinking is more important than ever yet every day in the news and in social media, I see many examples that overlook even the most basic tools of thought. I therefore decided that it would be worthwhile to reprint the index of such tools now.

I suppose many readers will already be familiar with many of these tools. Nonetheless, I think it’s worthwhile to have a compilation of tools. After all — plumbers, carpenters, programmers, piano tuners, sales people — they all have tool kits. I see at least three advantages to having them together in some one place.

Without a toolkit you may be prone to try to use the tool that just so happens to be nearest to hand at the time you encounter the problem. You need to tighten a screw and you happen to have a penny in your pocket. You don’t feel like walking all the way down into the garage to get your toolkit. A penny will do. I get it. But for more serious work, you are going to want to consider the whole toolkit and choose the tool that’s most appropriate to the situation at hand.

First, then, the existence of a toolkit serves as a reminder of all the tools at your disposal. This will help you choose appropriately. 

Second, you may only be familiar with one or two ways to use a tool. I may have thought of ways to use a tool that are different from the way you use it. In the same way, you undoubtedly know useful things about these tools of thought that I have never thought of. We can learn from each other. Readers are more than welcome to comment on uses, misuses, and variations.

Third, having all the tools together may stimulate people to invent new tools or see a way to use two or more in sequence and begin to think about the handoff between two tools. 

Here’s an index to the toolkit so far.

Many Paths(December 5, 2018). The temptation is great to jump to a conclusion, snap up the first shiny object that looks like bait and charge ahead! After all, “he who hesitates is lost!” But there is also, “look before you leap.” What works best for me in many circumstances is to think of many possible paths before deciding on one. This is a cousin to the Pattern: Iroquois Rule of Six. This heuristic is a little broader and is sometimes called “Alternatives Thinking.”

Many Paths

And then what?(Dec. 6, 2018). This is sometimes called “Consequential Thinking.” The idea is simple: think not just about how you’ll feel and how a decision will affect you this moment but what will happen next. How will others react? It’s pretty easy to break laws if you set your mind to it. But what are the likely consequences?

And, then what?

Positive Feedback Loops(December 7, 2018). Also known as a virtuous or vicious circle. If you drink too much of a depressant drug (e.g., alcohol or opioids), that can cause increased nervousness and anxiety which leads you to want more of the drug. Unfortunately, it also makes your body more tolerant of the drug so you need more to feel the same relief. So, you take more but this makes you even more irritable when it wears off.

Systems Thinking: Positive Feedback Loops

Meta-Cognition.(December 8, 2018). This is basically thinking about thinking. For example, if you are especially good at math, then you tend to do well in math! Over time, if your meta-cognition is accurate, you will know that you are good in math and you can use that information about your own cognition to make decisions about the education you choose, your job, your methods of representing and solving problems and so on.

Meta-Cognition

Theory of Mind(December 9, 2018). Theory of Mind tasks require us to imagine the state of another mind. It is slightly different from empathy, but a close cousin. Good mystery writers – and good generals – may be particularly skilled at knowing what someone else knows, infers, thinks, feels and therefore, how they are likely to act.

Theory of Mind

Regression to the Mean(December 10, 2018). This refers to a statistical artifact that you sometimes need to watch out for. If you choose to work with the “best” or “worst” or “strongest” or “weakest” and then measure them again later, their extreme scores will be less extreme. The tool is to make sure that you don’t make untoward inferences from that change in the results of the measurement.

Regression to the Mean

Representation(December 11, 2018): The way we represent a problem can make a huge difference in how easy it is to solve it. Of course, we all know this, and yet, it is easy to fall into the potential trap of always using the same representations for the same types of problems. Sometimes, another representation can lead you to completely different – and better – solutions.

 Representation 

Metaphor I (December 12, 2018): Do we make a conscious choice about the metaphors we use? How can metaphors influence behavior?

Metaphors We Live By and Die By

Metaphor II (December 13, 2018): Two worked examples: Disease is an Enemy and Politics is War.

Metaphors We Live and Die By: Part 2

Imagination (December 14, 2018): All children show imagination. Many adults mainly see it as a tool for increasing their misery; viz., by only imagining the worst. Instead of a tool to help them explore, it becomes a “tool” to keep themselves from exploring by making everything outside the habitual path look scary.

Imagination

Fraught Framing (December 16, 2018): Often, how we frame a problem is the most crucial step in solving it. In this essay, several cases are examined in which people presume a zero-sum game when it certainly need not be.

Fraught Framing: The Virulent “Versus” Virus

Fraught Framing II(December 17, 2018). A continuation of thinking about framing. This essay focuses on how easy it sometimes is to confuse the current state of something with its unalterable essence or nature. 

Fraught Framing: The Presumed Being-ness of State-ness

Negative Space(December 17, 2018). Negative space is the space between. Often we separate a situation into foreground and background, or into objects and field, or into assumptions and solution space. What if we reverse these designations?

Negative Space

Problem Finding(December 18, 2018). Most often in our education, we are handed problems and told to solve them. In real life, success is as much about being able to find problems or see problems in order to realize that there is even something to fix.

Problem Finding

More recently, I wrote a series of posts about the importance of Problem Finding, Problem Framing, and Problem Formulation. I haven’t yet put this in the form of “Tools of Thought” — these posts are specific experiences from my own life where I initially mis-formulated a problem or watched my friends do that. 

The Doorbell’s Ringing! Can you get it?
Reframing the Problem: Paperwork & Working Paper
Problem Framing: Good Point!
I Say: Hello! You Say: “What City Please?”
I Went in Seeking Clarity
Problem Formulation: Who Knows What?
Wordless Perfection
How to Frame Your Own Hamster Wheel
Measure for Measure
The Slow-Seeming Snapping Turtle
A Long Day’s Journey into Hangover
Training Your Professor for Fun & Profit
Astronomy Lesson: Invisible Circles
Tag! You’re it!
Ohayōgozaimasu
Career Advice from Polonius

——————————-

Author Page on Amazon

pastedGraphic.png

Photo by Pixabay on Pexels.com

Non-Linearity. (December 20, 2018). We often think that things are linear when they may not be. In some cases, they can be severely non-linear. Increasing the force on a joint may actually make it stronger. But if increased force is added too quickly, rather than strengthening the joint even further, it can destroy it. The same is true of a system like American democracy.

Non-Linearity

Resonance. (December 20, 2018). If you add your effort to something at the right time, you are able to multiply the impact of your effort. This is true in sports, in music, and in social change.

pastedGraphic_1.png

Photo by Kaboompics .com on Pexels.com

Resonance

Symmetry(December 23, 2018). There are many kinds of symmetry and symmetry is found in many places; it is rampant in nature, but humans in all different cultures also use symmetry. It exists at macro scales and micro scales. It exists in physical reality and in social relationships.

Symmetry

Other posts that are related to various mental errors you might want to avoid.

Labelism

Wednesday

The Stopping Rule

Finding the Mustard

What about the Butter Dish?

Where does your Loyalty Lie?

Roar, Ocean, Roar

The Update Problem

The Invisibility Cloak of Habit

The Impossible

Your Cage is Unlocked

We won the war! We won the war!

The self-made man

Wordless Perfection

11 Thursday Dec 2025

Posted by petersironwood in AI, creativity, HCI, psychology, sports, Uncategorized, user experience

≈ 1 Comment

Tags

AI, art, creativity, drawing, education, intuition, life, problem formulation, Representation, Right-brain, sports, thinking, writing

————————————

Sirius Black

I like to write. In fact, I like to write so much that I wrote before I could even read. When my early crayon “writings” in my grandfather’s books were discovered, instead of praise, I was spanked. I’m not even sure they really tried hard to read my learned annotations. Their missing the point didn’t deter me though. I like words! I like writing poetry, essays, stories, plays, and even novels. Words help human beings communicate and collaborate. However…

In this essay, I’d like to mention some instances of wordless success.

Photo by lascot studio on Pexels.com


In the neighborhood where I grew up, we spent most of the summer playing baseball, basketball, and football. I had never played golf nor paid much attention to it as a kid and when it came on TV I walked by with hardly a glance. At that point in my life, I deigned to consider something a sport only if there were a good chance to smash into one of the other players. I had never touched a golf club or a golf ball until one summer day when I was about ten, one of the kids brought one of his uncle’s golf clubs to our baseball field along with a tee and a golf ball. He demonstrated how to hit the ball and showed us how to put our hands on the club. Kids took turns hitting the ball and retrieving it for another go. 

When it came to my turn, I mainly remember just loving the shiny wood of the club. I loved wooden baseball bats back then, but the driver!! Wow! That was in a whole different category of cool. You didn’t need to be an adult or a golfer to know that! It shone opalesquely. I teed up the golf ball, and swung the unfamiliar and impossibly long club.

The resulting sound – exquisite. An explosion. A rifle shot. A cousin of the crack of a home run shot into the upper deck. But more penetrating. More elegant. More poignant.

We all looked up in amazement. My golf shot started low and straight. Then it rose and rose and disappeared far beyond the dirt road that marked the outer limit of our makeshift baseball field. It rose over the hill beyond the road and disappeared into the field beyond. There was no hope of retrieving the golfball. None of us even suggested trying. My shot was wordless perfection. 



Fast forward to graduate school. In the summer afternoons, I got into the habit of playing frisbee with the neighbors. One day, I parked my car and ran into the back yard. One of my neighbors spied me and threw me the frisbee, I noticed that they had placed an empty beer can atop a utility box about a hundred feet away. I caught the frisbee on the run and threw it with the next step. The frisbee sailed with a nice arc and smacked the beer can right off. My neighbors said that they had been trying to knock that beer can off for about a half hour.  My throw was wordless perfection.

Photo by Brixiv on Pexels.com

Meanwhile, at the University of Michigan, several of my friends and classmates liked puzzles as much as I did. One such puzzle consisted of a triangular “board” with a regular pattern of holes. There were pegs in every hole save one. The goal was to “jump” pegs much as one does in checkers and then remove that peg from the board. Eventually, one was supposed to end up with one and only one peg. I worked on it for awhile and thought about various strategies and moves. I couldn’t seem to solve it. My phone rang. I picked it up and conversed with my friend. Meanwhile, I toyed with the puzzle while my “mind” was on the conversation. I toyed with the puzzle and solved it. Wordless perfection.

A few months or weeks later, my officemates and I worked on another puzzle. This one consisted of four cubes (aka “instant insanity”). Each cube had a different arrangement of colors. The goal was to arrange the cubes so that every “row” of faces had four different colors. I fiddled with the puzzle trying out various strategies and noting various symmetries and asymmetries. Once again, someone called and interrupted my musings. Again, I idly fiddled around with the cubes while talking on the phone. And solved it. Wordless perfection strikes again! 

https://en.wikipedia.org/wiki/Instant_Insanity

Fast forward four decades. For best results, borrow Hermione’s time-turner. Otherwise, you’ll have to rely on your imagination. 

Betty Edwards (“Drawing on the Right Side of the Brain”) gave a plenary address at one of the Association of Computing Machinery’s premier conferences: CHI. Among other things, she showed example after example of how much people improved in their drawing skills based on her methods. A few months later, it so happened that my wife and I had an opportunity to go to one of her five day classes. 

I would have to honestly say, that course was one of the best educational experiences of my life. It was an immensely pleasurable experience in and of itself. Beyond that, the results in terms of improved drawing skills were dramatic. And, as if that were not enough, I looked at the world differently. I noticed visual things about the environment that I had never seen before. 

The essence of the method Betty Edwards uses is to get you to observe and draw — while “shutting up” or “turning off” the part of your brain (or mind) that talks and plans and categorizes. In one exercise, for instance, we took a line drawing and turned it upside down. Then, we copied that image onto our pad of paper by carefully observing and drawing what we saw. She also instructed us not to try to “guess” what they were drawing, but just to copy the lines. When every line had been copied, we turned the drawings right side up again. The result jolted me! I had created an excellent likeness of the original. So had everyone else in class. The quality stunned me. Wordless Perfection.

There’s a larger lesson here, too. 

I had within me, the capacity to make a very decent copy of a drawing, but had never achieved that result for 60 years. All it took was five minutes of instruction to enable me to achieve that. 

What else is like that? Imagine that we have, not just one, but a dozen or even a dozen dozen “hidden talents.” Some of them, like drawing, may depend more on Not-Doing than on Doing; on Being rather than Achieving.

There was a longer lasting side-effect of the drawing course. My day to day life, as is typical of most achievement-driven people had been very much “goal-driven” and there was always an ongoing plan and dialogue. After having learned to turn that off in order to draw, I can also turn it off in order to see, whether or not I draw. Seeing (or otherwise sensing or feeling) in the moment also makes me much less judgmental. If you decide to think about the physical appearance of people in terms of how interesting they would be to draw, you end up with an entirely different way of thinking about people’s appearance. 

What are your hidden talents? 

——————————————

The Invisibility Cloak of Habit 

Big Zig-Zag Canyon 

The Great Race to the Finish!

You Fool!

Horizons University

How the Nightingale Learned to Sing

Comes the Dawn

Dog Trainers

Where Does Your Loyalty Lie?

The Dance of Billions

Roar, Ocean, Roar

Imagine All the People

Your Cage is Unlocked

Author Page on Amazon

I Went in Seeking Clarity

10 Wednesday Dec 2025

Posted by petersironwood in AI, creativity, HCI, psychology, Uncategorized, user experience

≈ 1 Comment

Tags

AI, Artificial Intelligence, coding, parallel programming, problem formulation, problem framing, problem solving, programming, technology, thinking, tools, X10

“I stopped by the bar at 3 A.M.
To seek solace in a bottle or possibly a friend
And I woke up with a headache like my head against a board
Twice as cloudy as I’d been the night before
And I went in seeking clarity” — Lyrics from The Indigo Girls: Closer to Fine

If you think programming is cognitively difficult, try parallel programming. It is generally harder to design, to code, and to debug than its sequential cousin. One of the fun projects I worked on at IBM Research was on the X10 language which was designed to enable parallel programmers to be more productive. Among other things, I fostered community among X10 programmers and used analytic techniques to show that X10 “should be” more productive. Although these analytic techniques are very useful, we also wanted to get some empirical data that the language was, in actuality, more productive. 


Photo by Dominika Greguu0161ovu00e1 on Pexels.com


One part of those empirical studies involved comparing people doing a few parallel programming tasks in X10 to those using a popular competitor. But, like many other “chicken and egg” problems, there were no X10 programmers (other than the inventors and their colleagues). I was part of a team who travelled to Rice University in Houston. The design called for one group to spend a chunk of time learning X10 (perhaps half a day) and another chunk of time coding some problems.

Besides the three behavioral scientists like me who were there to make observations, there were also three high-powered Ph.D. computer scientists present who would teach the language. Programmers tend to be very smart. Parallel programmers tend to be very very smart. People who can invent better languages to do parallel programming? You do the math.



Anyway, after the volunteers students had arrived, one of the main designers of the language began to “teach them” X10. 

But — there was a problem. 

The powerpoint presentation designed to teach the students X10 was far too blurry to read!

Immediately, the three computer scientists tried to issue commands to the projector to put the images in focus. Nothing worked. The three of them began a fascinating problem solving conversation. The conversation concerned what communication protocol(s) among the PC, the projector, and the controller was the likely source of the problem. I suppose it might not have been fascinating to everyone, but it was to me. First, it fascinated me because I was learning something about computer science and communication protocols. Second, it fascinated me because I loved to watch these people think. I suppose many of the advanced computer science students who were in this classroom to learn X10 also found it interesting. Third, I found it fascinating because my dissertation was about human problem solving and I’ve been interested in it ever since.

But the study itself had completely stalled. 

After a few minutes of fascinating conversation that did nothing to focus the images, something possessed me to walk over to the projector and turn the lens by hand. The images were immediately clear and the rest of the experiment continued. 

The three computer scientists had “framed” the problem as a computer science problem and I found the discussion that sprang from that framing to be fascinating. But one of the part-time jobs I had had as an undergraduate was as a “projectionist” at Case-Western, and it was that experience that allowed me to try framing the problem differently. All of us have huge reservoirs of experience outside of our professional “training” and those experiences can sometimes be important sources of alternative ways to frame a problem, issue, or situation.

———————————-

Essays on America: Wednesday 

Essays on America: The Update Problem 

Essays on America: The Stopping Rule

The Invisibility Cloak of Habit

Labelism

Tools of Thought

Where Does Your Loyalty Lie?

Stoned Soup

The First Ring of Empathy

Travels with Sadie: Teamwork

Author Page on Amazon

   

I Say: Hello! You Say: “What City Please?”

09 Tuesday Dec 2025

Posted by petersironwood in AI, creativity, design rationale, HCI, management, psychology, Uncategorized, user experience

≈ 1 Comment

Tags

art, communication, conversation, Design, efficiency, HCI, human factors, photography, primacy, problem framing, problem solving, sensemaking, technology, thinking, UX

Photo by Tetyana Kovyrina on Pexels.com

In the not so distant past, people would often call directory assistance operators. These operators would find a number for you. For an additional charge, they would dial it for you. In fact, this was a very commonly used system. Phone companies would have large rooms filled with such operators who worked very hard and very politely, communicating with what was often a hostile and irrational public. 

Photo by Moose Photos on Pexels.c

Customer: “I have to get the number of that bowling alley right near where the A&P used to be before they moved into that new shopping center.”

Operator: “Sir, you haven’t told me what town you’re in. Anyway…”

Customer: “What town?! Why I’m right here in Woburn where I’ve always been!” 

Photo by Johannes Plenio on Pexels.com

There were so many operators that the phone companies wanted their processes to be efficient. Operators were trained to be friendly and genial but not chatty. The phone companies searched for better keyboards and better screen layouts to shave a second here or there off the average time it took to handle a call. 

There are some interesting stories in that attempt but that we will save for another article, but here I want to tell you what made the largest single impact on the average time per call. Not a keyboard. Not a display. Not an AI system. 

It was simply changing the greeting. 

Photo by eberhard grossgasteiger on Pexels.com

Operators were saying something like: “New England Telephone. How can I help you?” 

After our intervention, operators instead said, “What city please?” It’s shorter and it’s takes less time to say. But the big change was not in how long the operator took to ask the question. The biggest savings was how this change in greeting impacted the customer’s behavior. 

When the operator begins with “How can I help you?” the customer, or at least some fraction of them, are put into a frame of mind of a conversation. They might respond thusly:

“Oh, well, you know my niece is getting married! Yeah! In just a month, and she still hasn’t shopped for a dress! Can you believe it? So, I need the number for that — if it were up to me, I would go traditional, but my niece? She’s — she’s going avant-garde so I need the number of that dress shop on Main Street here in Arlington.” 

Photo by Tuu1ea5n Kiu1ec7t Jr. on Pexels.com

With the “What City Please?” greeting, the customer was apparently put into a more businesslike frame of mind and answers more succinctly. They now understand their role as proving information in a joint problem solving task with the operator. A typical answer would now be:

“Arlington.” 

“In Arlington, what listing?” 

“Dress shop on Main Street.”

The way in which a conversation begins signals what type of conversation it is to be. We know this intuitively. Suppose you walked up to an old friend and they begin with: “Name?” You would be taken aback. On the other hand, suppose you walk up to the line at the DMV and the clerk says, “Hey, have you seen that latest blog post by J. Charles Thomas on problem framing?” You would be equally perplexed! 

Conversation can be thought of partly as a kind of mutual problem solving exercise. And, before that problem solving even begins, one party or the other will tend to “frame” the conversation. That framing can be incredibly important. 

Even the very first words can cause someone to frame what kind of a conversation this is meant to be.

Words matter.

The Primacy Effect and The Destroyer’s Advantage

https://petersironwood.com/2018/02/13/context-setting-entrance/

Essays on America: Wednesday

After the Fall

The Crows and Me

Cancer Always Loses in the End

Come Back to the Light

Imagine All the People…

Roar, Ocean, Roar

The Dance of Billions

How the Nightingale Learned to Sing

Travels with Sadie

The First Ring of Empathy

Donnie Visits Granny!

You Must Remember This

The Walkabout Diaries: Bee Wise

Author Page on Amazon 

Problem Framing: Good Point!

08 Monday Dec 2025

Posted by petersironwood in AI, America, design rationale, HCI, management, psychology, story, Uncategorized, user experience

≈ Leave a comment

Tags

AI, art, life, politics, problem finding, problem formulation, problem framing, problem solving, technology, thinking, tools, USA

Photo by Pixabay on Pexels.com

You have probably heard variations on this old saw, “To a hammer, everything looks like a nail.” I’ve also heard, “If you have a hammer, everything looks like a nail.” There is also this popular anecdote:

One night, I took my dog out for a walk and I noticed one of my neighbors under a nearby street lamp crawling around on his hands and knees, apparently looking for something. I walked over and asked, “What are you looking for?”

Photo by Photo:N on Pexels.com



“My car keys!” He replied.

I have pretty good vision, so I helped him. I didn’t see any car keys so after a minute or so I asked, “Where exactly did you lose your keys?” 

He stood up, cracked his back, and pointed back to a nearby park. “Over there.”

“Over there?! Then, why are you looking under the street lamp? Why aren’t you looking over at the park entrance?”

“Oh, that’s obvious! The light is so much better here!” 

For a time, I had to very interesting and challenging job in the mid 1980’s at IBM Headquarters to try to get the company to pay more attention to the usability of their products and services. As a part of this, I visited IBM locations throughout the world. At one fabrication plant, our tour guide took us by an inspection station. This was not an inspection statement for chips. It consisted of one person whose job was to look through a microscope and make sure that two silver needles were perfectly aligned.

After we left the station, our tour guide confided that they were strongly considering replacing the person with a machine vision system. The anticipated cost would be substantial, but they hypothesized that the system would be more accurate and faster. It was, our host, insisted, just the nature of humans to be slow and inaccurate.

Maybe. 

When I looked at the inspection station however, with my background in human factors, I had a completely different impression of the situation. The inspector sat on a fixed height stool and had to bend his neck at an absurd angle to look into the microscope. He was trying to align these silver needles against a background that had almost the same hue, brightness and saturation. 

Photo by Wesley Carvalho on Pexels.com

Other than blindfolding the man, I’m not sure what they could have done to make the task more unnecessarily difficult. I suggested, and eventually, they implemented, a few inexpensive ergonomic changes and time and accuracy improved.

Like other companies in the technology segment, IBM often saw problems as ones that could be solved by technology. At that time, technology systems was their main business. Since then, they have expanded more fully into software and services. In fact, those services now include experience design.

If you find yourself enamored of technology in general, or some specific class of technology such as machine vision, speech recognition, or machine learning, you might overlook much simpler and cheaper ways to solve problems or ameliorate situations. Of course, you might lose some revenue doing that, but you can also win long term customer loyalty. 

Even if you are a hammer, everything is not a nail. 

That applies as well to User Experience. You might design the most wonderful UX imaginable for a particular product or service. But if it is shoddily made so that it is error prone; if it lacks important functionality; if the sales force is inept; or if service is horrible, those failures can completely overwhelm all the good work you have done on the UX. Because of the nature of UX, you might learn important knowledge or suggestions for other functions as well. It often requires finesse to have such suggestions taken seriously, but with some thought you can do it. 

During my second stint at IBM, I worked for a time in a field known at that time as “Knowledge Management.” One of our potential clients was a major Pharma company who felt that their researchers should do a better job of sharing knowledge across products. They wanted us to design a “knowledge management system” (by which they meant hardware and software) to improve knowledge sharing. 

Simply building a “Knowledge Management System” would be looking under the streetlamp. They knew how to specify a technology solution from IBM and have it installed.

However — they were unwilling to provide any additional space, time, or incentives for their employees to share knowledge with their colleagues!  

Photo by Chokniti Khongchum on Pexels.com

They were convinced that technology would be the silver bullet, the solution, the answer, the Holy Grail, the magic pill. They viewed technology as less disruptive than it would have been to change employee incentives, or space layout, or give them time to actually learn and use the technology system. 

This reaction to “knowledge management” was not unique. It was common.

To me, this seems very similar to the notion that health problems can all be solved with a magic pill. What do you think? 

—————————————

Since originally writing, we have had the spectacle of DOGE: Destroying Our Government’s Effectiveness under the excuse of making it “more efficient.” It might be (as I strongly suspect) that the destruction was quite intentional. It might be (as some think) that it was accidental. In either case, the result was predictable because the method was guaranteed not to work to actually make things more efficient. If you really wanted to do that, you would take the time to understand a system before trying to redesign it. You would identify all relevant stakeholders and get their input. You would not redesign a system using a gang of young hackers but instead use an interdisciplinary team of experienced experts. You would check out your redesign both with those who were doing the work and with at least one group who were not familiar but had similar experience. Then, on the basis of feedback, you would redesign. When you were sure that you had the design right, you would not then institute it everywhere but in one small trial installation.

There’s a pill for that. 

The Pandemic Anti-Academic.

What about the butter dish? 

The invisibility cloak of habit. 

Process re-engineering comes to Baseball

E-Fishiness in Government

Author Page on Amazon

← Older posts

Subscribe

  • Entries (RSS)
  • Comments (RSS)

Archives

  • October 2026
  • September 2026
  • August 2026
  • July 2026
  • June 2026
  • May 2026
  • April 2026
  • March 2026
  • February 2026
  • January 2026
  • December 2025
  • November 2025
  • October 2025
  • September 2025
  • August 2025
  • July 2025
  • June 2025
  • May 2025
  • April 2025
  • March 2025
  • February 2025
  • January 2025
  • December 2024
  • November 2024
  • October 2024
  • September 2024
  • July 2024
  • April 2024
  • March 2024
  • February 2024
  • January 2024
  • December 2023
  • August 2023
  • July 2023
  • May 2023
  • April 2023
  • March 2023
  • February 2023
  • January 2023
  • December 2022
  • November 2022
  • October 2022
  • September 2022
  • August 2022
  • July 2022
  • June 2022
  • May 2022
  • April 2022
  • March 2022
  • February 2022
  • January 2022
  • December 2021
  • November 2021
  • October 2021
  • September 2021
  • August 2021
  • July 2021
  • June 2021
  • May 2021
  • April 2021
  • March 2021
  • February 2021
  • January 2021
  • December 2020
  • November 2020
  • October 2020
  • September 2020
  • August 2020
  • July 2020
  • June 2020
  • May 2020
  • April 2020
  • March 2020
  • February 2020
  • January 2020
  • December 2019
  • November 2019
  • October 2019
  • September 2019
  • August 2019
  • July 2019
  • June 2019
  • May 2019
  • April 2019
  • March 2019
  • February 2019
  • January 2019
  • December 2018
  • November 2018
  • October 2018
  • September 2018
  • August 2018
  • July 2018
  • June 2018
  • May 2018
  • April 2018
  • March 2018
  • February 2018
  • January 2018
  • December 2017
  • November 2017
  • October 2017
  • September 2017
  • August 2017
  • July 2017
  • June 2017
  • May 2017
  • April 2017
  • March 2017
  • February 2017
  • January 2017
  • December 2016
  • November 2016
  • October 2016
  • September 2016
  • August 2016
  • July 2016
  • June 2016
  • May 2016
  • April 2016
  • March 2016
  • February 2016
  • January 2016
  • December 2015
  • November 2015
  • October 2015
  • September 2015
  • August 2015
  • May 2015
  • January 2015
  • July 2014
  • January 2014
  • December 2013
  • November 2013

Categories

  • AI
  • America
  • apocalypse
  • cats
  • COVID-19
  • creativity
  • design rationale
  • dogs
  • driverless cars
  • essay
    • guns
  • family
  • fantasy
  • fiction
  • HCI
  • health
  • leadership
  • love
  • management
  • nature
  • pets
  • poetry
  • politics
  • psychology
  • Sadie
  • satire
  • science
  • sports
  • story
  • The Singularity
  • Travel
  • Uncategorized
  • user experience
  • Veritas
  • Walkabout Diaries

Meta

  • Create account
  • Log in

Blog at WordPress.com.

  • Subscribe Subscribed
    petersironwood
    Join 653 other subscribers

    Have a WordPress.com account? Log in now.

  • petersironwood
    View site in Reader
    Manage subscriptionsSign upLog in
    Report this content
    Collapse this bar
Loading Comments...