“The Psychology of Design”

08 Thursday Jul 2021

Posted by petersironwood in Uncategorized

Tags

creativity, Design, HCI, human factors, IBM, leadership, research, UX

“The Psychology of Design”

I worked at IBM, all told, about 28 years. During that time, management put more and more 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 with the workers.

In the late 1970’s, the “Behavioral Sciences” group 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 story 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 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.

We used a spectrum of techniques to study “design” 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 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 showed the greatest diversity. 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.

“Wizard of Oz”

18 Friday Jun 2021

Posted by petersironwood in Uncategorized

≈ 5 Comments

Tags

HCI, IBM, research, usability, UX, Wizard of Oz

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

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

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”

Query By Example

15 Tuesday Jun 2021

Posted by petersironwood in Uncategorized

≈ Leave a comment

Tags

expertise, HCI, IBM, QBE, research, usability, UX

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.

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 five 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 do 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 Nadal or Djokovic 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).

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.

One example you may have run into 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

Non-Linearity

20 Thursday Dec 2018

Posted by petersironwood in America, management, psychology, Uncategorized

≈ 4 Comments

Tags

environment, equilibrium, feedback loops, ping pong, research, science, systems thinking, table tennis, testing, truth

Non-linearity

A Chessboard Full of Rice

According to myth, the Emperor’s wise adviser once did him a great favor. So grateful was the Emperor that he begged his wise advisor to take any gift she might like from the vast treasures of gold or jewels, any lands or gardens, any of the Emperor’s many male children to be her companion. However, the advisor answered as follows: “Thank you for your generosity, oh mighty Emperor. I have no need of great material wealth. My needs and wants are simple. I do get hungry and thirsty, of course, as do we all, and sometimes my household runs short of rice. You see this fine chessboard?”

Photo by Pixabay on Pexels.com

“Oh, yes, my wise counselor, it is indeed finely made of gold and silver and I would gladly give you twenty such!”

“Thank you again for your generosity, but I only wish for a some grains of rice. Give me one grain on this space and tomorrow, two grains on this space and the next day, four grains on this space. Each day for 64 days, double the number of grains of rice you gave me the day before. At the end of the 64 days, I will ask for no more.”

The Emperor looked puzzled. “Surely, you must have something more valuable than rice! Name it!”

“No, Sire, that is all I desire. Just the doubled rice will do quite nicely.”

“Well, it shall be so!” And thus the Emperor told his staff that they were to provide a grain of rice for the first day, two grains of rice for the next day and to double the amount each day until all 64 days had passed. At first, it seemed such a pathetic gift for such a great favor.

Even after 8 days, the wise counselor only received 128 grains of rice – not even a bowlful.

Readers familiar with exponential growth realize that on the 64th day, the Emperor has promised to deliver 2**63 grains of rice. This is not only more rice than the Emperor had at his disposal. It is more grains of rice than exist in all the kingdoms of earth. To be exact, the last payment is meant to be 9,223,372,036,854,775,808 grains of rice while the total is one less than 2**64. To put the matter scientifically — it’s a lot of rice! Much more than exists in the world.

How would you like the story to end? A wise Emperor, to my mind, would thank the counselor after a couple weeks and say, “I see, oh wise Counselor, that you used my gift to give me another gift to enhance my wisdom. For I now understand that what seemed at first an easy thing to do is actually quite hard. Doubling soon undoes even the richest king. I will keep this in mind when I think about interest rates and population growth.”

A crummy Emperor, on the other hand, might say, “I offer you a gift and you see fit to embarrass me by making me agree to an impossible task? Boil her in oil!”

The Lily Pad Pond Puzzle.

Beside my house is a pond. In this pond, a lily pad began to grow. Every day, it doubled in size. On day 20, it completely covered the surface of the pond. The surface of the pond is 400 square feet. How many days did it take to cover half of the pond?

red and green lily pads focus photography

Photo by Skitterphoto on Pexels.com

At first glance, you might think this problem is insoluble because you don’t know how big the lily pad was initially. In fact, you don’t even need to know how large the pond is. It will cover half the pond on day 19.

The Ping Pong Table Ping Pong Player Population

When I began at IBM Research in 1973, I soon discovered that a fair number of researchers were avid table tennis players. At lunch time, somewhere between six and twenty researchers would show up to play. There were two tables and some small amount of room for spectators to stand on the edges of the two ping-pong rooms and watch. Our rule was that if a person won, they would stay at the table and a new challenger would play. However, if you won three times in a row, you had to sit down regardlessly. I didn’t go over every lunch time, but I went over quite a few times over the course of my first ten years there and there was invariably someone to play with. Sometimes, I had a longer wait time than others, but it was never too long a wait.

Then, because management wanted to use one of the two ping-pong rooms for other purposes, they repurposed one of the rooms. Now, there was only one ping pong table. In the two ping-pong table case, remember, I never had to wait too long nor did I ever go there and have no-one to play. As I said, the number of players varied between somewhere around six to twenty. What is your prediction about how many players showed up when there was only one ping pong table?

Here’s what happened. The first day after this change happened, I went over and about fifteen people showed up. I, like everyone else, waited a long time for a game. Our “official” lunch hour was actually 42 minutes and the building was a five minute walk away. So, if you had to wait a half hour for your chance to play, it really wasn’t that much fun. In addition, there were some more subtle effects. All the players were good, but there some substantial differences in skill level. People tried to arrange it so that they played someone at about the same level. WIth only one table, this was trickier. In addition, when a relatively large number of people showed up, it was too crowded for everyone to see the match without interfering with play. It happened that I was too busy to go for a few days. The next time I showed up, no-one was there. Some of us talked about trying to “organize” the ping pong to insure that enough people showed up but everyone was busy and no-one wanted to take this on. Scheduling researchers is harder than you might think. It was hard for people to make a commitment to show up at noon because a meeting might run over, their manager might give them extra work, etc. The number of people showing up swung wildly for about two weeks and then stabilized.

At zero.

What had been a vibrant community with two ping pong tables did not stay the same size, or shrink to half when we were limited to one table. It went to zero.

Warring Positive Feedback Loops.

We’ve already talked about “positive feedback loops” which are also known as “vicious circles.” Sometimes, there are actually (at least) two positive feedback loops hiding beneath what appears to be a stable system. In the Case of the Missing Ping Pong Table described above, one positive feedback loop was simply that when you went there and had a good time through some combination of watching good matches or playing yourself, you were more likely to go there again. There was also a positive feedback loop that was more of a social nature. The more people who were there, the more likely it was you would find a good or interesting match. It was also more likely to be able to find someone you wanted to have a conversation with although the venue prevented this from being a big part of the adventure. Another way that having more people there increased the chances that more people would be there the next day was that it was kind of exciting to have a larger audience watching, cheering, throwing the ball back when the ball crept under the radiator after pin-balling around for awhile after a decent slam.

At the same time, there were other feedback loops, sometimes of the same factors but in a different range. For instance, beyond the point of having the periphery of the playing field covered one or two deep, additional spectators added only a little excitement and they were more likely to infringe on the needed space around the table. In addition, while the first ring of spectators felt very much a part of the action, the experience for the second ring of spectators was far less engaging. While I mentioned above that more players meant a better change of finding a good match, it also meant that one had to wait longer between matches. The worst case scenario, of course, is that you are the only one who shows up.

Behind Every Abstraction are a Host of Personal Stories.

Yes, you can practice against the wall, and I did this a few times, but it is significantly less fun than a real match. I love to serve, for instance. I have a raft of difficult serves. Just to give you one example, with most set-ups, I can hit the right side of the ball so thinly that I put enough side-spin for the ball to appear as though it isn’t even going to hit the table on the second side, but it does; it curves radically back around the left. Sometimes people are so surprised that they miss it entirely. Even if they get there, the sidespin often makes them hit it off the table or the curve causes them to mis-hit the ball on their thumb or finger. I can also add a fair amount of top-spin or under-spin as well. Anyway, I didn’t get to do any of that just hitting the ball against the wall. The wall was not perfectly smooth either. So I might hit three of four shots and then the ball would hit a little imperfection in the plaster and careen off to scribble scrabble along the floor and then crawl under the radiator. It’s the kind of annoyance that everyone has experienced. And if someone else is there, you can kind of glance at your friend who nods nearly imperceptibly as you get down on your hands and knees and stretch your fingers into the territory of God-knows what spiders or broken glass and feel around through the grit and dust until you retrieved the ball. And that little glance and that little nod actually make quite a difference. If you’re on your own, it’s not any fun at all. It’s just an annoyance. The only reason I even bother to hit against the wall is to learn to keep focus for extended periods of time. For this, it is good practice and a good challenge. But, if I’m interrupting this to go fish my hand into a pile of dust every couple minutes, it isn’t so likely I’ll come back.

Photo by Pixabay on Pexels.com

These various factors were all in a dynamic balance so long as there were two tables. When the tables went from two to one, however, what had been a stable equilibrium became a very unstable one. Eventually, of course, it did find a new equilibrium point and that was zero. To crawl out of that, one person might show up. But most of the time, they were the only one. So, they would be less likely to come again. Even if two showed up, since no-one could play every day, you might still find yourself wondering whether someone would be there the next time.

Photo by panumas nikhomkhai on Pexels.com

You might have read this whole story and wondered why the hell this building full of Ph.D.’s couldn’t get their act together and arrange some matches. It’s an interesting question and here is my personal opinion. When it came to these brilliant scientists and engineers, they came from every part of the globe and they came in all shapes and sizes. Some were vastly overweight and others were ultra marathoners. But the ones who liked to play table tennis were, by and large, athletic and “hyper” – an impatient lot. What all of us really loved was working to find out the truth. And, these truths that we sought were ones the company that we worked for wanted us to seek. True enough, but by the same token, that meant the truth found and utilized would make people’s lives better in some way in the not too distant future. But working in a corporation also meant doing a bunch of administrivia. So, the ping pong set in particular, wanted to get up from their intense sedentary mental and administrative work and play hard at something completely physical and different. The last thing any of us wanted to do was add more administriva to our lives.

The Takeaway

It’s easy and common to assume implicitly that the systems you deal with are linear.

They often aren’t.

Things can go out of control extremely quickly (into a dominant positive feedback loop) once the dynamic equilibrium is disturbed.

Would the invention of the iPhone have kept the ping pong community going?

Another takeaway: there are two quite distinct ways of analyzing that are going on in the essay above: a fairly abstract one (even if it uses concrete examples like rice and lily pads) and a very concrete and experiential one. In my experience, both of these modes are useful and valid and if taken together give a fuller picture of what’s going on. My experience in this was mainly in human computer interaction but I think it is equally true for many in law, medicine, management and many other fields. What’s your experience?

———————————

Author’s Page on Amazon.

Problem Finding

18 Tuesday Dec 2018

Posted by petersironwood in America, management, psychology, Uncategorized

≈ 2 Comments

Tags

Design, life, marketing, media, problem finding, problem solving, research, truth

Problem Finding

Today, I googled “problem solving” and it returned 287,000,000 results. In most of our school life as well as most people’s work life, we are given problems and asked to solve them. “Problem finding” only returned about 2.5 million or fewer than 1/100th as many hits. Solving problems can make processes more efficient and more effective. Solving problems can even save lives. We generally reward people both at school and at work for being good problem solvers. We seldom train people in problem finding. In fact, the reaction of many teachers and many managers when someone finds a problem is to dismiss it as being a non-problem.

I can understand this sentiment. As a teenager driving my dad’s car home from a date with my girlfriend, somebody beside me tried to make a right turn from the left lane and ran right into my dad’s blue Dodge. I heard what sounded like the voice of God say “NO!!” loud and clear. It was actually louder than the sound of crumpling metal. For a split second, I was in complete denial. Even some moments later, when we pulled over to assess the damage, it looked minor enough to ignore in my mind and just drive off. A more experienced guy from the corner gas station near where this happened said that while it may look minor, it would cost hundreds of dollars to fix and we therefore needed to trade information. I was stunned.

grayscale photo of wrecked car parked outside

Photo by Александр Неплохов on Pexels.com

In many cases, it is a human tendency to want to deny that a problem really exists. If you can get past that tendency however, and embrace problems and indeed, even learn to seek them out, you may be able to create tremendous value for yourself and for those around you. Problem solving can make your bookstore more profitable. Problem finding lets you invent Amazon. Problem solving lets you build a better internal combustion engine. Problem finding leads you to a Tesla.

What might you do to discover problems? First, you might take your own negative emotions as a jumping off place. If you find yourself angry, or anxious, or depressed, to the extent that you can trace back what is going on to the initiating event, you may be able to be consider whether that event is unique to you — or, more likely, that event is likely to trigger a negative reaction in many people.

person holding white polaroid land camera

Photo by fotografierende on Pexels.com

If you found waiting even 48 hours to have your photographs developed and printed — and you thought others might also be impatient to see the results, you might invent Polaroid instant photos. If you found cooking a casserole too time-consuming and messy for your taste, you might invent frozen dinners. If you drove a lot in hot, humid climates, you might be motivated to put air conditioning in cars.

Of course, you do not have to limit yourself to your own misfortune. If you read about someone having a miserable time, you could dig a little deeper and ask yourself how a tragedy might have been prevented or how an accident could have been avoided. You can also look at a change that seems minor and ask yourself what will happen if this change becomes widespread.

For example, if you read in the newspaper that a robot has been invented that harvests tomatoes, you might extrapolate to a more universal situation. What if all crops were harvested by machine? This might make groceries cheaper. But what else would it mean? Tomatoes are rather delicate, after all. You might wonder whether growers using a machine to harvest tomatoes would harvest them early to avoid them being mashed by the machine. You might wonder whether they would even genetically alter the tomatoes so that they were easier to harvest by machine (even if they were no longer as tasty). You might wonder what will happen to the tomato pickers? Politicians may tell you that they will all be retrained for higher paying jobs as machine inventors, machine programmers, and machine maintenance folks. But this makes no sense. If there were an equal number of IT jobs as there used to be tomato pickers but each of the new jobs came with a higher salary, why would the growers use robots? There will be fewer jobs after automation and in some cases, far fewer.

close up of hands holding cherry tomatoes

Photo by rawpixel.com on Pexels.com

You might look at the global temperature trends and ask yourself what will happen if they continue. What will happen if global temperatures continue to rise? What can be done about it? Of course, once people start seriously mapping out the consequences, some people will react by saying, “Oh, it isn’t really happening!.” Why do they think that? Because it’s too scary to contemplate the truth; or too inconvenient to take the necessary actions. There are vested interests in old energy sources who will be happy to help you along in your fantasy of denial. In the short run, it’s often easier to imagine that problems do not exist, or are not that bad, or won’t get worse, or that there is just nothing to be done.

Even most of the people who rail against what most of us think of as sensible gun regulation (requiring a license, showing ID, getting at least some training and testing the would-be gun owner’s knowledge, competency, and eyesight as we do with cars) don’t think that mass shootings of innocent children is a fine thing. They see it as a problem — just one that cannot be solved or one that can only be solved by adding cost and inconvenience to the potential victims. After such a tragedy, they may even send “thoughts and prayers.”

Photo by Specna Arms on Pexels.com

There is a possible “down side” to problem finding. The greedy may decide that they can make a lot of money by generating a solution to a problem that isn’t really a problem and making you believe it is a problem. My favorite, and so far made up, example is “Elbow Cream” for those unsightly skin wrinkles that appear on the back of your elbow when you straighten your arm. But that made up example is not too far off. You eat spicy food and it upsets your stomach? We can fix that! Of course, you could too by not eating spicy food! But nobody makes money that way. So they will sell you something that supposedly fixes the “problem.” While it might be fantasy to imagine “Elbow Cream” that will “fix” your “unsightly elbow wrinkles” it is not fantasy to imagine that people have been hoodwinked into spending money on “fixing” their faces and bodies.

fullsizeoutput_11b5

Americans spent 16 billion dollars on cosmetic plastic surgery in 2017. There are 50 countries who each have a lower GDP than that. The beauty industry in the USA overall was supposedly around $445 billion in 2017. That’s more than the GDP of each of 151 countries! Both figures are also less than the federal government spends on reducing climate change. Or cancer research.

Do you see that as a problem? I do.

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

Author Page on Amazon.

petersironwood

~ Finding, formulating and solving life's frustrations.

Tag Archives: research

“The Psychology of Design”

“Wizard of Oz”

Query By Example

Non-Linearity

Problem Finding