Category: Uncategorized

  • User-Centered Vs. Human-Centered Design

    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.

  • Coordination, Cooperation, and Collaboration

    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.

    CCC2

    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.

    Coordination schema, where sub-goals are merged to achieve an integrated outcome

    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.