Wild horses sculpture at Drexel

Category: human-centered design

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

    Diagram showing investigation of a complex, real-world situation vs constructing models that represent the real world
    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.

  • Human-Centered Design

    In the last few years, the terms human-centered and user-centered have become synonymous in HCI and IT design, 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 technology artifacts, applications, and platforms that provide a “support system” to people performing specific work or play activities as individuals, or collaborating around a set of (more or less) well-defined aims – often messily and exploratively. Asking people to describe their requirements for technology to support them in their activity doesn’t work because no-body really stops top think about how they work, or what they do to achieve a goal. When they are forced to do so, they will describe how work should be done – the formal system of procedures and rules – rather than how it is done – the informal, socially-situated system that makes work activities fit with their environment and the objectives that people have.

    People are seldom alone in what they do, even when engaging in individual activity. They socialize with other people and exchange ideas, they seek advice on how to proceed, and they collaborate to achieve shared – or similar – goals. When confronted with a novel problem, most people turn to a “small world” network of trusted social contacts for input – people who share their values and perspectives – rather than conducting a wider search that includes subject experts and knowledge resources (Chatman, 1991). Even when working alone, we are never truly alone. We are thrown into a working environment that existed before we joined – a self-contained world of work and social activity that we can only understand through participation (Weick, 2004). Professionalism and practice in one organization are completely different to the practices and standards applied in another.

    When we try to understand the “user” of a software application or system, we often fail miserably because we only see the formal work activities that they perform. We miss the web of activities that their formal activity is a part of – the multiple other human-activity systems they interact with, to get things done.  User-experience design is reductionist 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 for work-analysis e.g. Sharp, Preece, and Rogers (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 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, 2007). 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. Which they already did.

    We can support this world by understanding the various purposes of human activity and designing technology to assist in those purposes (Checkland and Winter, 2000). Human-centered design differs from user-centeredness by being systemic and multi-vocal: it is aware of the multiple networks of activity in which a human technology user engages, simultaneously. Unlike user-centered design, which focuses on a single, definable work-goal, human-centered design appreciates the multiple goals that people pursue simultaneously, for different purposes. Human-centered design appreciates the social and organizational context of work, employing analytical approaches and methods that explore the complexity of the activities that we do – and the social networks we inhabit to do them.

    Designing for humans rather than users is a choice:

    • Human-centered design explores the multiple, purposeful systems of human-activity that are required to achieve even simple work (or play) goals.
    • It treats the participants in a human activity system as autonomous individuals, not agents to be modeled, controlled, and curtailed. Human-centered design respects and supports the local knowledge required to act skillfully, using local knowledge and various forms of tacit or implicit knowledge to perform work that is often not recognized as knowledge work.
    • It recognizes that a social system of information exchange exists, of which the designed technology artifact or software is only a part, and that humans need to exercise a deliberative choice about what to record and why. Any computer-based system of data is part of a wider, human-network-based system of information.
    • Because it appreciates work as part of a wider social system,  human-centered design involves a conscious decision to support the informal communications and activities that keep the system of work connected and informed – for example, water-cooler conversations or phone calls. These informal channels produce more knowledgeable participants in the system of work, rather than resulting in recorded data records or written resources. They are often omitted from – or worse, designed out of – the formal system of “user experience design.”
    • 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, then reflecting on what we did and how – after which we have a better understanding of how to do them next time. Designing any particular set of procedures into a computer-based system is not only a waste of time, but may be counterproductive, as we constantly improvise and improve on how we did things previously (learning-by-doing). Human-centered systems design allows the human to be in control of their work, rather than the IT system.

    So no – “user experience design” and “interaction design” do not support human-centeredness in work (or play). They seek to humanize the artificial processes imposed by transaction-based systems by associating these with perspectives that acknowledge the psychology of human activity, learning, and interactions with technology. But they don’t even scratch the surface of understanding situated, systemic activity. For that, you need to employ methods that complicate your perspective, such as Soft Systems Analysis (Checkland, 2000; Checkland and Poulter, 2006) – and to take human-centeredness seriously.

    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

    Chatman, E.A. 1991 “Life in a Small World: Applicability of Gratification Theory to Information-Seeking Behavior,” Journal of the American Society for Information Science (42:6), pp. 438–449.

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

    Checkland, P., and Poulter, J. 2006. Learning For Action: A Short Definitive Account of Soft Systems Methodology, and its use Practitioners, Teachers and Students Chichester: John Wiley and Sons Ltd, 2006.

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

    Sharp, H., Preece, J., and Rogers, Y. 2019. Interaction Design: Beyond Human-Computer Interaction, 5th EditionWiley, UK, 2019.

    Suchman, L. 1987. Plans And Situated Action Cambridge MA: Cambridge University Press, 1987.

    Suchman, L. 2007. Human–machine reconfigurations: Plans and situated actions Cambridge, UK: Cambridge University Press, 2007.

    Weick, K.E. 2004. “Designing For Throwness,” in: Managing as Designing, R. Boland, J and F. Collopy (eds.), Stanford CA: Stanford Uniersity Press, pp. 74-78.

    Selected Papers:

    Gasson, S. (2008) ‘A Framework For The Co-Design of Business and IT Systems,’ Proceedings of Hawaii Intl. Conference on System Sciences (HICSS-41), 7-10 Jan. 2008. Knowledge Management for Creativity and Innovation minitrack, p348.  http://doi.ieeecomputersociety.org/10.1109/HICSS.2008.20.

    Gasson, S. (2005) ‘Boundary-Spanning Knowledge-Sharing In E-Collaboration’ in Proceedings of Hawaii Intl. Conf. on System Sciences (HICSS-38), Jan. 2005. http://doi.ieeecomputersociety.org/10.1109/HICSS.2005.123

    Gasson, S. (2003) ‘Human-Centered vs. User-Centered Approaches To Information System Design‘, Journal of Information Technology Theory and Application (JITTA), 5 (2), pp. 29-46.

    Gasson, S. (1999) ‘A Social Action Model of Information Systems Design’, The Data Base For Advances In Information Systems, 30 (2), pp. 82-97.

    Gasson, S. (1999) ‘The Reality of User-Centered Design‘, Journal of End User Computing, 11 (4), pp. 3-13.

  • Boundary-Spanning Design

    Boundary-Spanning Design

    We talk about organizational design and change problems as if they were given — as if there is only one problem that could be defined for any situation and only one best way to design a solution. This is far from true. Design is like completing a jigsaw puzzle without the picture on the box. We find a bit of sky and then realize it is, in fact, part of a swimming pool.

    Organizational change, design, and problem-solving depend on pattern recognition. When organizations assemble a team of managers or designers to represent different business groups, each person brings the assumptions of their group culture and “best practices” with them. They are expected to collaborate as if they totally understand every single part of every business practice involved. But there are multiple, interrelated problems involved in any situation and different stakeholders will perceive different problems depending on their background and experience. The key skill is to recognize those problems and tease them apart, dealing with each one separately.

    Organizational problems – whether operational or strategic – typically span organizational boundaries, so the design of business processes and enterprise systems is complicated. Boundary-spanning systems of work need systemic methods and solutions. The point is to understand how collaboration works when people lack a shared context or understanding — and to use design approaches that support collaborative problem investigation, to increase the degree of shared understanding as the basis for consensus and action in organizational change. To enable collaborative visions, people need some point of intersection. In typical collaborations – for example a design group working on change requirements – the “shared vision” looks something like Figure 1.

    Venn diagram, showing intersubjective frames, intersections of understanding between 2 stakeholders, and distributed cognition as the union of all frames

    Figure 1. Differences Between Individual, Shared, and Distributed Understanding In Boundary-Spanning Groups

    The only really shared part of the group vision is the shaded area in the center. The rest is a mixture of partly-understood agreements and consensus that mean different things to different people, depending on their work background, their life experience, education, and the language they have learned to use. For example, accountants use the word “process” totally different to engineers. Psychologists use it to define a different concept from either group. When group members perceive that others are not buying in to the “obvious” consequences of a shared agreement, they think this is political behavior — when in fact, it most likely results from differences in how the situation and group agreements are interpreted.

    Boundary-spanning collaboration is about maximizing the intersections of understanding using techniques such as developing shared representations and prototypes, to test and explore what group members mean by the requirements they suggested. It involves developing group relationships to allow group members to delegate areas of the design to someone they deem knowledgeable and trustworthy. It uses methods to “surface” assumptions and to expose differences in framing, in non-confrontational ways. But most of all, it involves processes to explore group definitions of the change problem, in tandem with emerging solutions. We have understood this for a long time: Enid Mumford, writing in the 1970s and 80s, discussed the importance of design approaches that involved those who worked in the situation, and the need to balance job design and satisfaction with the “bottom line interests” of IT system design (Mumford and Weir 1979; Mumford 2003) – also see Porra & Hirchheim (2007). This theme has been echoed by a succession of design process researchers: Horst Rittell (Rittel 1972; Rittel and Webber 1973), Peter Checkland (1999), and Stanford’s Design Thinking initiative (although “design thinking” tends to be co-opted to focus on “creativity” in interface design, rather than the integrative design approach that may have been envisioned).

    The problem is that most collaboration methods for design of organizational and IT-related change, whether focused on enterprise systems design, business process redesign, cross-functional problem-solving, or IT support for business innovation, employ a decompositional approach. Decomposition fails dramatically because of distributed sensemaking. Group members cannot just share what they know about the problem, because each of them is sensitized by their background and experience to see a different problem (or at least, different aspects of the problem), based on where they are in the organization. Goals for change evolve, as stakeholders piece together what they collectively know about the problem-situation — a process akin to assembling a jigsaw-puzzle. (Productive) conflict and explicit boundary negotiation are avoided because group-members lack a common language for collaboration so misunderstandings are ascribed to political game-playing. We need design and problem-solving approaches that support the distributed knowledge processes underpinning creativity and innovation — approaches that recognize and embrace problem emergence, boundary-negotiation, and the development of shared understanding. This is the core of my work on improvising design.

    References

    Balcaitis, Ramunas 2019. What is Design Thinking? Empathize@IT https://empathizeit.com/what-is-design-thinking/. Accessed 8-15-2023.

    Checkland, P. 1999. Systems Thinking Systems Practice: Includes a 30 Year Retrospective, (2nd. Edition ed.). Chichester UK: John Wiley & Sons.
    [Original edition of this book published in 1981].

    Mumford, E. 2003. Redesigning Human Systems. Hershey, PA: Idea Group.
    Mumford, E. and Weir, M. 1979. Computer Systems in Work Design: The Ethics Method. New York NY: John Wiley.

    Porra, J., & Hirschheim, R. 2007. A lifetime of theory and action on the ethical use of computers: A dialogue with Enid Mumford. Journal of the Association for Information Systems, 8(9), 3.

    Roumani, Nadia 2022. Integrative Design: A Practice to Tackle Complex Challenges, Stanford d.school on Medium, Accessed 8-15-2023.

    Rittel, H.W.J. 1972. “Second Generation Design Methods,” DMG Occasional Paper 1. Reprinted in N. Cross (Ed.) 1984. Developments in Design Methodology, J. Wiley & Sons, Chichester: 317-327.

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

  • Defining Organizational Problems

    The way in which problems are defined is critical to producing a good enough solution. Most people don’t stop to think about the constraints they introduce to problem-solving by defining problems in a certain way.

    • If you ask how something is done (IT requirements analysis), you get a focus on how a solution can support EXISTING processes. This defines the solution only in the vaguest terms.
    • If you ask what is done, you get a focus on how existing processes could be performed, which allows you to examine alternative ways of working and alternative ways of solving the problem. This approach provides more detail, to define the elements and purpose of the solution.

    In the examples that follow, I use an IT system solution, as this illustrates how solution requirements are missed or constrained by ways of defining the problem.

    Example 1 – Focusing On How (A Typical Mistake)

    Element Description
    The problem of … Order processing is too slow and prone to human error because this is done manually.
    Affects … Customers, order processing staff, order fulfillment staff, complaints staff and managers.
    And results in … Orders are not processed in a timely manner, some orders are never dispatched, and some customers receive the wrong items.
    Benefits of a solution … A system to automate order-processing would eliminate errors, provide more time for order processing staff and order fulfillment staff to get on with their work, and increase customer satisfaction, resulting in more business.

    What the system will actually do (its functional purpose) is not defined here – you now need a lot of investigation (and negotiation) to agree what should be involved in automating order processing.

    Example 2 – Focusing On What (Better)

    Element Description
    The problem of … Order processing is too slow and prone to human error because there is no way of recording what has been done, to process an order, and no way of tracking the status of an order.
    Affects … Customers, order processing staff, order fulfillment staff, complaints staff and managers.
    And results in … Orders are not processed in a timely manner, some orders are never dispatched, and some customers receive the wrong items.
    Benefits of a solution … A system to record and track order-processing activities would eliminate errors, provide more time for order processing staff and order fulfillment staff to get on with their work, and increase customer satisfaction, resulting in more business.

    This problem definition hinges on what is not being done properly. The functional purpose of the system is defined by the problem definition – all that remains is to determine how this should be performed by people using an information system.

    Example 3a – Focusing On Parts of “What” (Best) – Part 1

    The best way is to define problems around what people need to do, rather than what the IT system does not do, in supporting them. Then you can think really laterally about whether solving this problem requires work-process changes, IT system changes, or both.

    Element Description
    The problem of … Order processing is too slow and prone to human error because staff are not trained in effective work procedures and lack any formal coordination mechanisms to ensure that they understand and follow best practice.
    Affects … Customers, order processing staff, order fulfillment staff, complaints staff and managers.
    And results in … Customer dissatisfaction – orders are not processed in a timely manner, rush orders are not prioritized, some orders are never dispatched, and some customers receive the wrong items.
    Benefits of a solution … A system to manage and track order-processing activities would ensure that staff process orders effectively, increasing customer satisfaction and resulting in more repeat business.

    Example 3b – Focusing On Parts of “What” (Best) – Part 2

    Element Description
    The problem of … Order processing is too slow and prone to human error because there is no way of recording what has been done, to process an order, and no way of tracking the status of an order.
    Affects … Customers, order processing staff, order fulfillment staff, complaints staff and managers.
    And results in … Customer dissatisfaction – orders are not processed in a timely manner, rush orders are not prioritized, some orders are never dispatched, and some customers receive the wrong items.
    Benefits of a solution … A system to record and track customer orders would flag errors and communicate order priority and progress, allowing problems to be detected before they affect customers.

    Example 3c – Focusing On Parts of “What” (Best) – Part 3

    Element Description
    The problem of … Order processing is too slow and prone to human error because work is poorly coordinated, between departments, and between individual staff.
    Affects … Customers, order processing staff, order fulfillment staff, complaints staff and managers.
    And results in … Customer dissatisfaction – orders are not processed in a timely manner, rush orders are not prioritized, some orders are never dispatched, and some customers receive the wrong items.
    Benefits of a solution … A system to record and target delivery of the information required to process each step of order processing would eliminate errors and communicate work priorities.

    These three problem definitions allow us to specify the (IT system) solution purpose:

    The new system will support order processing and fulfillment activities. Specifically, it will fulfill the following high-level purposes (functions):

    1.The system will coordinate order information between the order processing system and the order fulfillment system, so that orders are scheduled for fulfillment by the expected date of delivery. This is determined by the combination of (i) date of placing order, and (ii) order priority (1-day, 3-day or 4-5 days). Order processing staff will be able to determine and to change the status of an order in case of customer queries.

    2.The system will manage and track order fulfillment processing. The system will signal, through a daily management report and on-screen tracking reports, how many and which orders have not been processed to meet their scheduled delivery date. The main stages of order processing tracked will be: (i) order placement, (ii) order verification against inventory, (iii) customer confirmation of order, (iv) inventory delivery to packing station, (v) order packed, (vi) order delivery to shipping station, (vii) order shipped, (viii) delivery confirmation received.

    3.The system will communicate the information required to process orders effectively. It will provide daily management reports, that summarize the percentage of orders processed on time for expected delivery and that list outstanding orders for immediate action. This report will also be available on request, reflecting real-time order processing and fulfillment status. The system will communicate order processing information to each work-station, on the basis of priority and staff availability.

    Because of their depth, they also allow us to specify the (IT system) solution features:

    The new system will support order processing and fulfillment activities. Specifically, it will provide the following user features:

    1.An order processing staff member can determine the status of an order from customer or order identifying information. A list of recent orders will be presented for selection, if order ID code is not available.

    2.An order processing staff member can change the status of an order (cancel or change priority) in case of customer queries.

    3.A manager can print or view a dynamic order-tracking report. A daily management report will summarize the percentage of orders processed on time for expected delivery and list outstanding orders for immediate action. On-demand reports will summarize real-time order processing and fulfillment status. The user can drill down to locate and see the progress of an individual order.

    4.A manager can view or print the status of work at each stage of order-processing, for each employee work-station. The main stages tracked will be: (i) order placement, (ii) order verification against inventory, (iii) customer confirmation of order, (iv) inventory delivery to packing station, (v) order packed, (vi) order delivery to shipping station, (vii) order shipped, (viii) delivery confirmation received.

    5.Order processing and order-fulfillment staff will receive work-scheduling information at their work-station, that provides them with the information that they need to process the next order, on the basis of priority and staff availability. The information provided will depend on the stage of order processing (see feature 4).

    Validating The System Purpose and Features

    The system purposes can be validated fairly easily – ask people if this is what they need a new system to do!

    System features are more difficult — how do you know if you’ve missed anything?

    • You can use scenarios (paper walkthroughs) to validate sequence of events
    • You can use swimlane diagrams to determine sequence of interactions with system
    • You can use use-case models, to understand detailed system interactions required for each purpose
    • You can use event-lists, to determine if you have included all the processes that you need

    Any of these methods is useless unless validated by people who will work with the system (and their managers).

    © Copyright Susan Gasson, 2014-17. Created 12 December 2014.

  • Human-Centered Design

    Human-Centered Design

    In the last few years, the terms human-centered and user-centered have become synonymous in HCI and IT design, 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 technology artifacts, applications, and platforms that provide a “support system” to people performing specific work or play activities as individuals, or collaborating around a set of (more or less) well-defined aims – often messily and exploratively. Asking people to describe their requirements for technology to support them in their activity doesn’t work because no-body really stops top think about how they work, or what they do to achieve a goal. When they are forced to do so, they will describe how work should be done – the formal system of procedures and rules – rather than how it is done – the informal, socially-situated system that makes work activities fit with their environment and the objectives that people have.

    People are seldom alone in what they do, even when engaging in individual activity. They socialize with other people and exchange ideas, they seek advice on how to proceed, and they collaborate to achieve shared – or similar – goals. When confronted with a novel problem, most people turn to a “small world” network of trusted social contacts for input – people who share their values and perspectives – rather than conducting a wider search that includes subject experts and knowledge resources (Chatman, 1991). Even when working alone, we are never truly alone. We are thrown into a working environment that existed before we joined – a self-contained world of work and social activity that we can only understand through participation (Weick, 2004). Professionalism and practice in one organization are completely different to the practices and standards applied in another.

    When we try to understand the “user” of a software application or system, we often fail miserably because we only see the formal work activities that they perform. We miss the web of activities that their formal activity is a part of – the multiple other human-activity systems they interact with, to get things done.  User-experience design is reductionist 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 for work-analysis e.g. Sharp, Preece, and Rogers (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 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, 2007). 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. Which they already did.

    We can support this world by understanding the various purposes of human activity and designing technology to assist in those purposes (Checkland and Winter, 2000). Human-centered design differs from user-centeredness by being systemic and multi-vocal: it is aware of the multiple networks of activity in which a human technology user engages, simultaneously. Unlike user-centered design, which focuses on a single, definable work-goal, human-centered design appreciates the multiple goals that people pursue simultaneously, for different purposes. Human-centered design appreciates the social and organizational context of work, employing analytical approaches and methods that explore the complexity of the activities that we do – and the social networks we inhabit to do them.

    Designing for humans rather than users is a choice:

    • Human-centered design explores the multiple, purposeful systems of human-activity that are required to achieve even simple work (or play) goals.
    • It treats the participants in a human activity system as autonomous individuals, not agents to be modeled, controlled, and curtailed. Human-centered design respects and supports the local knowledge required to act skillfully, using local knowledge and various forms of tacit or implicit knowledge to perform work that is often not recognized as knowledge work.
    • It recognizes that a social system of information exchange exists, of which the designed technology artifact or software is only a part, and that humans need to exercise a deliberative choice about what to record and why. Any computer-based system of data is part of a wider, human-network-based system of information.
    • Because it appreciates work as part of a wider social system,  human-centered design involves a conscious decision to support the informal communications and activities that keep the system of work connected and informed – for example, water-cooler conversations or phone calls. These informal channels produce more knowledgeable participants in the system of work, rather than resulting in recorded data records or written resources. They are often omitted from – or worse, designed out of – the formal system of “user experience design.”
    • 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, then reflecting on what we did and how – after which we have a better understanding of how to do them next time. Designing any particular set of procedures into a computer-based system is not only a waste of time, but may be counterproductive, as we constantly improvise and improve on how we did things previously (learning-by-doing). Human-centered systems design allows the human to be in control of their work, rather than the IT system.

    So no – “user experience design” and “interaction design” do not support human-centeredness in work (or play). They seek to humanize the artificial processes imposed by transaction-based systems by associating these with perspectives that acknowledge the psychology of human activity, learning, and interactions with technology. But they don’t even scratch the surface of understanding situated, systemic activity. For that, you need to employ methods that complicate your perspective, such as Soft Systems Analysis (Checkland, 2000; Checkland and Poulter, 2006) – and to take human-centeredness seriously.

    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

    Chatman, E.A. 1991 “Life in a Small World: Applicability of Gratification Theory to Information-Seeking Behavior,” Journal of the American Society for Information Science (42:6), pp. 438–449.

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

    Checkland, P., and Poulter, J. 2006. Learning For Action: A Short Definitive Account of Soft Systems Methodology, and its use Practitioners, Teachers and Students Chichester: John Wiley and Sons Ltd, 2006.

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

    Sharp, H., Preece, J., and Rogers, Y. 2019. Interaction Design: Beyond Human-Computer Interaction, 5th EditionWiley, UK, 2019.

    Suchman, L. 1987. Plans And Situated Action Cambridge MA: Cambridge University Press, 1987.

    Suchman, L. 2007. Human–machine reconfigurations: Plans and situated actions Cambridge, UK: Cambridge University Press, 2007.

    Weick, K.E. 2004. “Designing For Throwness,” in: Managing as Designing, R. Boland, J and F. Collopy (eds.), Stanford CA: Stanford Uniersity Press, pp. 74-78.

    Selected Papers:

    Gasson, S. (2008) ‘A Framework For The Co-Design of Business and IT Systems,’ Proceedings of Hawaii Intl. Conference on System Sciences (HICSS-41), 7-10 Jan. 2008. Knowledge Management for Creativity and Innovation minitrack, p348.  http://doi.ieeecomputersociety.org/10.1109/HICSS.2008.20.

    Gasson, S. (2005) ‘Boundary-Spanning Knowledge-Sharing In E-Collaboration’ in Proceedings of Hawaii Intl. Conf. on System Sciences (HICSS-38), Jan. 2005. http://doi.ieeecomputersociety.org/10.1109/HICSS.2005.123

    Gasson, S. (2003) ‘Human-Centered vs. User-Centered Approaches To Information System Design‘, Journal of Information Technology Theory and Application (JITTA), 5 (2), pp. 29-46.

    Gasson, S. (1999) ‘A Social Action Model of Information Systems Design’, The Data Base For Advances In Information Systems, 30 (2), pp. 82-97.

    Gasson, S. (1999) ‘The Reality of User-Centered Design‘, Journal of End User Computing, 11 (4), pp. 3-13.

  • Home

    Improvising Design

    This website provides a tour of how to enable IT-related change in complex business organizations (nonprofit and for-profit). It is focused around improvisational design, as improvisation is the result of dealing with wicked problems.

    Wicked problems are the type of interrelated, subjective problems that we encounter in organizational change. We can never resolve (or even agree) such complex problems in one go – each stakeholder has a different perspective on what the problems are. As Rittel & Webber (1973) observed, there is no single problem definition – and no stopping point by which to judge if you are finished.

    Goal-based design is a myth. Instead, we face emergent design, comprising cycles of inquiry, systemic analysis, organizational & IT change, and evaluation. The best we can do is to agree a scope for action, analyze the problems within that scope and take action, then evaluate whether we made the situation better or worse. Design is emergent because we constantly need to change our scope and goals, depending on that evaluation – and on changes to organizational goals in response to a changing business environment.

    IT and change management fail when they are managed as if each project is self-contained. Instead, we need to manage these processes as a single cycle in an ongoing process of managing organizational fit with an evolving business environment.

    Emergent Design

    Parabolic trajectory followed by the design process as goals emerge over time

    Explore how design works, the co-design of business and IT systems, and user-centered vs. human-centered design.

    Systemic Analysis

    Interconnectedness of elements from systems thinking perspective

    Understand what systemic analysis involves and why you need to use it!

    Human-Centered Collaboration

    Two stick men communicating with metal cans and string

    Appreciate design of systems to support computer-mediated human interactions, decision-making, and collaboration.

    References

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