Author: Susan

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.
November 7, 2023
The Potential of Interaction Design
While browsing and working on a recent paper, I mused on the missed opportunity of interaction design. Reading Terry Winograd’s (1997) From Computing Machinery to Interaction Design, I was stunned to see how visionary this was, in the context of contemporary HCI thinking which focused on interactions with computer screen interfaces (still, sadly, the main focus of much HCI work). Winograd saw computing as a “social and commercial enterprise” and saw the role of interaction design as situating technology within social and commercial processes. This thinking is related to Suchman’s (1987) Plans and Situated Actions: The Problem of Human-machine Communication, which saw human-computer-interaction as part of a stream of activity, located in the rationale of a wider sequence of tasks. While HCI theorists were fixated on task-analysis and screen-interface design, Suchman argued that we should see tasks as related to what had gone before and what was to follow. Winograd argued that we should design technical artifacts to be useful in the larger context of social networks and the complexities of interactive spaces.

I was reminded of this when reading a discussion of Don Norman’s (2005) Human-Centered Design Considered Harmful. In this essay, Norman argues that HCI designers focus on “human-centered design,” which he relates to support for tasks and artifact-interactions, when they should focus on “activity-centered design,” related to the larger context of what people do. While I agree wholeheartedly with the sentiment (and applaud the fact that the idea will at last get an audience if Don Norman has taken it up), the concept of activity-centered design still misses the point that we need to understand how actors perceive their stream-of-reality, situated within both a social and a cognitive-processual context, for interaction design to fulfill its potential.

In my 2003 paper, Human-Centered vs. User-Centered Approaches To Information System Design, I argued that human-centered design is not the same as user-centered design. User-centered design sees the human-being as a consumer of technology, whose reality is – somehow, magically – represented by the set of functions accessed via the computer artifact. This tends to be the focus of “traditional” HCI research. Human-centered design, on the other hand, sees the human-being as an autonomous individual, who may want to perform tasks in a different way, or a different order, to other computer “users.” They see the logic of what they do – and therefore the manner of its execution – as part of a socially-situated stream of activity that is meaningful to their understanding of work-processes and not some engineer’s idea of “best practice.” This means that design methods need to deal explicitly with problem inquiry, rather than just focusing on problem closure.

In a new paper (hopefully to be accepted soon!), I have argued that situated interaction-design needs an analysis of two dimensions of the work that people do:
- the formal vs. informal translations that need to take place, to locate work practice in both the social (unstructured-interaction) and organizational (structured-interaction) worlds, and
- the global vs. local translations that need to take place to locate work practice in both the situated and generically subjective worlds.
Most of our design methods focus only on one quartile of this reality: the formal, structured world of data-processing. To really support interaction design, both education and practice need to take on a much wider scope.
August 5, 2017
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
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
Designing Social Media Platforms For Online Learning

Recently, I have been using a collaborative social media platform, designed for online learning, 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. Berkeley Publishing: New York.
Daniel 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) How Cognitive Surplus Will Change The World. TED Talk Video, June 28, 2010.
Clay Shirky and Daniel Pink (2010) Cognitive Surplus: The Great Spare-Time Revolution. Wired Magazine, June 2010.

January 14, 2012
Why The IKEA Font Matters

People have been commenting on the change of font used by IKEA for their catalogs since August, when the new catalog came out. IKEA had used the Futura font for 50 years, but made the decision to adopt Microsoft’s Verdana font this year. Apparently, because it translates well to numerous languages. Take a look at the two catalog examples in this picture. Ignoring that the too-busy 2010 cover looks like they are trying to appeal to the attention-deficit generation, the 2010 catalog could be anybody’s while the 2009 catalog is distinctively IKEA. If you took the brand-name off the catalog, you’d know exactly whose it was.

This is important because design is about more than a satisficing appearance. We tend to mock style over substance, but style plays another role in design. It reinforces the emotional response to artifacts that we have and it provides us with clues (affordances) that tell us how to respond to those artifacts. There is an aesthetic to design that makes the difference between something that is a joy to use and something that just does the job. Sometimes that aesthetic is as simple as the tactile response to a Pilot G2 pen (one of the mundane artifacts that tends to rouse a lot of passion in its users). Sometimes it is the lack of cognitive effort in being able to distinguish the utility of one artifact over another because of its appearance. Sometimes, it is just the comfort of recognizing a familiar artifact, that one knows how to use.

For all of these reasons, IKEA’s decision seems stupid. They had a brand recognition that people would die for, based on the use of the Futura font. Yes, this may be a sad thing to obsess over. But the familiarity and distinctiveness of the IKEA catalog is gone. And I, for one, mourn its passing.

September 5, 2009
Design as a trajectory of goal-definitions

The collaborative design of system solutions for wicked problems seems to follow a trajectory of goals, as the group’s understanding of the design progresses. The key to making (and evaluating) progress is understanding what triggers the changes in goal-direction.
From my research studies, it seems that goal changes are triggered by breakdowns in individual buy-in to the group’s consensus definition of the design vision. Both the breakdowns and the most important parts of the vision are concerned with how the design problem is structured and defined — not (as we usually assume) how the designed system will work. Of course, the solution is important: individual group members constantly test their understanding of the problem against the emerging solution, then realize that the design goals need to change. But it is the consensus problem-vision that drives design goals.

An important implication of this design model is how to manage design effectively. We need to keep influential decision-makers in the loop, when design goals are redefined, or they just see the start and end points. The natural response is “what took you so long?”. Managing external expectations is key to design success.

August 27, 2009