Author: Susan Gasson

Small World Information Bubbles
Small World Information Bubbles

Information Bubbles

We all live in an information bubble. Not because we are unaware of alternative perspectives, but because we prefer the perspectives of our “tribe” (or in-group).
Fox News, CNN, and MSNBC are filling the trust hole left by eroding community life. Increasingly, extremist online media groups and politicized TV networks are exploiting the vacuum left by abolishing the fairness doctrine. There is no requirement for media sources to be balanced or objective in their presentation of news or facts [1].

In the 1970s, 80s, and 90s research demonstrated that people only read newspapers that aligned with their political point-of-view (Knobloch-Westerwick et al, 2019). Now people seek out media, TV, and online news sources that align with their existing perspective – or are served with reinforcing points of view via social media filtering mechanisms.

A filter bubble is the state of intellectual isolation that arises when personalized searches, recommendation systems, and algorithmic curation selectively presents information to each individual user (Pariser, 2011).

Elfreda Chatman’s “Small World” Findings

Elfreda Chatman (1991) showed how people in working class and marginalized communities prefer news from friends & neighbors to external sources. She described the world that less-educated or impoverished individuals inhabit, using six aspects of information-seeking. Chatman argues that poor and less-educated individuals tend to:

1. Live life in a small world

Information originating outside of their local circle of contacts holds little of interest for the lower class. Their information access is driven by the combination of living in a risky environment, life at the margin of influence and social participation, and “the awareness that if one wants acceptance, future goals and aspirations must be constrained by the standards of one’s family and friends.”

2. Have lower expectations of success

People in marginalized and poorer communities believe their success is governed by luck rather than opportunity or skill.

3. Seek information only from direct or trusted contacts

People (generally) prefer to seek information mainly from others like themselves, and are skeptical of claims not personally experienced. They view external perceptions about reality as not adequate, trustworthy, or reliable, which limits exposure to new possibilities or education.

4. Have a limited-time horizon

Their lifestyle is present rather than future focused. They base decisions on “the immediate present and the very recent past” rather than planning for the future.

5. Have an insider’s worldview

People in marginalized and poorer communities view the outside world as unpredictable and hostile. There is an “us vs. them” mentality, where people residing outside of one’s familiar surroundings are viewed with suspicion.

6. Use the mass media differently than do higher socioeconomic classes.

Marginalized people are heavy television viewers: “mass media, particularly television, is viewed as a medium of escape, stimulation, and fantasy” rather than an information source. They perceive news to be a reflection of events that occur locally and so they are more likely to be “mistrustful of others and afraid of being victims of crime.” They keep dogs and guns for protection.

Chatman’s (1991) Small World theory has proved highly influential, as shown in Figure 1. This theory has been used to demonstrate how – because evaluating information in an online world is so complex – people tend to rely on members of their local community, or online influencers trusted by local community members, as sources of reliable information (Chowdhury & Chowdhury, 2013).

Figure 2. Influence of Chatman’s “Small World” Information Theory
(Gonza´lez-Teruel & Abad-Garcı´a, 2018)

Chatman’s “small world” theory explains why Fox News is so subversive to society: it markets itself as the sole purveyor of truth and plays on distrust of people outside the group by pretending that their privileged journalists are just like “ordinary people.” Members of marginalized and poorer communities consume news as a medium of entertainment – they are relatively uneducated and can be indoctrinated without realizing it, as this Fox News presents perspectives from “people like us.” When trying to get a broadcast license in the UK, from where they were banned, Fox News described their content as entertainment, rather than news.

Filter Bubbles in Online Communities

Because social media and news media are driven by algorithm or network-connected interaction, they create a “small world” network for everyone, regardless of social class. On social media platforms, algorithms and the need to develop networks of regular social contacts can inadvertently isolate a user into an ideological filter bubble (Pariser, 2011), by only serving them information that it thinks they want to see. For example, Meta (Facebook, Instagram, and Threads) curate their posts to match them to posts on similar topics, or containing similar keywords and sentiment-related modifiers that users have sought out previously [2]. If you “like” posts from a particular perspective, those are all that you will see. Two examples of filtering mechanisms are:
- On Threads, a Meta social media site which uses a preference-oriented algorithm to display posts for each user, there has been a lot of discussion about how the algorithm rewards people who “like” posts to sympathize with those whose dog or cat has just died, with a depressing, never-ending stream of posts about dead or dying pets.
- On platforms with no filtering algorithm, such as Bluesky, the need to follow other users in order to obtain visibility and online-interaction imposes its own filter bubble, as people tend to follow those with similar perspectives to their own (people whose posts they enjoy reading).
This creates an online small-world – an automated filter-bubble. Because of their limited, ideological information preferences, it is difficult to introduce people to alternative points of view. They see alternative ideological viewpoints – including factual support for counter-perspectives – as dishonest or subversive. When confronted by cognitive dissonance, they reframe the “facts” to fit with their beliefs, because of the importance of local community perspectives in their world. They engage in defense mechanisms such as avoidance, denial, or cherry-picking sources. Dissonance research has demonstrated that people are more willing to examine materials that confirm their beliefs than materials that dispute their beliefs. reinforcing their filter-bubble (and confirming research from previous decades). People become isolated in a filter-bubble of limited information sources, of which they are largely unaware.

Figure 2. In an ideological filter bubble, indicated by the circle, exchange of information is closed, limited to a prescribed network of influences, and insulated from rebuttal (Wikipedia)

Social media algorithms and network-association mechanisms (such as following people whose posts you prefer) can inadvertently isolate a user into an ideological filter bubble, by only serving them information that it thinks they want to see. It is important to actively seek out diverse sources of information and – when countering disinformation in a community – to introduce countervailing information (such as data on the efficacy of vaccination) via trusted community influencers, rather than presenting people with external, unvouched for scientific evidence.

Notes

[1] Kellyanne Conway, a public relations and media influencer working for Donald Trump, famously coined the phrase “alternative facts” to reflect ideological perspectives for which there was no objective evidence.
https://en.wikipedia.org/wiki/Alternative_facts

[2] An example of sentiment-analysis is associating a modifier such as “demented” with a keyword such as “president.” Posts containing both terms will be ranked as more attractive to the user than posts without them, if the user has “liked” posts with similar sentiment-terms previously.

Reference

Chatman, E. A. (1991). Life in a small world: Applicability of gratification theory to information-seeking behavior. Journal of the American Society for Information Science, 42, 438–449.
https://doi.org/10.1002/(SICI)1097-4571(199107)42:6<438::AID-ASI6>3.0.CO;2-B

Chowdhury, G. G., & Chowdhury, S. (2013). Human information behaviour studies and models. In Information Users and Usability in the Digital Age (pp. 55–84). Facet Publishing.
https://doi.org/10.29085/9781856049757.004

Gonza´lez-Teruel & Abad-Garcı´a (2018) The influence of Elfreda Chatman’s theories: a citation context analysisScientometrics (2018) 117:1793-1819
https://doi.org/10.1007/s11192-018-2915-3

Harmon-Jones, E., & Harmon-Jones, C. (2007). Cognitive dissonance theory after 50 years of development. Zeitschrift für Sozialpsychologie, 38(1), 7-16. Downloaded 5/12/2026 from
https://www.researchgate.net/profile/Eddie-Harmon-Jones/publication/255581596_Cognitive_Dissonance_Theory_After_50_Years_of_Development/links/638e8e53484e65005be6c4a8/Cognitive-Dissonance-Theory-After-50-Years-of-Development.pdf

Knobloch-Westerwick, S., Westerwick, A., & Sude, D. J. (2019). Media choice and selective exposure. In Media effects (pp. 146-162). Routledge. Downloaded 5/12/2026 from
https://kimliaa.wordpress.com/wp-content/uploads/2021/10/routledge_communication_series_mary_beth_oliver_arthur_a._raney_jennings_bryant_-_media_effects__adv.pdf#page=157

Pariser, E. (2011). The filter bubble: How the new personalized web is changing what we read and how we think. Penguin.

Wikipedia (2015) Filter bubble. Accessed 5/12/2026 at https://en.wikipedia.org/wiki/Filter_bubble. Graphic source Original: Evbestie Vector: Dabmasterars, CC BY-SA 4.0 https://creativecommons.org/licenses/by-sa/4.0, via Wikimedia Commons
May 11, 2026
Design as Bricolage.

When attending a boundary-spanning design meeting the other day, I was reminded of how important pattern sensitization is to design. When we explore a new problem-situation, we structure it according to the patterns that we perceive in that situation. This is why experienced designers are so much better at design than novices. It is not that experienced professionals are sharper, or better at design — but just that they have a wider repertoire of patterns to call upon. As they recognize familiar elements of the situation, they fit partial solutions to those elements. Problem decomposition is not hierarchical, in the sense proposed by Alexander (1964), but convergent. The problem-space and the solution-space co-evolve, as designers explore these in tandem (Maher and Poon, 1996; Maher and Tang, 2003).

Back to the meeting.
A group of strategic managers (including the systems people and the business process change manager) were examining how to revise business process support for a routine workflow. The problem that they faced was that this had been adapted by several workgroups (whose representatives were present) over time. So each of these managers had a different perspective of the problem, depending on what each group was trying to achieve. The customer support group were frustrated that they could not access all of the customer information in the system, but had to call another group to obtain missing information. The order-processing group were frustrated that they could not track the progress of an order without having to run three separate IT applications. The sales and marketing group were incensed that not all of the latest products and services were publicized on the website. None of these people – including the IT group managers – could see that these were related problems. They spent hours debating the fields to be displayed on the screens and the detailed reports needed, without realizing that the workflows were related.
The breakthrough came by accident, when the Process Improvement Manager was mapping the “requirements” on a whiteboard. He started to link two of the requirements, stood back and then said “So this step is also related to this one, isn’t it?” Then the Marketing Manager said “That comes just before the promotions stage.” As the Process Improvement Manager drew a process diagram, each individual kept adding in pieces of the puzzle, with how they were related.

Design as bricolage.
Bricolage involves repeated “trying out” and experimentation until a pattern is discerned that is useful. (The word derives from Bricoleur, a French term meaning “handy-man” or “jack- of-all-trades.”) Claudio Ciborra described bricolage as “the constant re-ordering of people and resources that is the true hallmark of organizational change.”

Bricolage is based on leveraging the world “as defined by the situation” (Ciborra, 2002). This process is not random experimentation – it is the construction or creation of a design from the range of available things or ideas. In other words, bricolage is what we do when we call on the patterns – the arrangements of, and relationships between technology, people, and concepts – to which we have been sensitized. There is a fascinating article, just as relevant now as when it was written, that discusses “How The Refrigerator Got Its Hum” (Cowan, 1995). It will come as no surprise that refrigerators hum because …. refrigerators have always hummed. But it is much more complicated than that. There was a point in time when designers had to make choices about which technologies to use. These choices are embedded in a whole set of assumptions about users, networks of power, and influence.

Becoming aware of Pattern sensitization adds another dimension to bricolage. It makes us aware of the sources that we use as inspiration. Design can now be seen as an ordering of situation elements until they make sense according to previously encountered patterns. So design is like a jigsaw. Each person carries around a partially-completed set of jigsaw pictures in their heads. The core problem of design is to use a problem-representation that can allow people to communicate the structures in their “mental jigsaw picture” to others.

References

Alexander, C. Notes On The Synthesis Of Form. McGraw Hill, New York NY, 1964.

Ciborra, C.U. The Labyrinths of Information: Challenging the Wisdom of Systems Oxford University Press, Oxford UK, 2002

Cowan, R.S. 1995. “How the Refrigerator Got its Hum,” in: The Social Shaping of Technology, D. Mackenzie and J. Wajcman (eds.), Buckingham UK: Open University Press, pp. 281-300.
– You can check this book out of the Internet Archive to read the chapter cited – do look at the other chapters as well, because there are lots of fascinating ideas in this book!

Maher, M.L., and Poon, J. “Modelling design exploration as co-evolution,” Microcomputers in Civil Engineering (11:3) 1996, pp 195-210.

Maher, M.L., and Tang, H.-H. “Co-evolution as a computational and cognitive model of design ” Research in Engineering Design (14:1) 2003, pp 47-64.

March 31, 2026
Socio-Technical System Design

Origins of Human-Centered Design

A few years ago, I published a paper on user-centered vs. human-centered design. I compared HCI analysis methods to a more human-centered approach based on industrial engineering and “soft systems analysis” (Checkland, 1999). Having seen the recent explosion of “user-centered” design fields such as User Experience design, I feel even more strongly that human-centered design is a discipline that has not yet fulfilled its potential for changes to the way in which we design technology systems for both work and play.

Human-centered design ideas come out of an emancipatory labor movement – originally in the UK – that looked at the constraints imposed by technology on work and focused on the impact of design on the quality of working life. This “socio-technical” approach to design (Emery & Trist, 1960) originated in studies of industrial processes, often embedded in the rapid societal and technical change of post World War II Britain conducted by researchers from The Tavistock Institute of Human Relations in London. A research team led by Eric Trist, Ken Bamforth, and Fred Emery studied the organization of coal-mining teams for various types of mine and coal-seam environment, concluding that the design of working arrangements and the use of technology needed to be balanced with the conditions in various type of working environment. They noted the tension between the need for miners to self-organize into collaborative groups that increased productivity by allowing miners autonomy in selecting their team role, and management directives which constrained group autonomy because this empowered the miners – and allowed them to negotiate the higher rates paid for skilled labor (Trist et al., 1963). They coined the term “sociotechnical” to define an approach to the design of working arrangements that balanced the socially-situated needs of human workers with the use of machinery to automate repetitive and dangerous work.

The ideas behind socio-technical design really took off in the 1980s, with the explosion of affordable office technologies and personal computing. Some notable thinkers in this aspect of design include:

Mike Cooley (Architect or Bee?, 2016), who explained how technology design choices exerted control over the labor force at the expense of social good. A key element of his arguments was to explain how the combination of conceptual design ability with the practical ability to understand the context of practice across multiple domains – common in the renaissance – has given way to a “deep dive” specialization in one area or another. This separation of “planning” from “doing” leads to design problems, as designers cannot envision the context in which their design will be used and make stupid mistakes. It also excludes consideration of social good when making design choices. Technology decisions are made on the basis of manufacturing cost rather than long-term, environmental impact.

Ken Eason, who argued in his early work (e.g. Eason, 1982) that designers’ choice of design approach affected system usability: a technology-led approach leads to ‘fire fighting’ when negative organizational effects become apparent; and user involvement in design tends to fail as users take longer to understand new technology than developers, so design is complete by the time they are able to make a contribution. He proposed an evolutionary design process that builds slowly from small-scale systems to large ones, retaining the flexibility to change and adapt to emerging user needs, promoting user learning via system prototypes and training, and involving users in system evaluation. His later work discusses how the typical “closed system” approach to IT design (goal-oriented and focused on predefined requirements) constrains the “open system” approach to design needed to balance the emergent needs of human users with technology goals, and also cater for the evolving system requirements engendered by changing global business environments (Eason, 2009).

Howard Rosenbrock (1981, 1988), was a visionary engineering theorist, who not only developed innovative techniques approaches to algorithm design for control engineering, but also saw engineering as an “art” (Rosenbrock 1988) that needed to balance the design of technology with the social needs, personal experience, and judgment of human beings. The opening to his 1981 paper, Engineers And The Work That People Do, contains the most chilling description of a work environment that I have ever read:

The plant was almost completely automatic. Parts of the glass envelope, for example, were sealed together without any human intervention. Here and there, however, were tasks which the designer had failed to automate, and workers were employed, mostly women and mostly middle-aged. One picked up each glass envelope as it arrived, inspected it for flaws, and replaced it if it was satisfactory, once every four-and one-half seconds. Another picked out a short length of aluminum wire from a box with tweezers, holding it by one end. Then she inserted it delicately inside a coil which would vaporize it to produce the reflector, repeating this again every four-and-one-half seconds. Because of the noise, and the isolation of the work places, and the concentration demanded by some of them, conversation was hardly possible.
Rosenbrock, H. H. (1981). Engineers And The Work That People Do, pg. 4.

This description still sends shivers down my spine. Not just because of the working conditions, but because of the casual way in which Rosenbrock mentions that the few manual work-processes on the light-bulb factory floor are not automated only because they are too complex or expensive to automate. They used human-beings for repetitive, demeaning jobs in which the environment made it too difficult to socialize with others, simply because they were cheaper or easier than designing an automated solution.

Moving to Participative Design

Obviously, any blog post cannot capture the whole of the socio-technical movement, with all the complexities that the various studies introduced. Here, I have tried to outline the tip of the iceberg, explaining the motivations that led to the HCI, CSCW, and agile design fields that influence contemporary design. But I cannot leave this discussion before mentioning the key influence of End Mumford. Professor Mumford was critical in promoting the importance of user participation in design (Mumford, 1983). She even conducted studies to demonstrate how users “went native” when participating in technology design, as technology-design skills were considered so glamorous and career-enhancing (1975). She devised a method – the ETHICS approach – that illustrated how to analyze requirements in ways that both balanced the technical and the social aspects of design, but also managed the inevitable subversion of social (work-system) design by considerations of technical expediency and optimization (Mumford & Weir, 1979; Mumford, 1995).

So how do we design human-centered systems that support workers in the work they need to do, while allowing them autonomy in the way that they do this work? The process devised over many years is to use socio-technical systems design.

Figure 1. Socio-Technical System Design

As shown in Figure 1, above, socio-technical design balances the needs of a “supported system” of people doing work – a.k.a. the social system – with a “supporting system of information and communication technology – a.k.a. the technical system. It is important to start with the social system: the people who do the work are unfailingly the people who understand best what it requires, in the way of information and computing support. It is also important to see the drivers of design as the need to balance changes to the two systems, so the IT system supports the system of work (and not vice-versa). I refer to this principle as the co-design of business-process and IT systems. This concept is actually taken from the work of Peter Checkland, who argues that designed IT systems often solve the wrong problem, because designers fails to appreciate that the point of design is to support purposeful systems of human activity, rather than pursuing the separate aims of a technology architecture, data structures and information systems (Checkland, 1999; Winter, Brown, & Checkland, 1995).

References

Checkland, P. (1999) Systems Thinking, Systems Practice: includes a 30-year retrospective. John Wiley and Sons Ltd. Chichester UK. ISBN: 0-471-98606-2.

Cooley, Mike (2016). Architect or Bee? The Human Price of Technology. UK: Spokesman Books. ISBN 978-0-85124-8493.

Eason, K. D. (1982). The Process Of Introducing Information Technology. Behaviour and Information Technology, 1(2), April-June 1982>
Reprinted as Eason, K.D. (1984) “Managing Technological Change,” in Rob Paton, Suzanne Brown, Jake Chapman, Mike Floyd and John Hamwee (Eds.) Organizations: Cases, Issues, Concepts. The Open University, Milton Keynes, UK.

Eason, K. D. (2009). Before the Internet: The Relevance of SocioTechnical Systems Theory to Emerging Forms of Virtual Organisation. International Journal of Sociotechnology and Knowledge Development, 1(2).

Emery, F. E., & Trist, E. L. (1960). Socio-Technical Systems. In C. W. Churchman & M. Verhulst (Eds.), Management Science Models and Techniques (Vol. 2). Oxford UK: Pergamon Press.

Mumford, E. & Sackman, H. (1975) Human Choice and Computers, North-Holland Publishing Company.

Mumford, E. & Weir, M. (1979), “Computer Systems in Work Design: the ETHICS Method”, John Wiley, New York

Mumford, E. (1983) Designing Participatively: A Participative Approach to Computer Systems Design. Manchester Business School, Manchester, UK.

Mumford, E. (1995) Effective Systems Design and Requirements Analysis: The ETHICS Approach. Macmillan, Basingstoke, UK

Rosenbrock, H. H. (1981). Engineers And The Work That People Do. IEEE Control Systems Magazine, 1(3), 4-8.

Rosenbrock, H. H. (1988). Engineering As An Art. AI & Society, 2(4), 315-320.

Trist, E., Higgin, G., Murray, H., and Pollock, A. B. (1963) Organisational Choice. London: Tavistock Publications.

Trist, E. L. (1981). The evolution of socio-technical systems. Toronto: Ontario Quality of Working Life Centre. Report access is provided courtesy of Larry Miller’s Blog on Leadership, Learning and Culture.

Winter, M. C., Brown, D. H., & Checkland, P. B. (1995). A Role For Soft Systems Methodology in Information Systems Development. European Journal of Information Systems, 4(3), 130-142.

October 4, 2024
Designing for Real Users

Recently, I spoke with a colleague who was serving on a design committee for a new company intranet site. He kept coming back to the problem of determining the placement of the CEO’s vision message, as the interface was starting to look rather cluttered. A senior marketing consultant was the lone holdout against this obvious vanity item, to which the design team felt compelled to give pride of place, at the top of the landing page. It occurred to me that few people were likely to be interested in this item, or to understand its significance in terms of company strategy. Yet it was being allocated valuable real estate and other items – which intranet users would need to access frequently – were being buried in a complex menu as a result. The design group did not even consider allowing users to configure the landing-page layout, so they could place frequently-accessed information pages at the top.

Design is not a one-size-fits-all activity. We are all the product of our experiences ~ no two people have the same perspectives. It is a common anti-pattern to design for people-like-us.

After all, aren’t web designers the most interesting, creative, and representative people in the world?

Yet most people are less interested in the mechanics and visual impact of web design than the average web designer. Yes – emotional design is important. But not as important as enabling the user to achieve the purpose of their visit by making content easy to find – and interesting.

Good design focuses on customer visit objectives, to hit the sweet spot in the push vs. pull tradeoff. Content design and navigation tend to be driven by the firm’s business model – what designers want to push to the users of our website. This results in unnecessary frustration, as the user tries to achieve the purpose of their visit. UXD sweet spot design balances the firm’s push factors with customer pull factors: what they need from the site, why they need it (their visit objectives), and how they expect to locate it (comparative design exemplars). You can only discover these things from user research, rather than lazy-UXD.

Figure 1. Hitting the sweet spot between push vs. pull in site navigation

It’s easy to design a site that directs your users to the products, areas, and sales possibilities that your company wants to push.
Not only is this less effort than worrying about what your users came here to find, but your manager will be pleased, as you are focusing on what matters to the company.
Your users? Not so much …
…In fact, they may try to avoid your website altogether, visiting only when they really have to …

In conclusion, we tend to design systems and websites with a one-size-fits-all interface, where the priority and placement of various information is determined by designers. There are two problems with this approach:
1. These decisions are often political, or driven by those who shout loudest.
2. The worst anti-pattern in design is to design for people-like-us. Most people do not think like web-designers. They have different priorities and interests, based on the work that they do.
We should let users decide what order they want to see which items, in interface design. Give them a configurable interface, so they can arrange things to suit their own way of working – and priorities.

October 4, 2024
Why is design improvisational?

We talk about design as if it were ﬁxed: as if there were one best way to design everything. We celebrate designers who produce especially elegant or usable artifacts as if they were possessed of supernatural powers. Yet design should be easy. It is the application of “best practice” principles to a speciﬁc situation. We can observe how the users of a designed artifact or system work, then design the artifact or system accordingly. Why does that approach fail so often?

The key issue is the problem of “the problem.” Designers are taught a repertoire of designs-that-works: patterns that ﬁt speciﬁc circumstances and uses. Experienced designers are capable of building up a deep understanding over time, of which problem-elements each of these patterns resolves. So they can assess a situation, recognize familiar problem-elements, then ﬁt these with design patterns that will work in these circumstances. The problem comes when a designer is faced with a novel or unusual situation that they have not encountered before. Novice designers encounter this situation a great deal, but even experienced designers must deal with emergent design in a novel context. In these circumstances, designers iterate their design, as shown in Figure 1. They identify (often partial) problems, ideate/conceive relevant solutions, give those solutions form with a prototype, then evaluate the prototype in context. This often reveals emergent user needs or problems, that are explored in the next iteration.

Figure 1. Iterative Design

An important aspect of iterative design is that iterations can occur within cycles. As designers succeed or fail at successive designs, they accumulate experiential knowledge, that allows them to assess new situations quickly and

to understand which design elements will work or fail in that situation, looping back to remediate the design as they spot logical ﬂaws and gaps in the design. The problem with this is that (as the Princess said) you have to kiss an awful lot of frogs to get a Prince. An awful lot of people end up with really bad designs, because their designer did not recognize elements of the situation well enough to understand which pattern-elements to implement. If you are really unlucky, you will also end up with one of those designers who feel it is their mission in life to prevent the end- user “mucking about with” their design. If you are lucky, your designer will recognize that it is your design, not theirs. They design artifacts and systems in ways that allow people to adapt and improvise how they are used.

Which means that design-goals are constantly changing between iterations, as shown in Figure 2. The designer starts by designing for the subset of goals they understand. As they explore and test the design with users, they become aware of new requirements and so modify the subset of goals they are designing for. As part of this process, they also discard any requirements that are no longer associated with perceived user needs.

Figure 2. Goal-emergence in design

Improvisation takes a multitude of forms. It might be that a user wishes to customize the color of their screen (because the designer thought that a good interface should look like a play-school). This may not do much for the function of your work-system, but it does mean that your disposition towards work is a heck of a lot sunnier as you use it. Or it might be that the information system which you use expects you to enter data on one step of your work before another. You might be able to enter data into a separate screen for each step, reordering the steps as you wish. More usually, you have to enter fake data into the ﬁrst step, then go back later to change this, once you have the real data. This is because IT systems designers treat software design as a well-structured problem. A well- structured problem is one that contains the solution within its deﬁnition. Deﬁning the problem as a tic-tac-toe game application means that you have a set of rules for how the game is played which absolutely deﬁne how it should work. This is ﬁne if everything goes to plan, but a huge pain for users when it does not. The only discretion left to the user is how to format the results in a printed report, which is not much comfort if your whole transaction failed because you were prevented from going back to change one of the inputs. This is not rocket science – developers need to design systems that let users work autonomously.

Business applications tend to present wicked problems . A wicked problem cannot be deﬁned objectively, for all the reasons identiﬁed in Figure 3. Solving a wicked problem needs business users and stakeholders to agree on what problems that they face, their priorities in resolving these, and what their change-goals are.

Figure 3. Constraints on Design Posed by Wicked Problems (Rittel & Webber, 1973)

A wicked problem can be understood as a web of interrelated problems. It is not always clear what the consequences will be, of solving any part of this mess. Some of the problems may have “obvious” solutions. But implementing these solutions may make other, related problems worse or better. This is why iterative design is central to resolving wicked problems. In general, stakeholders don’t understand what they need until they see it. So solutions must be designed ﬂexibly, for changes to be implemented as the consequences are realized and to permit adaptation-in-use by stakeholders and users. People are inﬁnitely improvisational. They develop work-arounds and strategies to manage poor design. But, as Norman observes, why should users have to develop work-arounds for poor design? What is it, about the design process, that leads us to such constraining IT systems, interfaces, and work procedures that are based on the system design, rather than system designs that are based on ﬂexible work- procedures?This website reﬂects ﬁndings from my research studies and reﬂections from my own experience in design, to discuss some key underlying principles of design, to explore how the design process works in practice (rather than how we manage it now, which is based on unsupported theoretical models), and to present a way of managing design differently. … Improvisationally.

References

Norman, D. A. (2013). The Design of Everyday Things: Revised and Expanded Edition. Basic Books, New York.

Rittel, H. W. J., & Webber, M. M. (1973). Dilemmas in a General Theory of Planning. Policy Sciences, 4, 155-169.

August 19, 2024
Coordination, Cooperation, and Collaboration

I was musing about the differences between these three concepts. They are not explained clearly in any resource I could find (although many people take a stab at this), so I thought I’d try bending my brain around the problem. The three types of collectivity appear goal-oriented (as in, sharing a common purpose), but there are big differences between the ways in which group members interact – and the reasons for these types of interaction.

Cooperation is when people share ideas about how to work, or share effort to complete the work towards a shared goal, which is understood in common. People work together to complete a task that would be much more difficult to complete individually. Cooperation often involves deciding how to divide the work between individuals in a group for an optimal outcome – for example, in software or organizational change projects. Work may be divided laterally (each person takes a separate slice of the work towards a deliverable), vertically (each person takes a separate deliverable), or performed collectively, where people share the effort required to achieve a goal (for example, analyzing a business process that is too diverse – involving too many stakeholders – for one person to explore in a reasonable amount of time).

Coordination is the organization of work-tasks across individuals to achieve a complex goal that requires analysis (breakdown into subtasks) before it can be addressed. People work together towards a common goal within an agreed timeframe, even if they don’t understand all the tasks required at the start. They organize their activities around a schema, which provides a model of the parts of the work to be done. They divide their labor on the basis of this schema, with individuals or sub-groups completing each part, which is assembled into a whole once all relevant parts have been completed. They may collaborate to perform shared subtasks.

A Work Breakdown Schema (WBS) Used For Coordination of Work

Coordination may be organized around interim deliverables, which are completed individually from subsets of the work-schema, then assembled once all the parts are complete. The underpinning concept to coordinated work activity is that of a plan – a plan of work, or a plan of how the parts of the whole are organized. This is used to guide the coordination of work, across individuals and across groups. For example, in traditional software project management, work is coordinated around a work breakdown structure (WBS).

Collaboration is the pooling of effort, to achieve a joint goal, which everyone in the group of coordinated workers may not understand in the same way (so this is not a shared goal – subgoals may emerge through the processes of discussion and experimentation over how to perform the work). People work together, taking different parts of a task, to achieve a goal that, if not understood in common at the start of the process, will probably be understood in the same way by the end. Collaboration requires trust (that other people will work towards a common goal), but it is more adaptive than coordinated work – instead of agreeing a model of the task in advance, collaborators develop a shared model of the task deliverables as they collaborate on the task. Working together increases the amount of shared understanding between people, which allows them to improvise and adapt the plan of work to contingencies that arise. So both goals and work-practices evolve as shared practice increases shared understanding between collaborators. Software developers, working on agile software projects, collaborate in analyzing how to coordinate their team’s work around a feature-breakdown then coordinate team work around each person implementing the next feature in the backlog. Finally, they collaborate around integrating the feature components into a coherent prototype system.

Collaboration schema, where sub-goals are explored and defined independently, then merged to achieve an integrated outcome

Collaboration is organized around sub-components (or sub-goals) of the planned outcome that are defined separately. Each sub-component emerges through discussion and experimentation, so the parts are managed autonomously by delegating them to different people. It is only at the integration stage that the shape of the whole solution can be understood.

June 27, 2015
Improvising Design For Emergent Problems

Why is design improvisational? We talk about design as if it were fixed: as if there were one best way to design everything. We celebrate designers who produce especially elegant or usable artifacts as if they were possessed of supernatural powers. Yet design should be easy. It is the application of “best practice” principles to a specific situation. We can observe how the users of a designed artifact or system work, then design the artifact or system accordingly. Why does that approach fail so often?

The key issue is the problem of “the problem.” Designers are taught a repertoire of designs-that-works: patterns that fit specific circumstances and uses. Experienced designers are capable of building up a deep understanding over time, of which problem-elements each of these patterns resolves. So they can assess a situation, recognise familiar problem-elements, then fit these with design patterns that will work in these circumstances. The problem comes when a designer is faced with a novel or unusual situation that they have not encountered before. Novice designers encounter this situation a great deal. As designers succeed or fail at successive designs, they accumulate experiential knowledge, that allows them to assess new situations quickly and to understand which design elements will work or fail in that situation. The problem with this is that (as the Princess said) you have to kiss an awful lot of frogs to get a Prince. An awful lot of people end up with really bad designs, because their designer did not recognize elements of the situation well enough to understand which pattern-elements to implement. If you are really unlucky, you will also end up with one of those designers who feel it is their mission in life to prevent the end-user “mucking about with” their design. If you are lucky, your designer will recognize that it is your design, not theirs. They design artifacts and systems in ways that allow people to improvise how they are used — and the role that they play in the work that people do.

Improvisation takes a multitude of forms. It might be that you customize the color of your screen (often because the designer thought that a good interface should look like a play-school). This may not do much for the function of your work-system, but it does mean that your disposition towards work is a heck of a lot sunnier as you use it. Or it might be that the information system which you use expects you to enter data on one step of your work before another. You might be able to enter data into a separate screen for each step, reordering the steps as you wish. More usually, you have to enter fake data into the first step, then go back later to change this, once you have the real data. This is because IT systems designers treat software design as a well-structured problem. A well-structured problem is one that contains the solution within its definition. Defining the problem as a tic-tac-toe game application means that you have a set of rules for how the game is played which absolutely define how it should work. The only discretion left to the designer is whether to support one or two players and how to present the functions in a usable screen interface. This is not rocket science: most designers can manage this level of design without making the game unusable.

But information systems applications tend to present wicked problems. A wicked problem is a problem that cannot be defined objectively, but needs the people involved (the stakeholders) to agree on what the problems that they face are, what are their priorities in resolving these, and what they want to achieve in changing things in the first place. A wicked problem can be understood as a web of interrelated problems. It is not always clear what the consequences will be, of solving any part of this mess. Some of the problems may have “obvious” solutions. But implementing these solutions may make other, related problems worse or better. For example, consider the problem of providing State-based unemployment benefit in the USA (see the diagram on the “systems thinking” page). If one State offers such benefits and a neighboring State does not, unemployed people will move to the State which does offer benefit payments. This will place a greater tax burden on that State, causing the more affluent residents and businesses to move out. This increases unemployment, raising the tax burden, causing more people and businesses to move out. The act of offering State-based unemployment benefits leads that State into a downward spiral in which their budget becomes unmaintainable and employment opportunities are significantly reduced. For wicked problems, a wider perspective is needed, that examines interactions between problem elements and which analyzes the impact of one problem-solution on other problems. It is not always possible to foresee all unintended consequences. So solutions must be designed flexibly, for changes to be implemented as the consequences are realized and to permit customization by stakeholders and users.

People are infinitely improvisational. They develop work-arounds and strategies to manage poor design. But I constantly ask myself why should they have to develop work-arounds for poor design? What is it, about the design process, that leads us to such constraining IT systems, interfaces, and work procedures that are based on the system design, rather than system designs that are based on flexible work-procedures? This website reflects findings from my research studies and reflections from my own experience in design, to discuss some key underlying principles of design, to explore how the design process works in practice (rather than how we manage it now, which is based on unsupported theoretical models), and to present a way of managing design differently. Improvisationally.

April 14, 2015
Design Methods as Performative Objects

Brown and Duguid’s (2001) concept of a “network of practice” has been niggling away at my consciousness. The idea is that a collection of people are enabled to understand each others’ work because of commonalities in practice, but not to the extent that a Community of Practice creates shared ways of framing and performing work:

“we include under the rubric … groups whose members, to the extent that they have common practices, are able to read and understand one another’s work. Disciplinary networks of practice cut across heterogeneous organizations, including, for example, universities, think tanks, or research labs. Professions make up yet other such networks of practice, where again similar practitioners, by virtue of their practice, are able to share professional knowledge through conferences, workshops, newsletters, listservs, Web pages and the like. … different networks of practice cut horizontally across vertically integrated organizations and extend far beyond the boundaries of the latter. Along these networks, knowledge can flow.” (Brown and Duguid 2001, p. 206)

So create closer bonds than organizational membership, spanning organizational boundaries. If the type of intersubjectivity that derives from shared practice (i.e. what Polanyi calls tacit knowledge) does not underpin a network of practice, what does? This rings true, given the observation that IT professionals identify more with the interests of their profession than with their organization (Chou and Pearson 2012). Which brings me to the second property of networks of practice:

“it is important to note that networks of practice may also inhibit the flow of knowledge. As Lynn et al (1996) show, professional networks will occasionally work to resist the spread of ideas felt to be inimical to the interests of the network’s members.” (Brown and Duguid 2001, p. 207).

So how do networks of practice share knowledge? Brown and Duguid have an explanation:

“We have used the notion of networks of practice to explain leakiness. This is not, we have suggested, simply an inherent property of some kinds of knowledge. It does not result from making knowledge explicit and so tradable. It is, rather, a function of the common underlying practice, which creates social-epistemic bonds. Where practice doesn’t prepare the ground, knowledge is unlikely to flow.” (Brown and Duguid 2001, p. 207)

But this is not very satisfying when members of the network are not co-located. Surely, “common underlying practice” includes some form of shared framing as the basis of those social-epistemic bonds? I thought back to the work of Howard Rosenbrock (1981), who explains that IT professionals’ paradigm of system design with the aim of making users interchangeable results in deskilled, repetitive, and unfulfilling jobs for those who use these systems. He explains:

“The paradigm is transmitted from one generation to another, not by explicit teaching but by shared problem-solving. Young engineers take part in design exercises, and later in real design projects as members of a team. In doing so, they learn to see the world in a special way: the way in fact which makes it amenable to the professional techniques which they have available.” Rosenbrock (1981, p.6),

So we have design methods as a form of performativity, embedding ways of framing job design, as well as creating a shared design practice that ignores users’ psychological and motivation needs. But surely, IT professionals are continually learning, acquiring new skills and approaches to system design? It would appear not:

“The fact that most IS professionals learn the bulk of their technical skills during college or immediately afterward encourages recruiters to focus on technical skills for new hires. IS professionals generally learn non-technical skills in the workplace.” (Lee et al. 2001, p.28).

All is not lost. Lee et al. (2001) go on to observe

“IS professionals generally learn non-technical skills in the workplace. And because these non-technical skills are so valuable in the long term, new hires need to possess the aptitude to learn these skills. This may help explain why recruiters prefer graduates who took more MIS classes than those who concentrated strictly on computer science courses.” (Lee et al. 2001, p.28).

How can we remedy the perspective that leads to such impoverished outcomes? As Rosenbrock observes, IT systems can be seen as a replacement for human ingenuity and skill, or as a way of supporting these. We have a choice to automate or to informate work (Zuboff 1988). We also have two chances to undermine the automation-on-rails approach taught in so many methods classes. Back to the network of practice idea. IT professionals have a network of practice with really strong bonds. We can teach IS methods more thoughtfully to those who return – for ongoing education in Masters degrees, etc. Finally, we can mobilize the network of practice, on LinkedIn and elsewhere, to ensure that IT professionals are aware of the types of skill and knowledge-preserving approaches to organizational system design that we would want to see used in our own organizations.

References

Brown, J.S. and Duguid, P. 2001. “Knowledge and Organization: A Social-Practice Perspective,” Organization Science (12:2), pp. 198-213.

Chou, S.Y. and Pearson, J.M. 2012. “Organizational Citizenship Behaviour in It Professionals: An Expectancy Theory Approach,” Management Research Review (35:12), pp. 1170-1186.

Lee, S., Yen, D., Havelka, D., and Koh, S. 2001. “Evolution of Is Professionals’ Competency: An Exploratory Study,” The Journal of Computer Information Systems (41:4), pp. 21-30.

Rosenbrock, H.H. 1981. “Engineers and the Work That People Do,” IEEE Control Systems Magazine (1:3), pp. 4-8.

Zuboff, S. 1988. In the Age of the Smart Machine. New York NY: Basic Books.

July 10, 2014
Responsive Web Design

I manage the website for an Animal Rescue shelter. I have been struggling with the design of the site for some time now, as I have some users who are still using IE6 under windows XP (on an SVGA screen), some who want to view the site on their mobile phones, and some who have really wide displays and think my two column design looks outdated (it does). While looking for a solution, I came across the concept of responsive web design. Because the reference I just provided is stuffed with code snippets (and I personally think it is obscure), I will point you instead to some really great examples that demonstrate how a website design can be responsive.

There is a neat concept at play in most of these designs, where a webpage layout is segmented into multi-device layout patterns, that simply “flow” differently, depending on the screen size that the user will display the site on. But screen size is not the only consideration – images have to be resized to scale with the device and the performance of the device must be considered (it is painful to load a large, graphics-intensive page on a slooow tablet!). I was also musing that – most relevantly to this course – site menus and navigation toolbar interfaces have to be designed so that they will work on any device or layout. Which is harder than you’d think, simply because of the layout conventions that we use on a typical web-page.

Off to experiment with scripts and pageflow layouts …

March 12, 2014
Actor-Network Theory

Sociomaterial Networks of Resources (Human and non-Human)

A recent emphasis on sociomateriality appears to have entered the IS literature because of discussions by Orlikowski (2010) and the excellent empirical study of Volkoff et al. (2007). Now that people have been sensitized to the literature on material practice, actor-network theory is classified as “tired and uninformative” [1]. Which leads me to wonder just how many IS academics have actually read the actor-network theorists? Or pondered how this applies to technology design?

Long before people started discussing socio-material “assemblages,” Bruno Latour (1987) and John Law (1987) were discussing how technology developed by means of “heterogeneous networks” of material and human actants, the combination of which directs the trajectory of technology design and form. Latour (1999) suggests that he should recall the term “actor-network,” as this is too easily confused with the world-wide web. Yet actor-networking – in the sense of a web of connectivity, where heterogeneous interactions between diverse individuals, between virtually-mediated groups, and between individuals and material forms of embedded intentionality – is exactly what is going on in today’s organizations.

In addition, Michel Callon’s (1986) work on how the “problematization” of a situation in ways that aligns the interests of others leads to their enrolment in a network of support for a specific technological frame. Once support has been enrolled, such networks endow irreversibility, which makes changes to the accepted form of a technology solution incredibly difficult. So we have paradigms that are embedded in a specific design. Akrich coined the term “script” to define the performativity of technology and the term was adopted by the other leading actor-network theorists [2]. This thread of work articulates incredibly deeply the ways in which technology design directs its users (and maintainers) into a set of roles and worldviews that are difficult to escape. We must “de-script” technology to repurpose it to other networks and other applications – which is much more difficult than one would suppose, given the embedded social worlds that are carried across networks of practice with the use of common technologies (Akrich 1992).

So what does actor-network theory give us?

Actor-network theory provides a conceptual and practical approach to understanding and modeling why design takes specific forms – and what needs to be “undone” for a design to be conceived differently than in the past [3]. It provides a rationale for understanding technology as a network actor in its own right, influencing behavior and constraining discovery. The assumptional frameworks embedded in – for example – a software book-pricing application will direct the evaluation of price alternatives in ways that reflects the model of decision-making adopted by the software’s author. This results in the type of stupid automaticity that recently saw an Amazon book priced at $23,698,655.93 (plus $3.99 shipping). The cause of this pricing glitch was traced back to an actor-network of two competing sellers, unknowingly connected via their use of the same automated pricing software [4].

A lot of the “materiality of practice” literature has identified new phenomena and new mechanisms of actor-networks, by exploring material (non-human) resources. For example Knorr Cetina (1999) has sensitized us to how epistemology is embedded in socio-technical networks. Rheinberger (1997) has demonstrated how some technical objects are associated with emergence while others enforce standardization around a prescribed framework or process. Henderson (1999) demonstrates how the use of specific representations can conscript others around the norms of an organizational power-group (e.g. IT developers who priorititize technical requirements over usability).

These effects can be understood by using Actor-Network Theory as the epistemology underlying analysis of a design’s evolution. Exploring actor-network interactions reveals mechanisms that are relevant to how we work today.

For further reading, I would strongly recommend Bruno Latour’s (2005) book, Reassembling The Social.

Notes:

[1] I have to declare an interest here – this comment was contained in a review of one of my papers … 🙂

[2] As Latour (1992) argues: “Following Madeleine Akrich’s lead (Akrich 1992), we will speak only in terms of scripts or scenes or scenarios … played by human or nonhuman actants, which may be either figurative or nonfigurative.”

[3] One of my favorite papers on the topic of irreversibility in design is ‘How The Refrigerator Got Its Hum,’ by Ruth Cowan (1995). Another good read is the introduction to the same book by MacKenzie and Wajcman (1999).

[4] The amusing outcome is recounted by Michael Eisen, at http://www.michaeleisen.org/blog/?p=358

References:

Akrich, M. 1992. The De-Scription Of Technical Objects. W.E. Bijker, J. Law, eds. Shaping Technology/Building Society: Studies In Sociotechnical Change. MIT Press, Cambridge, MA, 205-224.

Callon, M. 1986. “Some elements of a sociology of translation: domestication of the scallops and the fishermen of St Brieuc Bay.” J. Law, ed. Power, Action, and Belief: a New Sociology of Knowledge? Socioogical Review Monograph 32. Routledge and Kegan Paul, London, 196-233.

Cowan, R.S. 1995. “How the Refrigerator Got its Hum.” D. Mackenzie, J. Wajcman, eds. The Social Shaping of Technology. Open University Press, Buckingham UK, 281-300.

Henderson, K. 1999. On Line and on Paper: Visual Representations, Visual Culture,and Computer Graphics in Design Engineering. MIT Press, Harvard MA.

Knorr Cetina, K.D. 1999. Epistemic Cultures: How the Sciences Make Knowledge. Harvard Univ. Press, Cambridge, MA.

Latour, B. 1987. Science in Action. Harvard University Press, Cambridge MA.

Latour, B. 1992. “Where Are the Missing Masses? The Sociology of a Few Mundane Artifacts.” W.E. Bijker, J. Law, eds. Shaping Technology/Building Society: Studies In Sociotechnical Change. MIT Press, Cambridge MA.

Latour, B. 1999. “On Recalling ANT.” J. Law, J. Hassard, eds. Actor Network and After. Blackwell, Oxford, UK 15-25.

Law, J. 1987. “Technology and Heterogeneous Engineering – The Case Of Portugese Expansion.” W.E. Bijker, T.P. Hughes, T.J. Pinch, eds. The Social Construction of Technological Systems: New Directions in the Sociology and History of Technology. MIT Press, Cambridge MA.

MacKenzie, D.A., J. Wajcman. 1999. Introductory Essay. D.A. Mackenzie, J. Wajcman, eds. The Social Shaping Of Technology, 2nd. ed. Open University Press, Milton Keynes UK, 3-27.

Orlikowski, W. 2010. “The sociomateriality of organisational life: considering technology in management research.” Cambridge Journal of Economics 34(1) 125-141.
Rheinberger, H.-J. 1997. Experimental Systems and Epistemic Things Toward a History of Epistemic Things: Synthesizing Proteins in the Test Tube. Stanford University Press, Stanford CA, 24-37.

Volkoff, O., D.M. Strong, M.B. Elmes. 2007. “Technological Embeddedness and Organizational Change.” Organization Science 18(5) 832-848.

September 23, 2013