Author: Susan

Socio-Technical System Design

Origins of Human-Centered Design

A few years ago, I wrote a paper on user-centered vs. human-centered design. I compared HCI analytic methods for user-centered design to a concept of human-centered design that came out of industrial engineering. 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.

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 Systems 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 was inspired by the Soft Systems Methodology approach of Peter Checkland (1981). Checkland 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, 1981; Winter, Brown, & Checkland, 1995). Socio-technical systems design balances the needs of the systems of purposeful human-activity (work or play) in which various people engage, and the supporting system of information technology and user experience design that makes those activities possible.

References

Checkland, P. (1981) Systems Thinking, Systems Practice, John Wiley & Sons, Chichester.

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.

November 4, 2025
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, 2025
Wicked Problems

What are Wicked Problems?

A wicked problem is one that is just too complex and messy (comprising multiple problem-elements) to be easily defined. As it can’t be defined, it can’t be resolved using regular analysis methods, such as those used to generate IT system requirements. Different stakeholders will define the problem in different ways, depending on the parts they have encountered in their work. The emergence of multiple problem-definitions as the problem is explored distinguishes “wicked” problems from the “tame” problems that organizational analysts and IT systems developers typically deal with. While tame problems can be defined in terms of goals, rules, and relate to a clear scope of action, wicked problems consist of many, interrelated problems, each with its own organizational scope and goals. Because so many different stakeholders are involved, each with their own set of problems, wicked problems — and the problem-situation in which they exist — are structured in ways that complicate problem-solving.

Ten Aspects of How Wicked Problems Complicate Problem-Solving

As a result, solutions to wicked problems have vague, emergent goals and boundaries. Ways of framing wicked problems are negotiated among stakeholders who hold radically different views of the organization (Rittel & Webber, 1973).

“It comes as no particular surprise to discover that a scientist formulates problems in a way which requires for their solution just those techniques in which he himself is especially skilled.”
Kaplan, Abraham (1964) “The Age of the Symbol—A Philosophy of Library Education” The Library Quarterly: Information, Community, Policy, Oct., 1964, Vol. 34, No. 4 (Oct., 1964), pp. 295-304

Organizational Problems = Wicked Problems

Wicked problems present as tangles of interrelated problems, or “messes” (Ackoff, 1974). Because these problems are so messy, they are defined by various stakeholders in multiple ways, depending on the parts that they perceive — which in turn depends on where they are in the organization, their experience and their disciplinary background.

If you try to model a complex problem-situation, you will rapidly discover that any “system” of work consists of subsystems, the definition and scope of which depends on where the definer stands in the organization. To act upon a wicked problem, you need to understand the multiplicity of perspectives that various stakeholders take. Often, a single person will hold multiple perspectives depending on the role they are playing at any point in time. For example, I trained as an engineer, I was introduced to systemic analysis during my education, and I adopted a social science perspective as an academic. So I can happily (and obliviously) define any situation in three different ways, depending on which “hat” I am wearing when I do so!

Wicked problems are so-called because they are not “well-structured” – that is, amenable to analytical methods of problem-solving. This means that analysts often experience difficulty in defining the problem that needs solving or selecting an appropriate technique to model the problem.

“Successful problem solving requires finding the right solution to the right problem. We fail more often because we solve the wrong problem than because we get the wrong solution to the right problem.”
Russel Ackoff (1974) Redesigning the Future. ‎Wiley.

We need to use systems thinking (a.k.a. systemic analysis) to resolve wicked problems. Systemic analysis methods use a “divide-and-conquer” approach to exploring problems. Various subsets of problems prioritized by different stakeholders need to be explored and debated across the wider group of change managers. Goals and potential solutions emerge as “the problem” is framed and re-framed in multiple ways over time, as the group of managers and analysts explore different stakeholder perspectives. This process results in organizational learning, as stakeholders acquire an improved understanding of others’ perspectives across organizational functions and boundaries.

By understanding how various parts of “the problem” are structured, change managers and analysts can appreciate how different stakeholder perspectives complement or conflict with each other – and also to explore the “knock-on” impacts of change, allowing them to appreciate conflicts and tradeoffs between perspectives and to predict the impact of changes to one area of the organization on other areas and functions.

Wicked Problems Require Systemic Analysis

As a result, Wicked Problems have a number of characteristics not found in the sorts of problems for which professional analysts and change-agents are typically trained. They are solved by trial and error, rely more on problem-negotiation than analysis, and need to be investigated, rather than analyzed. Any analysis imposes a model or structure that includes some aspects of the situation and excludes others, imposing an expectation that the elements found will be related in specific ways:

“… it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.”
Maslow, Abraham Harold (1966). The Psychology of Science: A Reconnaissance. Harper & Row.

The bottom line is that, while most analysis approaches focus on the form of the solution, wicked problem analysis needs to investigate the nature and scope of the problem. Successful resolution of wicked problems requires appreciative design techniques (Vickers, 1968), where the definition of a solution emerges in tandem with the definition of the problem. Analysts must become enculturated in the problem-situation to understand the stakeholder perspectives that drive various definitions of wicked problems. They need to be familiar with systemic analysis of problems . Plus, they need to be good facilitators, capable of negotiating solutions across multiple stakeholders, with multiple viewpoints and priorities.

References

Mitroff, I.I., Kilmann, R.H. (2021). Wicked Messes: The Ultimate Challenge to Reality. In: The Psychodynamics of Enlightened Leadership. Management, Change, Strategy and Positive Leadership. Springer, Champaign. https://doi.org/10.1007/978-3-030-71764-3_3

Pickering, Andrew (1995) The Mangle of Practice. University of Chicago Press, Chicago IL.

Rittel, H. W. J. (1972). Second Generation Design Methods. Design Methods Group 5th Anniversary Report: 5-10. DMG Occasional Paper 1. Reprinted in N. Cross (Ed.) 1984. Developments in Design Methodology, J. Wiley & Sons, Chichester: 317-327.: Reprinted in N. Cross (ed.), Developments in Design Methodology, J. Wiley & Sons, Chichester, 1984, pp. 317-327.

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

Vickers G. (1968) Value Systems and Social Process. Tavistock, London UK.

September 19, 2025
Appreciative Design & Soft Systems

Appreciating The Context of Organizational Activity

Human-centered design requires that we understand – or rather, appreciate – the need for changes to a “real-world” situation that is viewed as a governed by business logic and goals – rather than the engineering logic employed for IT system requirements. The intention is to improve how we understand the need for change – and the systemic impacts of making changes – through an iterative learning process based on Vickers’ concept of Appreciative Systems (Vickers, 1968; Checkland, 2000b).

Geoffrey Vickers observed the diversity of norms, relationships, and experiential perspectives among those involved in, or affected by, a system of human-activity such as that found in business work-organizations. He argued that organizational change analysts needed methods for analysis that explored how to reconcile these perspectives, developing the concept of an “appreciative system,” the set of iterative interactions by which members of an organization explore, interpret, and make collective sense of their shared organizational reality (Vickers, 1968).

The Concept of an Appreciative System Source: Checkland and Casar (1986), via Checkland (2000b)

Vickers conceptualized organizational work as a stream, or flux, or events and ideas that were interpreted by participants in the organization by means of local “standards,” reflecting shared interpretation schema and sociocultural values (Checkland and Casar, 1986). Interpretations of new events and ideas are subject to the experiential learning that resulted from prior encounters with similar phenomena; these will vary across stakeholders, depending on how they interpret the purpose of the system of work-activity. To achieve substantive change, we need to understand and reconcile these multiple purposes, integrating requirements for change across the multiple system perspectives espoused by various stakeholders. These are separated out into distinct perspectives, which model subsets of activity that are related to a specific purpose or group of participants in the problem situation (Checkland, 1979, 2000b).

Real-World Analysis Vs. Systems Thinking About the Real World

While both real-world analysis and systems thinking about the real world aim to produce representations of complex situations, the key difference lies in their focus: real-world analysis primarily examines data from actual scenarios to identify patterns of human-activity, relationships between actors, and issues that affect performance, whereas systems thinking takes a broader view by considering the interconnectedness of elements within a system, analyzing how they interact and influence each other to understand the big picture – and to engage in debate about how it may be improved.

The concept of appreciative design underpins Soft Systems Methodology (SSM), an approach devised by Dr. Peter Checkland of Lancaster University in the UK, to capture and make sense of complex change requirements across multiple goals for change and the multiple rationales that underpin any organizational system of work-activity. SSM is now a highly-regarded approach to managing complex change, especially suited to the untangling of “wicked problems” (Rittel, 1972). Its contribution is to separate the analysis of “soft systems” of human-activity – what people do in their work and the logic that makes sense of that activity – from the “hard system” of IT and engineering logic that usually underpins system requirements.

Soft Systems Methodology (SSM)

The development of integrative system thinking methods and analysis techniques to solve ill-structured, “soft” problems is Checkland’s (1979) contribution to the fields of change management and systems analysis. Soft Systems Methodology (SSM) provides a method for participatory design centered on human-centered information systems. The analysis tools suggested by the method — which is really a family of methods, rather than a single method in the sense of modeling techniques — permit change-analysts, consultants and researchers to surface and negotiate feasible aspects of change, to explore and reconcile alternative viewpoints, and to anticipate (to some extent) the knock-on effects of changing one part of a complex system of work on other parts of this system.

Problems are ultimately subjective: we select things to include and things to exclude from our problem analysis (the “system boundary”). But real-world problems are wicked problems, consisting of interrelated sub-problems that cannot be disentangled — and therefore cannot be defined objectively (Rittel, 1972). The best we can do is to define problems that are related to the various purposes that participants pursue, in performing their work. By solving one problem, we often make another problem worse, or complicate matters in some way. Systemic thinking attempts to understand the interrelatedness of problems and goals by separating them out.

In understanding different sets of activities and the problems pertaining to those activities as conceptually-separated models, we understand also the complexity of the whole “system” of work and the interrelatedness of things – at least, to some extent. It is important to understand that, given the evolving nature of organizational work, a great deal of the value of this approach lies in the collective learning achieved by involving actors in the situation in analyzing changes, and that this approach in inquiry is, in principle, never ending. It is best conducted with and by problem-situation participants (Checkland, 2000b).

Summary

To summarize, appreciative design is an approach where emergent perspectives on what a “system” of work should achieve and how that work should be performed are modeled to produce actionable changes to the system that can be evaluated around agreed standards of performance and that preserve desired relationships between human actors and between elements of work-activity and their outcomes. This approach to modeling work-systems influenced the development of Soft Systems Methodology (Checkland, 2000b), a method to operationalize the representation and negotiation of systems of purposeful human-activity around which desirable and feasible changes can be identified and implemented.

References

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

Checkland P., Casar A. (1986) Vickers’ concept of an appreciative system: A systemic account. Journal of Applied Systems Analysis 13: 3-17

Checkland, P. (2000a) New maps of knowledge. Some animadversions (friendly) on: science (reductionist), social science (hermeneutic), research (unmanageable) and universities (unmanaged). Systems Research and Behavioural Science, 17(S1), pages S59-S75. http://www3.interscience.wiley.com/journal/75502924/abstract

Checkland, P. (2000b). Soft systems methodology: a thirty year retrospective. Systems Research and Behavioral Science, 17: S11-S58.

Checkland, P., Poulter, J. (2006) Learning for Action: A Short Definitive Account of Soft Systems Methodology and its Use, for Practitioners, Teachers and Students. John Wiley and Sons Ltd. Chichester UK. ISBN: 0-470-02554-9.

Rittel, H. W. J. (1972). Second Generation Design Methods. Design Methods Group 5th Anniversary Report: 5-10. DMG Occasional Paper 1. Reprinted in N. Cross (Ed.) 1984. Developments in Design Methodology, J. Wiley & Sons, Chichester: 317-327.: Reprinted in N. Cross (ed.), Developments in Design Methodology, J. Wiley & Sons, Chichester, 1984, pp. 317-327.

Vickers G. (1968) Value Systems and Social Process. Tavistock, London UK.

August 19, 2025
Why Is Design Improvisational?

The focus of IS design has moved “upstream” of the waterfall model, from technical design to the co-design of business-processes and IT systems. This focus requires an improvisational design approach. IT-related organizational innovation deals with wicked problems. Wicked problems tend to span functional and organizational boundaries as business process and information management problems are intertwined. There are clusters of interrelated problems: these cannot be defined objectively because the problem is defined differently, depending on who you ask. IS designers cannot analyze this type of problem in isolation – we need to involve diverse groups of stakeholders in negotiating suitable problem definitions and boundaries for change. But wicked problems also involve distributed knowledge, where understanding of the problems is stretched across (rather than shared between) stakeholders. So design goals evolve, as designers and stakeholders learn more about the context and the problems facing the organization by engaging in incremental change. This is often approached by means of agile design methods. But our lack of understanding about how to establish a “common language” for this type of design means that information system innovation tends to be pretty hit-and-miss. Most design initiatives spend more time arguing about process definitions than achieving change.

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

April 25, 2025
The Relevance of Actor-Network Theory

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? It 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 for action 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].

Finally, I want to observe that a lot of the recent “materiality of practice” literature has identified new phenomena and new mechanisms of actor-networks. For example Knorr Cetina (1999) has sensitized us to how epistemology is embedded in socio-technical assemblages, Rheinberger (1997) has demonstrated how some technical objects are associated with emergence while others enforce standardization and Henderson (1999) demonstrates how the use of specific representations can conscript others around an organizational power-base. But I would argue that these effects can be understood by using Actor-Network Theory as one’s underpinning epistemology – and that exploring actor-network interactions continues to reveal ever newer mechanisms that are relevant to how we work today. I would strongly recommend Bruno Latour’s latest 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 12, 2024
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, 2024
Organizational Forms Of Coordination
I have been working for a while on comparing the results from some very complex research studies of collaborative design in groups that span disciplines or knowledge domains. I was stunned to realize that I had different types of group activity depending on the sort of organization.

By “organization,” I mean the way in which work is organized, not the sort of business they are in. I noted three types or organization, that seem to respond to collaboration in different ways:
- Tightly-coupled work organizations rely on well-defined work roles and responsibilities to coordinate tasks across group members. When people in this sort of group have to make decisions, they partition these decisions, based on expertise. Because they all know each others’ capabilities and roles, they don’t have to think about who-knows-what: this is just obvious. This type of organization falls down when people don’t perform their role reliably. For example, if the whole system relies on accurate information coming into the group, someone who misinterprets what they observed can undermine the whole group system.
- Event-driven organizations rely on external crises and pressures to coordinate group action. People in this sort of group have strongly-defined roles in the wider organization that take precedence over their role in the group — for example in management taskforce groups, business managers tend to prioritize their other work over problems that the group needs to fix. When people in this sort of group make decisions, they partition these decisions according to who-claims-to-know-what, who has time to do the work, and who knows people connected to the problem. They get to know each others’ capabilities over time, but this is a slow process as priorities and decisions are driven by external events, rather than a shared perception of what needs to be done. This type of organization falls down when decisions or actions that were put on a back burner because of another crisis inevitably become a crisis themselves because they were not followed through.
- Loosely-coupled organizations rely on ad hoc work roles and cooperation among group members. This type of group is commonest in business process change groups, professional work-groups, and community groups, where people are there because they share an interest in the outcome. When people in this sort of group make decisions, they partition these decisions according to who can leverage external connections to find things out and who has an interest in exploring what is involved. People often share responsibilities in these groups, comparing notes to learn about the situation. This type of organization falls down because it is hard to coordinate. So shared tasks are performed badly because someone knew something vital that they failed to communicate back to the group.
Managing group collaboration can be like taming wild horses

Why would we care about these different types of organization? Well these structures affect how we approach problem-solving and design. If we (process and IS analysts) need to work with one of the tightly-coupled work-groups, we need to identify who has the decision-making capability for what. It would not occur to a tightly-coupled group member that anyone would not realize who to go to for what. If we need to work with an event-driven group, we have to realize that our work will not be a priority for them — it must be made a priority by gaining an influential sponsor who can kick a$$ within the group(!). If we work with a loosely-coupled group, we need to engage the interest of the group as a whole. Working with individuals can lead to failure, as this type of group makes decisions collaboratively, not on the basis of knowledge or expertise.

I have a fair amount of evidence for this line of thought and I am pursuing other factors that make these groups different. More to follow …
February 25, 2024
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.” But Bricolage is not random experimentation. It is based on leveraging the world “as defined by the situation” (Ciborra, 2002). Pattern sensitization adds another dimension to bricolage. It 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.

The Process of Bricolage

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

January 16, 2024
Design as the Serendipity of Location
As I ruminate on design processes, I can’t help but reflect on the similarities between research methods, processes and outcomes, and design methods, processes and outcomes. I read an article which argued that there were two types of people: people with tidy offices and people with untidy offices¹. Tidy-office people are organized and so can find anything they need. These are the people who work top-down, creating an outline then writing or designing according to that scheme. Untidy-office people are disorganized, spend a great deal of time searching for things, but also tend to be more creative because they are inspired by things which they bump into, while looking for other things. These people work bottom-up, assembling elements into a coherent whole. The article argued that there are cognitive rewards in both styles of working, that lead people to subconsciously adopt one or the other style consistently.

I was reflecting on this as I try to make sense of the piles of material that I have assembled for the book. I am definitely an untidy-office type and I wonder if this has something to do with introvert/extrovert personalities? [My project management students and I just explored an online Myers-Briggs personality test; as expected, I was an INTP type.] Perhaps introverts just prefer a “life of the mind,” where we can construct inductive models of the real world?².

My semi-organized and shifting piles of research data, models and representations, interim findings, academic articles, and books provide a three-dimensional, systemic representation of design processes that can be reorganized as I comprehend different patterns. Of course, they are both preceded and supplemented by painstaking (and frequently revisited) processes of categorization, synthesis, and validation. But the kaleidoscope of patterns that they reflect is invaluable in suggesting different views of my findings. The same is true for design – we create the patterns that we perceive as relevant in the problem situation. As our perceptions shift, so do the design patterns that we follow.

I would argue that innovative design is neither deductive or inductive, but consists of cycles of induction and deduction. It follows a hermeneutic circle of sensemaking, as designers attempt to work from problem to solution and to reconcile those fragments of a solution that they understand back to a meaningful problem definition. The combination of deductive and inductive thinking has been described as abductive reasoning, but reasoning about design is more disciplined and rigorous than most descriptions of abduction [a hunch] would indicate. I prefer Thagard and Shelley’s (1997) argument that hypotheses about reality are layered, incomplete, and too complex to be comprehended easily³. Often, the only way to comprehend complex, interrelated elements of behavior and context is to use a visual, systemic representation.

As someone who has spent a good portion of their career as a systems designer, I have never considered design creative. Design is more about synthesizing from preconceived elements than creating from scratch⁴. But I wonder if – just as in research – the greatest inspiration in design derives from the serendipity of location?

Footnotes (click on ↩ to return to post)
1. If anyone knows the reference for this paper, please let me know. I saw an NYT article on the subject, but I can’t locate the academic paper again – which was published in an information science journal, if I recall correctly … ↩
2. There is a neat discussion of deductive vs. inductive reasoning over at the research methods knowledge base. ↩
3. Paul Thagard and Cameron Shelley (1997) “Abductive reasoning: Logic, visual thinking, and coherence.” Available at http://cogsci.uwaterloo.ca/Articles/Pages/%7FAbductive.html (last accessed 11/27/2009). ↩
4. Like sex, design seems to be 30% inspiration and 70% perspiration … ↩
November 27, 2023