Seed, Ground, Water, Light, Love

09 Sunday Aug 2026

Posted by petersironwood in creativity, design rationale, fantasy, fiction, leadership, love, management, politics, psychology, Uncategorized, Veritas

≈ Leave a comment

Tags

books, cooperation, council, Democracy, fiction, legend, life, myth, peace, politics, story, Veritas, war, writing

——————

After some delicate and delicious love-making with Shadow Walker, Many Paths decided to check on She Who Saved Many Lives. If she seemed well enough, it might also be good to see whether her mentor had any further wisdom to share about Many Path’s plan to gather all the tribes. Her goal was to bring about peace but she realized that in trying to accomplish that, she might trigger the evil things she hoped to avoid. Her tentative plan was therefore to gather as much wisdom as she might from many sources — but not to wait overlong. As the story goes, she thought to herself, if you waste the entire warm season deciding where to plant, you will starve in the season of great ice and snow.

Many Paths called out to her friend and mentor and received a surprisingly strong and cheery response. “Come in, Many Paths. Come in! I’ve been meaning to ask your advice about something. Do sit down. I will get you a cup of tea this time.”

Not for the first time, Many Paths wondered whether it was actually possible for She Who Saved Many Lives to see into her heart and mind. After serving them both a cup of spicebush tea, ever so slightly flavored with mint, She Who Saved Many Lives went to her work area and brought over two patches of weaving. She placed one on each knee of Many Paths. The older woman smiled and said, “It never fails to amaze me how strong a weave of reeds is! It’s so wonderful. Just as I hope our community is.”

“I have had that exact same though,” Many Paths replied. Then, she laughed and added, “Likely because you pointed that out to me before I was even old enough to remember.”

The Elder Shaman tilted her head and nodded ever so slightly. “Perhaps. But you have made so many wonderful discoveries. And, not only you but our entire tribe. That’s because you have been open to learning and seeing what is there. But enough of that. I did have a question for you. Which of these two do you think is better?”

Many Paths frowned. “Better for what? What are you making?”

She Who Saved Many Lives considered, “A basket to carry things.”

Many Paths nodded, “What things and how many? This weave has these stiffer switches to help support the weight. If you’re making a small bag to collect mint, for example, you wouldn’t have any need. If you’re making a large bag to collect apples, however, you would want the extra structuring support.”

Photo by Pierpaolo Riondato on Pexels.com

She Who Saved Many Lives nodded. “Yes, yes. It sounds obvious when you say it. I guess the fever must have addled my brain a bit. Anyway, thank you for reminding me. Soon, I will have to decide on what I want to use the bag for; then I will know which one is likely correct. Now, what did you want to ask my advice on?”

Many Paths took in a deep breath and slowly let it out. “I am quite sure I didn’t say anything about asking your advice.”

She Who Saved Many Lives nodded. “I think you’re right. Sometimes I confuse us.” She laughed. “I know it sounds crazy but any way, I will get back to my weaving — or at least deciding why I’m weaving and let you go about your business — unless, of course, there was something else you wanted to talk about.”

Many Paths chuckled. “As it turns out, I did want to ask your advice about something. You know I want to convene a — Let me ask you another question first. Are you going to teach me how to see into another person’s mind?”

She Who Saved Many Lives laughed surprisingly long. At last, she caught her breath and said, “Many Paths! You won all seven rings of empathy! Of course, you can see into others. Of course, you can never be perfect at it. But you already do it. I knew you were busy. Yet you came to see me. You probably wanted to see whether I was dead or not, but even your footsteps and the way you called out told me you had something else on your mind. In fact, whether you knew it or not, you assumed I was alive. There was no edge of anxious worry in your voice. It was friendly — but also a bit — plaintive. I knew you wanted something from me. Now, you can see I have very few possessions. I find that having too many things about is intolerably distracting and makes cleaning and finding much more difficult. I am not going to help you with any arduous physical task. What is left? You want to offer me the opportunity to share my experiences; that is a great gift. For once we die, what else is left? So, naturally, I am more than willing to try to see what grows from our discussion.”

Many Paths looked down and slowly shook her head. She realized that she could read people. She simply forgot sometimes to do it. If you really take the time to put yourself in their sandals, of course, you can make a good guess at what they’re thinking, she thought. Aloud, she said, “Yes. You’re right. So, I want to convene the tribes and I am wondering how, exactly, to go about it. How can I make sure it helps bring greater peace and doesn’t somehow spark off violence. Maybe it’s better not to try?”

She Who Saved Many Lives replied, “I can say that no-one has attempted to bring all the tribes we know about together — not in my lifetime or the lifetime of my mother or the lifetime of my mother’s mother. During that time, there have been many wars and other atrocities. People stealing other people’s children? Even in our own tribe, we had some who forgot they were not the Tree of Life but a small and temporary part of the Tree of Life. I judge it’s worth the attempt.”

Many Paths. “As to how…?”

She Who Saved Many Lives said, “What comes to mind for what you are trying to do is more akin to growing things than it is to making things. I am making a basket, and I will use it for a time. I don’t ever imagine that it will live forever any more than that I will or you, my dear. But if I know your heart correctly, you don’t want to make a thing, which will at some time break or dissolve. You want to make something grow for a hundred years, like a giant oak. Ideally, it would be an oak that would seed still more oaks when old mother oak also died.”

Many Paths nodded. She realized that her mentor had described her desires precisely even though she herself could not have articulated them so succinctly. “Yes, that’s exactly right.”

She Who Saved Many Lives nodded. “Let’s suppose then that you want to plant something so that it’s likely to grow. What do you need?”

“A seed. Fertile ground. Water. Sun. That’s it. Is there more? Love! It’s all more likely to grow with love.”

She Who Saved Many Lives nodded. “Yes. That’s it. I would start with the love. You already have that. Then, you need to know what seed. The seed determines what will grow though not exactly how. But you will need the ground, water, and sun so it can grow at all.”

Many Paths continued the thought stream. “If you know what the seed is, then, you know what kind of place to look for. You know whether you need to plant it in bright sunlight or in shade. You know whether it needs very fertile ground or if it can grow in dirt and rocks. And, you know whether it needs to be in very wet ground or if arid ground will do.”

“Yes,” Many Paths, “and it occurs to me, that you might choose a place with enough light first, because, you can make the ground more fertile and bring more water, if need be. But brining light is more difficult.” She Who Saved Many Paths sighed. “Once, apparently, we knew how to bring light as those which lit the tunnel that leads to the Veritas on the … on the other side of the mountain.”

“I do wonder, Old Mother, whether such light is strong enough to grow plants. And then, Shadow Walker used reflections of the sun, along with other captives, to escape from the City of the Z-Lotz. It seems too contrived and elaborate for growing plants, but … perhaps writing is a little like that when it comes to providing enough truth so that peace can grow. It allows you to bring the light of wisdom to places that are many days walk from where they started. More importantly, you can place the light in a different time as well. We have all learned so much from the books uncovered in the great library. But, as usual, you are right. We must determine what type of thing we want to grow. That decision will determine the type of seed. The type of seed will determine the proper material, sunshine, and water.”

Many Paths arose and began pacing around in the Old Leader’s shelter. “Of course, since the outcome could impact everyone, I need to know how everyone believes it should be. Or, at least, find out as much as they know about how they want it to be.”

She Who Saved Many Lives considered for a moment before answering. “Yes. I suspect some will have many ideas about that while others may not care that much. Nearly everyone wants peace. On other matters, there may be great differences.”

Many Paths sat back down. The two sat in a comfortable silence for a time. Many Paths rose at last and said, “Thank you for sharing your wisdom. I will look for some to walk with me a bit and contemplate the plants and their nature and try to see among them what it is that the people may be seeking. I’m glad you seem so much better.”

“As am I, Many Paths. You know, you give me much to live for.” She Who Saved Many Lives smiled and added, “But I do think I will lie down for a nap now. Though some time in the near future, I might accompany you on such a walk.”

Many Paths left and saw Shadow Walker coming toward her. From the look on his face, Many Paths judged he had some news. His smile broadened as he approached and he said, “Hello my love! Can we go for a bit of a walk?”

———————

Author Page on Amazon

Myths of the Veritas: The Orange Man

Myths of the Veritas: The Forgotten Field

Myths of the Veritas: The First Ring of Empathy

We won the war! We won the war!

Who won the war?

Somewhere a Bird Cries

How the Nightingale Learned to Sing

The Broken Times

The Silent Screams of Dead Mens Dreams

After All

When Greed is the Only Creed

A Pattern Language for Collaboration & Cooperation

Imagine All the People…

Roar, Ocean, Roar!

The Dance of Billions

Small Steps

“The Psychology of Design”

22 Wednesday Jul 2026

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

≈ Leave a comment

Tags

AI, creativity, Design, education, HCI, human factors, IBM, leadership, research, technology, UX

“The Psychology of Design”

I worked at IBM, all told, about 28 years. During that time, management put increasing pressure on us to make our work “relevant” to the business. In fact, the pressure was always there, even from the beginning. Over the years, however, we were “encouraged” to shorten evermore the time gap between doing the research and having the results of that research impact the bottom line. This was not an IBM-only phenomenon.

I was a researcher, not a politician, but it seemed to me that at the same time researchers in industrial labs were put under pressure to produce results that could be seen in terms of share price (and therefore payouts to executives in terms of stock options), academia was also experiencing more and more pressure to publish more studies more quickly — and to make sure “intellectual property” was protected to make sure the university could monetize your work. This was about the same time that, at least in America, increasing productivity and the wealth that sprung from that increased productivity stopped being shared between the workers and the owners.

In the late 1970’s, the “Behavioral Sciences” group at IBM Research began to study the “psychology of design.” For the first few months, this was an extremely pleasurable & productive group, due mainly to my colleagues. Over the next few blogs, I’ll focus on some specific techniques and methods that you may find useful in your own work.

In this short recounting though, I want to focus instead on some broader issues relevant to “technology transfer”, “leadership” and “management.” Even if you are or aspire to be an expert in UX or HCI or design, I assure you that these broader issues will impact you, your work and your career. I wouldn’t suggest becoming obsessed with them, but being aware of their potential impact could help you in your own work and career.

It is telling that, almost invariably, whenever I told someone inside IBM (or, for that matter, outside IBM) that I was studying the “psychology of design,” people responded by asking, “the design of what?” So, I would explain that we were interested in the generic processes of design and how to improve them. I would explain that we were interested in understanding, predicting, and controlling these processes to enable them to be more effective. I would explain that we could apply these findings to any kind of design: software design, hardware design, organizational design, and (see last post about IBM) communication design. I would explain that design was a quintessentially human activity. I would also explain that design was an incredibly leveraged activity to improve.

Looking back on it, I still think all these things are true. I also see that I missed the “signal” people were giving me that, while I thought of design as something that could be studied as a process, that most people did not think of it that way. To them, it was never the “psychology of design,” but only the design of something.

Don’t get me wrong. I agree that somewhat different skills are involved in designing a great advertising campaign, a great building, and a great application. I agree that different communities of practice treat various common issues differently. I still think it’s worth studying commonalities across domains. For one thing, we may find an excellent way of generating ideas, say, that the advertising community of practice uses that neither architects nor applications developers had ever tried. Or, vice versa.

My own academic background was in “Experimental Psychology.” We were forever doing experiments that we believed were about psychological processes that were thought to be invariant regardless of the domain. It was an axiom of our whole enterprise that studying memory for any one thing also shed light on how we remember every other thing. Similar studies looked at decision making or problem solving or multi-tasking. We came to understand that there were some interesting exceptions to being able to separate content from process. For instance, it is much easier to multi-task a spatial task and a verbal task than it is to multi-task two independent spatial tasks or two independent verbal tasks.

In our Behavioral Sciences lab, we used a spectrum of techniques to study “design” ranging from laboratory studies of toy problems, to observing people doing real-world design problems while thinking aloud. After about 3-4 months of very productive work, we were told that we had to make our work relevant to software development. That one domain should be the focus of our work. We were told that this command came from higher-ups in IBM. That might have been true, or perhaps partly true.

It might also be relevant that someone in our management chain might have been the recipient of a grant from ONR which was specifically focused on software development. So far as I can tell, nothing had been done on that grant. So, our past, present, and future work could have been co-opted to be “results” done under the auspices of the ONR grant.

In any case, regardless of the “reasons,” the group began to focus specifically on software design. In one study, we used IBM software experts as subjects. Each person was given information that was geared toward a specific transformation that occurred in software development. One person was presented with the description of a “situation” that included a number of “issues” and they were asked to write a requirements document. In real life, I would hope that this would be done in a dialogue (and, indeed, in other studies, we recorded such dialogues). Absent such dialogues, what we found was that different software experts — all from IBM research — and all given the same documentation about a set of problems generated vastly different problem statements and overall approaches.

In other parts of the study, other experts were variously given requirements documents and asked to do an overall, high level system design, or given a high level design and asked to design an algorithm, or given an algorithm and asked to code a section. There was always diversity but the initial phases showed the greatest diversity of behavior. The initial stage is also the one that can cause the most expensive errors. If you begin with a faulty set of requirements — a misreading about how to even go about the problem — then, the overall project is almost certain to incur schedule slip, cost overruns, or outright failure.

While the vital importance of the initial stages of design is true in software development, I would argue that it is likely also true for advertising campaigns, building designs — and even true for the design of research programs. We designed our research agenda under the assumption that we had a long time; that we were studying design processes independently of specific communities of practice or the nature of the problems people were attempting to address. We assumed that there was no “hidden agenda.” Although we believed we would eventually need to show some relevance to IBM business, we had no idea, when we began, that only relevance to software design would be “counted.”

—————-

Some of our studies on the “Psychology of Design.”

Carroll, J. and Thomas, J.C. (1982). Metaphor and the cognitive representation of computer systems. IEEE Transactions on Man, Systems, and Cybernetics., SMC-12 (2), pp. 107-116.

Thomas, J.C. and Carroll, J. (1981). Human factors in communication. IBM Systems Journal, 20 (2), pp. 237-263.

Thomas, J.C. (1980). The computer as an active communication medium. Invited paper, Association for Computational Linguistics, Philadelphia, June 1980. Proceedings of the 18th Annual Meeting of the Association for Computational Linguistics., pp. 83-86.

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.

Miller, L.A. and Thomas, J.C. (1977). Behavioral issues in the use of interactive systems: Part I. General issues. International Journal of Man-Machine Studies, 9 (5), pp. 509-536.

——————————

Blog posts about the importance of solving the “right” problem.

The Doorbell’s Ringing. Can you get it?

https://petersironwood.com/2021/01/13/reframing-the-problem-paperwork-working-paper/

Problem Framing. Good Point.

https://petersironwood.com/2021/01/16/i-say-hello-you-say-what-city-please/

Problem formulation: Who knows what.

How to frame your own hamster wheel.

The slow seeming snapping turtle.

Author Page on Amazon.

Walston & Felix Multiple Regression Study

17 Friday Jul 2026

Posted by petersironwood in creativity, design rationale, leadership, management, psychology, Uncategorized

≈ 1 Comment

Tags

art, books, development, HCI, IT, productivity, programming, regression, software, technology, UX, writing

As I mentioned recently, when I first arrived at IBM Research in the early 1970’s I began to work on Query By Example and other schemes to make it easier for non-programmers to interact productively but flexibly with computers. Some of the lessons learned have to do, not with my own work, but with the work of others.

At that time, some researchers labelled their work as “The Psychology of Programming.” There were many debates — and some studies — about structures, syntax, which language was better than others, etc. There were also lengthy discussions about the process that one should use for software development. Doing any kind of “controlled” experiment on large scale code development is prohibitively expensive. It is rare that a company is willing to have two independent teams build the same piece of software in order to learn which of two methods is “better.”

Of course, one such comparison would likely not prove much. It may be that one of the two teams had a “super-programmer” or an extremely good manager. Perhaps, flu broke out in one of the two teams. You would really need to study many more than two teams to properly and empirically study the impact of language, or syntax, or process. Doing reasonable-sized experiments would be far too costly and impractical. Our lab and others did do laboratory tasks in order to test one syntax variant against another and so on. The problems were generally quite small in order for the study to be practical. So, the applicability to real-world development projects was questionable.

Photo by Christina Morillo on Pexels.com

Walston & Felix (See below), on the other hand, were able to find data on a fair number of real-world projects and rather than try to control for languages, processes, etc., they did a multiple regression analysis based on what languages, methods, etc. real projects used and what the important predictors were of actual productivity.

Personally, I learned two lessons from their study.

Lessons Learned: #1 — Sometimes, when it comes to what matters in the real world, controlled laboratory experiments have to give way to other methods such as studying “natural experiments.” Despite the many issues with trying to interpret such findings, no-one will pay for massive controlled experiments that parametrically vary programming methods, programming languages, etc. while controlling for quality of management, experience, complexity of task, etc. Multiple regression studies and in-depth case studies; ethnographic studies; interviews: all of these can provide useful input.

Lessons Learned: #2 — The impact of the variables that our community of people were looking at in terms of syntax, structure, etc. were dwarfed by the impact of organizational variables. For example, Walston & Felix found that the complexity of the interface between the developers and the customers was extremely important.

DeMarco & Lister (See below) claim that, based on their decades of experience as consultants to the software development process, projects almost never fail for technical reasons; when they do fail, it’s almost always for organizational and management reasons.

That conclusion dovetails with my own experience. Many decades later, working for IBM in “knowledge management,” it was amazing how many companies wanted us to “solve” their knowledge management issues by building them a “system” for knowledge sharing.

But…

Management at the company would not provide:

Incentives to share knowledge

Space to share knowledge

Time to share knowledge

Or, commit any personnel to gathering, vetting, organizing, and promoting the knowledge repository.

So — knowledge sharing was something their workers were simply supposed to “do” knowledge sharing on top of everything else they were doing.

They did not want a computer system, IMHO; they wanted a magic system.

These experiences were part of my motivation for attempting to catalog “best practices” in collaboration and teamwork in the form of a Pattern Language. Christopher Alexander and his colleagues looked at “what worked” in various parts of the world when it came to architecture and city planning. What they did for architecture and city planning, I want to do for collaboration.

Naturally, merely creating a catalog is not sufficient. I need to have people who will read it, understand it, modify and improve it, and then promulgate it via actual use. For now, it’s free. Comments and critiques are always welcome.

—————-

C. E. Walston and C. P. Felix, “A method of Programming Measurement and Estimation,” IBM Systems Journal, vol. 16, no. 1, pp. 54–73, 1977.

https://en.wikipedia.org/wiki/Peopleware:_Productive_Projects_and_Teams

Thomas, J.(2008). Fun at work: Managing HCI from a Peopleware perspective. HCI Remixed. D. McDonald & T. Erickson (Eds.), Cambridge, MA: MIT Press.

——————-

Introduction to a Pattern Language for Collaboration and Teamwork

Index to a Pattern Language for Collaboration and Teamwork

Chain Saws Make the Best Hair Clippers

Author Page on Amazon

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.

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.”

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.)

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!

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.”

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

The Story of Story 4: Character

19 Monday Jan 2026

Posted by petersironwood in design rationale, fiction, story, Uncategorized

≈ Leave a comment

Tags

AI, creative-writing, fiction, life, politics, story, Storytelling, truth, user experience, writing, writing-tips

The Story of Story 4: Character

Character is revealed by choices under pressure. Character is one of the three main dimensions of story. Often people who write fiction — or developers who write “user stories” add details about the people in an effort to make their characters (or personas) more “interesting.” Adding irrelevant details in something as long as a novel might help the reader get a clearer image of the character. Even in a long novel though, it’s better to add details that relate to something else in the story. In something as short and “to the point” as a “user story” it is worse than pointless.

Consider these descriptive details:

“Jill had beautiful blue eyes.”

“Jill had beautiful brown eyes.”

“Jill had beautiful green eyes.”

So what?

It might be relevant to some stories. For example, if Jill were a slave on an antebellum plantation, her having blue eyes might relate to her mother being raped by a white overseer. Maybe Jill finds out and exacts revenge. In that case, her blue eyes might be meaningful. Or, in another story, Jack might insist on dating only blue-eyed blonds. That is part of his “ideal beauty.” Jack pursues Jill because of her striking blue eyes. He shares information all the time about his “conquests” with his best friend, Judy, a woman with black hair and dark eyes. If it’s a romantic comedy, we will know, long before Jack will, that he is falling in love with Judy. The physical characteristics of the women serve to reveal Jack’s true character, which turns out to be deeper than we at first surmised.

But suppose the story is about how someone might use an Uber app? Is it really going to matter what color her eyes are? Will it matter to someone playing a video game?

Irrelevant details only seek to distract the reader (or the developer). These details sometimes go by the title “characterization” rather than character. Character should be reserved for deeper things. Sometimes, characterization can be interesting in the way it contrasts with character. In Psych for instance, Sean Spencer pretends every week to be a psychic helping the Santa Barbara police. His aim is to get to the truth. But in the service of getting to the truth, and putting the bad folks in jail, he runs a scam where he pretends to be psychic.

In the James Bond movies, the character of James Bond is revealed by his choices under pressure. He will give up everything and anything in the service of his country. But on the surface, he seems like a playboy. He drinks martinis. Yet, he is highly disciplined. He wants things his way. Even in his instructions for his martini, his meticulous attention to detail comes out.

Spock, on Star Trek, plays a character who reminds us time and again about how “rational” he is and how he can control his emotions. Of course, what makes this interesting is precisely because he isn’t always rational and in fact, sometimes has more violent emotions than the humans he critiques for their emotionality.

fullsizeoutput_17ed

If “character is revealed by choices under pressure,” it’s also good to remember that character should be coherently related to setting and plot. Plot advances through conflicts. In The Sound of Music, for instance, Maria has an internal conflict. She wants to be “good” and “follow the rules” of the convent (and later those of the Captain’s household), but she likes joy and music and spontaneity. She also finds herself in love with the Captain. Conflict. She also has inter-personal conflicts with the authorities at the convent, with the children, with the Captain, and with the Countess. She also has conflicts with larger forces in the world – notably Nazism. None of these conflicts is random; they arise quite naturally from the setting that she’s in — and from her own character.

James Frey, in How to Write a Damned Good Novel, suggests a sequence of increasingly intimate reveals that helps the reader progressively care more and more about the character. First, you say something about the objective, external world that the character exists in. Second, you reveal what the character perceives and does about the situation. Then, you reveal how the character feels about what is happening. Finally, you let the reader “tune in” to the internal conflicts of the character by showing their internal dialogue. Consider:

“The snow began to fall. The wind began to howl. The “snow” morphed into sharp little knives of ice.”

“Joe began to shiver and pulled his coat tight about him, crossing his arms across his chest.”

“Damn it! I want to be in a nice warm bed. Grrr.”

“Why do I always let Sally talk me into these half-baked schemes?”

For me, this order “works” – I am now curious to see what this particular half-baked scheme is and what sort of power Sally has over Joe. Read the lines in the reverse order and it makes only a little sense. It also puts a greater memory load on the reader.

In some stories, character stays fairly constant and the world (and other people) change because of the character’s choices. In the “Hero Saves the World” plot, this is the main emphasis. In the “Growing Up” plot, on the other hand, the most important action is how the character “changes” over time. I put “changes” in quotes because sometimes the “change” is really that the character simply acknowledges their underlying character. For instance, in Sweet Home Alabama, Melanie never really stops being in love with her husband (or Alabama) but consciously, she claims to want a divorce and go back to NY to be a “success.” As always, character is revealed under pressure <spoiler alert> and she “forgets” to sign the divorce papers. In many of the best stories, the character changes (or saves) the world and the world also changes or matures the character. </spoiler alert>.

Photo by Pixabay on Pexels.com

This may all make sense when it applies to fiction, but how does it impact how we write stories in a business context? This is often tricky because in many business contexts, only the founder or CEO is even allowed to have character. Everyone else is basically supposed to behave the same way: put the company first; follow the rules; do a great job; work together cooperatively; be loyal to the company. As a result, official company stories are typically bland and two-dimensional. They are basically nothing more than procedures. “If this happens, do that.” Implicitly, this means, “If this happens, do that” regardless of your internal character.

If you’ve done an excellent job of observing and interviewing potential users of a product or service, you have hopefully discovered some interesting internal conflicts and some related aspects of character that can become a logical part of user journeys. Initially, your target user may be reluctant to use your product.

Users may be reluctant to use on-line banking, for instance, because of the possibility of hacking or fraud. If this is a genuine concern of 1% of your potential customers, you probably don’t want to make it a concern to the rest, unless it is something they really should worry about. On the other hand, if it’s a genuine concern of 99% of your potential customers, sweeping it under the rug won’t do. The user in your user stories can be portrayed with this concern including internal conflicts and then you can show them overcoming the concern, if and only if it really can be ameliorated through various actions like two-factor verification, password choices, etc. Telling a lie about how safe on-line banking is, will ultimately undo you no matter how well told the story is. But character and characterization of these users should be designed around conflicts that actually are relevant to the product or service.

“Mary had put all her life savings and all her energy into her small company. Her time had become gold. She was on a path to hire more people, but that took time. Now the bank was offering lower fees if she would switch to on-line banking. She had always wanted to be a soccer player but she knew she wasn’t coordinated enough.”

Photo by Lukas on Pexels.com

What?

Yes, that may be something that came out in an interview with a real Mary. And it may even be part of an interesting story. But not this story! The naturally occurring conflict here is Mary’s desire to be as efficient and cost-effective as possible — and yet also to be as safe as possible. Mary may initially see these in conflict, but you may have a legitimate way for her to avoid or rethink the conflict. Mary’s character might be made more intense by having her see her budding business as a legacy she wants eventually to hand off to her daughters. But it doesn’t really matter whether she has blue eyes or brown eyes. You could instead intensify Mary’s desires by making her a success-oriented second generation immigrant whose own parents spent countless hours of hard work so she could get through college. The family still cares about every dollar. It doesn’t matter whether she lives in a small flat in Brooklyn, Chicago, or LA. It does matter that she wasn’t gifted 10 million dollars to start a business by her billionaire parents who live in a mansion in Manhattan.

It doesn’t matter whether she likes her martinis shaken or stirred either, unless you are making the point, e.g., that she is a fanatic for having things her way and that your software allows more customization than does that of your competitors. In that case, you can introduce a detail that shows, rather than tells, this fact about her character.

When you think back about books, movies, or TV series you really “got into”, I’m willing to bet that, at least in many cases, it’s partly because of the characters. What makes a great character for you?

———————————

Author Page on Amazon.

If Only

It was in his Nature

The Orange Man

The Mango Mussolini

At Least he’s our Monster

Sadie the Sifter

The Con-Con Man’s Special Friend

A Query on Quislings

As Gold as it Gets

Stoned Soup

How the Nightingale Learned to Sing

What a teeny man

Donnie Boy Plays Captain Man

Donnie Boy Lets his Brother Take the Fall

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

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.

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

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

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.

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!”

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

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?”

“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.

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

Reframing the Problem: Paperwork & Working Paper

04 Thursday Dec 2025

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

≈ Leave a comment

Tags

AI, ethics, leadership, life, philosophy, politics, problem finding, problem formulation, problem framing, problem solving, thinking, truth

Reframing the Problem: Paperwork & Working Paper

This is the second in a series about the importance of correctly framing a problem. Generally, at least in formal American education, the teacher gives you a problem. Not only that, if you are in Algebra class, you know the answer will be an answer based in Algebra. If you are in art class, you’re expected to paint a picture. If you painted a picture in Algebra class, or wrote down a formula in Art Class, they would send you to the principal for punishment. But in real life, how a problem is presented may actually be far from the most elegant solution to the real problem.

Doing a google search on “problem solving” just now yielded 208 million results. Entering “problem framing” only had 182 thousand. A thousand times as much emphasis on problem solving as there was on problem framing. [Update: I redid the search today, a little over three years later. On 3/6/2024, I got 542M hits on “problem solving” and 218K hits on “problem framing” — increases in both but the ratio is even worse than it was in 2021] [Second update: I did the search today, Dec. 4th, 2025, and the information was not given–but that’s the subject of a different post].

Let’s think about that ratio of 542 million to 218 thousand for a moment. Roughly, that’s 2000 to 1. If you have wrongly framed the problem, you not only will not have solved the real problem; what’s worse, you will have often convinced yourself and others that you have solved the problem. This will make it much more difficult to recognize and solve the real problem even for a solitary thinker. And to make a political change required to redirect hundreds or thousands will be incalculably more difficult.

All of that brings us to today’s story. For about a decade, I worked as executive director of an AI lab for a company in the computers & communication industry. At one point, in the late 1980’s, all employees were all supposed to sign some new paperwork. An office manager called from a building several miles away asking me to have my admin work with his admin to sign up a schedule for all 45 people in my AI lab to go over to his office and sign this paperwork as soon as possible. That would be a mildly interesting logistics problem, and I might even be tempted to step in and help solve it. More likely, if I tried to solve it, some much brighter & more competent colleague would have done it much faster.

Photo by Charlie Solorzano on Pexels.com

But why?

Why would I ask each of 45 people to interrupt their work; walk to their cars; drive in traffic; park in a new location; find this guy’s office; walk up there; sign some paper; walk out; find their car; drive back; park again; walk back to their office and try to remember where the heck they were? Instead, I told him that wasn’t happening but he’d be welcome to come over here and have people sign the paperwork.

You could make an argument that that was 4500% improvement in productivity, but I think that understates the case. The administrator’s work, at least in this regard, was to get this paperwork signed. He didn’t need to do mental calculations to tie these signings together. On the other hand, a lot of the work that the AI folks did was hard mental work. That means that interrupting them would be much more destructive than it would to interrupt the administrator in his watching someone sign their name. Even that understates the case because many of the people in AI worked collaboratively and (perhaps you remember those days) people were working face to face. Software tools to coordinate work were not as sophisticated as they are now. Often, having one team member disappear for a half hour would not only impact their own work, it would impact the work of everyone on the team.

Quantitatively comparing apples and oranges is always tricky. Of course, I am also biased because my colleagues are people I greatly admire. Nonetheless, it seems obvious that the way the problem was presented was a non-optimal “framing.” It may or may not have been presented that way because of a purely selfish standpoint; that is, wanting to do what’s most convenient for oneself rather than what’s best for the company as a whole. I suspect that it was more likely just the first idea that occurred to him. But in your own life, beware. Sometimes, you will mis-frame a problem because of “natural causes.” But sometimes, people may intentionally hand you a bad framing because they view it as being in their interest to lead you to solve the wrong problem.

Politics, of course, takes us into another realm entirely. People with political power may pretend to solve one problem while they are really following a completely different agenda. One could imagine, for instance, a head of state claiming to pursue a war for his people when he’s really doing it to keep in power. Or, they could claim they are making cities safe by deploying troops when they are really interested in suppressing the vote in areas that can see through his cons. Or, a would-be dictator could claim they are spending your tax dollars to make government more efficient when that has nothing to do with what they are *actually* doing–which is to collect data on citizens and make the government ineffective in order to have people lose confidence in government and instead invest in private solutions.

Even when people’s motivations are noble or at least clear, it is still quite easy to frame a problem wrongly because of surface features. It may look like a problem that requires calculus, but it is a problem that actually requires psychology or it may look like a problem that requires public relations expertise but what is actually required is ethical leadership.