Author: Susan

Socio-Technical System Design

Origins of Human-Centered Design

A few years ago, I published an academic paper – which proved to be one of my most-read articles, on user-centered vs. human-centered design. In that paper, I compared the typical analytic methods and tools for user-centered design to an idea of human-centered design that came out of the field 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.

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, 1981; Winter, Brown, & Checkland, 1995).

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.

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
User-Centered Vs. Human-Centered Design
In the last few years, the terms human-centered and user-centered have become synonymous in HCI, with a focus on disciplines such as “user experience” and “interaction design.” Here I will argue that neither discipline really deals with the core issues of human-centered design.

Human-centeredness in design involves designing artifacts and technology support environments that provide a “support system” to the humans performing specific work, applying their effort to achieving specific goals, or collaborating around a set of (more or less) well-defined aims. The human is seldom alone in these endeavors. They engage with others in a social network of communications and collaborative actions, they socialize and exchange ideas, and they work together purposefully. A better description than “user” to describe the context of use for the artifacts and environments which we design would be “human-activity system.” As humans, we are thrown into a world of work and activity by others, which we can take control of through action (Heidegger, 1967). We can support this world by understanding the various purposes of human activity and designing technology to assist in those purposes (Checkland & Winter, 2000) . So human-centered design is systemic: it appreciates the social and organizational context of work and it supports the multivocal purposes of the system of human activity, within its context.

User-centeredness by contrast is isolationist in its focus on interaction design. It takes a human being, rich in purpose and understanding, and reduces them to the role of artifact user. Not only that, but by implication, the user of a pre-defined artifact, whose purpose is understood, but whose mechanisms of interaction remain to be fully defined. By focusing on conceptual models of use, user scripts, and activity/task frameworks (e.g. Sharp et al. 2019), it isolates the user from the social context of work, describing activities in terms of fixed procedures and embedding assumptions about how and why the artifact will be used. It loses the joyful multivocality of the human-centered approach to design. Instead of understanding, with Heidegger, that thrownness is a temporary state, where there is a choice between reaction or being proactive, user-centered design embeds reaction as a paradigm. It separates tasks from workflows, making each interaction an end in itself and enforcing the approach to design that led Lucy Suchman to write her famous treatise on situated design (Suchman, 1987). There is no linked flow of work processes, where the human being knows that (for example) they have already photocopied the report covers (onto special cardstock) and the early chapters, so now have only to copy later chapters. There is the dumb lack-of-saved-status machine, which jams halfway, then asks the user to reload the report pages in their original order, starting with the covers which need the user to load special cardstock into the paper feeder.

Designing for humans rather than users is a choice.
- It involves more complex and realistic state machines, which account for multiple stages of linked workflow, supported by multiple sets of machine interactions.
- It involves a conscious decision to support informal communications and activities – for example, water-cooler conversations or phone calls, which may or may not result in recorded outcomes.
- It treats the participants in a human activity system as autonomous individuals, not agents to be modeled, controlled, and curtailed.
- It recognizes that a social system of information exchange exists, of which the machine is only a part – and that humans need to exercise a deliberative choice about what to record and why – and that any computer-based system of data is part of a wider, human-network-based system of information.
- Above all, it acknowledges that knowledge, understanding, and the meanings that we ascribe to work are emergent. We understand how to do things by doing them – after which we have a better understanding of how to do them next time. Embedding any particular set of procedures into a computer-based system is not only a waste of time, but may be counterproductive, in the face of new ways of proceeding.
So no – “user experience” and “interaction design” do not support human-centered information system design. They seek to humanize the artificial processes imposed by transaction-based systems through associating these with specific paradigms or conceptual models that guide the psychology of human activity and interaction. But they don’t even scratch the surface of understanding systemic activity. For that, you need to employ methods such as Soft Systems Analysis (Checkland & Poulter, 2007) – and to take human-centeredness seriously.

User-centered design is NOT the same as human-centered design. User-centered design focuses on ameliorating design decisions already made, to define IT & data use around the needs of notional “business goals.” Human-centered design focuses design on the needs of people engaged in purposeful activities aimed at a variety of goals.

To conclude, user-centered design – as the term is employed in HCI and UX – is not the same as human-centered design. User-centered design is aimed at mitigating and improving the experience of using a system of technology that was designed for another purpose than those the user prioritizes – to make money, to “engage” users on the website so they return (and spend more money), and to publicize the firm’s products and services. In contrast, human-centered design is an approach that starts with user values, priorities, and purposes. It seeks to afford uses of the system that fulfill how the user would like to access the features that they value and expect. It designs the flow of use-interactions around the expected user flow of work (or play), allowing the user to configure this flow how they want. It does not make you do illogical or stupid things, like reloading all the sheets in a photocopier feed in their original order, even when the copy failed on the last-page-but one. It does not make you enter the same information repeatedly, because the designer was too unimaginative to anticipate that a user might want to change some of the options they had selected earlier (e.g. when booking an airline ticket). And it doesn’t make you go through seven layers of a menu to reach the one page you need.

Human-centered design is performed by people who talk to users, learn to think like users, and walk alongside them in their work. These designers not only prototype and evaluate their designs, but also listen to the feedback they are given. They value user input and see it an critical to their portfolio of design experience. In the design literature of the 1980s there was a lot of discussion of how user representatives would “go native,” when participating in design projects, learning to think like designers and subsuming the interests of their fellow users in the process. In the 2020s, we need to see more IT designers going native, learning to think like users, reworking IT system designs to support how users work, and valuing the aspects of system design that users value. That is human-centered design.

References

Checkland, P. & Winter, M.C. 2000) “The relevance of soft systems thinking,” Human Resource Development International (3:3), pp. 411-417.

Checkland, P. and Poulter, J. (2007) Learning For Action: A Short Definitive Account of Soft Systems Methodology, and its use for Practitioners, Teachers and Students, Wiley, UK

Heidegger, M. 1962. Being and Time New York NY.: Harper & Row New York, 1962.

Sharp, H., Preece, J. & Rogers, Y. (2019) Interaction Design: Beyond Human-Computer Interaction 5th Edition, Wiley, UK

Suchman, L. 1987. Plans and situated action Cambridge, UK: Cambridge University Press, 2007.
August 15, 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

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
The Co-Design of Business & IT Systems

Business analysts, change managers, and IT systems analysts are in a no-win situation. They are expected to understand myriad interpretations of the business strategy, reconcile conflicting viewpoints on how business processes work, and – somehow – define a coherent set of change objectives that pleases everyone. While the stakeholders of change each understand only a fraction of what the business does.

The co-design of business & IT systems is like piecing together a jigsaw puzzle without the picture. You get an edge here and there, part of a building outline, or a connecting feature, but mainly you are assembling bits and pieces that are tacked together in whatever way makes sense at the time. Most people fudge this by kludging viewpoints together under a single goal, with multiple objectives that reflect the main things that stakeholders seem to value. Objectives move in and out of the picture, as the focus shifts. Analysts have to understand multiple business domains, as stakeholders pull in different directions like the wild horses in the site header. Even business managers don’t really understand their processes – and know very little of the processes they interface with. Conflicts, priorities, and omissions in change objectives are seldom realized as current analysis methods don’t provide ways to map out the full scope of change, or to present this to business managers for input.

Systemic analysis uses a divide-and-conquer strategy. The parts of the jigsaw puzzle are assembled separately, then the analyst can piece together the whole. Conflicts, priorities, and omissions from the change requirements become obvious because of the way in which the whole picture is explored. This allows the change analyst and — more importantly — the managers, system users, victims, and beneficiaries of change to understand the scope and priorities of what will change.

This website provides a tour of how to perform a systemic analysis of requirements for change in business organizations (nonprofit and for-profit). It deals with how to get groups of people, who come from very different backgrounds, on the same page – talking a common language for the co-design of business and IT systems.

December 7, 2014
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
On Realizing 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 23, 2013
Designing Social Media Platforms For Online Learning

Recently, I have been using a new social media platform to run one of my classes. The idea was, that as we are studying social informatics, we could study the effect of using social media on our own workflows first hand. I also thought that – in these days of daily Facebook and Twitter use – a social media site would add some relevance to the class. My thinking was that the “right-brain” expression that Daniel Pink extolls as critical to motivation in the 21st Century – the design, narrative, synthesis, empathy, play and sensemaking skills – would be enabled by the use of social media (Pink, 2005). The site has a WIKI, blogs, discussion forums, and an interactive chat facility. I was proposing that we used Google+ hangout for short class discussions by video. For the first week, I set students the task to post to the WIKI, to post to their own blog, to locate some web readings, and to join Google+ if they had not already done so.

By Thursday (from a Monday start), almost all of the students had posted to the discussion forum. Several had asked me questions by email. But no-one had posted to the Blog or the WIKI. By Friday, two of the more technologically-literate students had made blog posts. But most of the activity was still on the discussion forums – and only three students had provided me with Google+ contact details. Then I started to question my own assumptions. All of the students had used Blackboard for their online course access, which revolves around an asynchronous discussion board. So they were used to interacting via an asynchronous forum. I had assumed that they would be excited to use more “social” media for class interactions or for sharing what they had discovered about the topic. But how did this fit into their idea of how they would behave in an online class? Very badly. Most students sign up for online courses because this provides them with choices about what to do, when. They have a low learning-curve for using a discussion forum. Anything else is hard work.

Clay Shirky talks about the cognitive surplus that is available from zillions of digitally-literate people with mundane jobs and untapped creativity. He argues that this expresses itself in the groundswell of free, open source software initiatives and in the crowdsourcing phenomenon (Shirky, 2010). But graduate students with a full-time job are already using their cognitive surplus in grappling with new areas of learning. My assumption that they may have some left over for experimenting with social media may be false. The problem is that the learning curve gets in the way of the “right-brain” expression that I wanted to encourage. I may need to rethink how far experimenting with social media is constraining people’s’ ability to express themselves.

References
Daniel Pink (2005) A Whole New Mind: Why Right-Brainers Will Rule the Future. Berkely Publishing: New York.
Pink (2005) Revenge Of The Right Brain, Wired Magazine, Feb. 2005.
Clay Shirky (2010) Cognitive Surplus: Creativity and Generosity in a Connected Age, Penguin Press: New York.
Clay SHirky (2010) An Extract From Cognitive Surplus. Wired Magazine, Business Video, June 16, 2010.
Clay Shirky and Daniel Pink (2010) Cognitive Surplus: The Great Spare-Time Revolution. Wired Magazine, June 2010.

January 14, 2012