Author: Susan Gasson

  • Boundaries Matter

    Boundaries Matter

    As we become more experienced in the professional practice of our organizational function, we build a repertoire of “recipes for success” — mental models that indicate what methods to use for solving various types of problem, and criteria for evaluating how well we have succeeded in achieving specific outcomes.

    The diagram shows four types of domain-locale that are spanned to produce organizational expertise, as a 2x2 matrix with the axes: Local (group) vs. Global (Organization); Community of Practice vs. Knowledge Domain (of expertise).

    Boundaries Matter: How Aspects of Organizations Interact

    Assemble a group of people from different functions – for example the typical project group or management taskforce that is used for problem-situations that span organizational boundaries – and you discover that its members’ perspectives diverge, and often conflict with each other.

    “Consensus planning” is the worst strategy for wicked problems. Instead, you need problem-exploration techniques that represent different perspectives of the situation to stakeholders, allowing them to generate useful frames that surface and expose conflicting change-objectives. You need to make tradeoffs explicit, to prioritize actions for change.

    Appreciative design makes sense of the tangle of complexities, using an improvisational approach to incorporate the multiple, mutually inconsistent aims of stakeholders into a coherent plan for action.

    An effective strategy for boundary-spanning design and change-management explores the problem-situation iteratively, incorporating the implicit knowledge that surfaces during investigation, acknowledging multiple ways of framing the situation, and managing evolving strategies, contingencies, and values to produce a coherent set of priorities for change.

    It involves three, very different types of thinking:

    Spiral road, representing recursion of systemic thinking

    Systemic Thinking

    Typically, we define a single goal that conflates the multiple, often conflicting, objectives of the work-systems we are trying to improve. This complicates, rather than simplifies the design of work-systems, as we inevitably have to revisit these goals, reworking the analysis to incorporate the multiple other purposes that people value. Many times, objectives conflict, but we don’t realize this because we only have a vague idea of what these are.

    Systemic thinking takes a “big picture” approach to problem investigation, followed by a “divide-and-conquer” approach to making improvements. Read more on Wicked Problems and Systemic Solutions

    Human-Centered Design

    In a complex, interconnected world modern organizations need to focus on effectiveness – doing the right thing – rather than the efficiency focus of most design approaches. We still use late 19th century thinking in design, trying to use “scientific management” rather than centering the process on how people need to do their work in order to produce products and services that are responsive to customer needs.

    Human-centered design starts with the work that people need to do, involving them in the redesign. Unless we understand what needs to be done, we can’t design systems to support work.
    Read more on Human-Centered Design

    Man playing saxaphone. Represents improvisational nature of design.

    Co-Design of Business & IT Systems

    Boundary-spanning design is improvisational. We very rarely understand all the requirements for change, even when we start to implement changes to business processes and IT systems. The key skill is an ability to adapt to contingencies, integrating group knowledge across work domains.

    Adaptive planning takes an iterative approach to goal-setting, integrating knowledge about what needs to be done with an evolving appreciation of how the organization works. We center this around an effective business strategy for our company, while prioritizing the work processes that those involved identify. Read more on the Co-design of Business & IT Systems

  • Why is design improvisational?

    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, recognize 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, but even experienced designers must deal with emergent design in a novel context. In these circumstances, designers iterate their design, as shown in Figure 1. They identify (often partial) problems, ideate/conceive relevant solutions, give those solutions form with a prototype, then evaluate the prototype in context. This often reveals emergent user needs or problems, that are explored in the next iteration.

    Figure 1. Iterative Design

    An important aspect of iterative design is that iterations can occur within cycles. As designers succeed or fail at successive designs, they accumulate experiential knowledge, that allows them to assess new situations quickly and

    to understand which design elements will work or fail in that situation, looping back to remediate the design as they spot logical flaws and gaps in the design. 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 adapt and improvise how they are used.

    Which means that design-goals are constantly changing between iterations, as shown in Figure 2. The designer starts by designing for the subset of goals they understand. As they explore and test the design with users, they become aware of new requirements and so modify the subset of goals they are designing for. As part of this process, they also discard any requirements that are no longer associated with perceived user needs.

    Figure 2. Goal-emergence in design

    Improvisation takes a multitude of forms. It might be that a user wishes to customize the color of their screen (because the designer thought that a good interface should look like a play-school). This may not do much for the function of your work-system, but it does mean that your disposition towards work is a heck of a lot sunnier as you use it. Or it might be that the information system which you use expects you to enter data on one step of your work before another. You might be able to enter data into a separate screen for each step, reordering the steps as you wish. More usually, you have to enter fake data into the 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. This is fine if everything goes to plan, but a huge pain for users when it does not. The only discretion left to the user is how to format the results in a printed report, which is not much comfort if your whole transaction failed because you were prevented from going back to change one of the inputs. This is not rocket science – developers need to design systems that let users work autonomously.

    Business applications tend to present wicked problems . A wicked problem cannot be defined objectively, for all the reasons identified in Figure 3. Solving a wicked problem needs business users and stakeholders to agree on what problems that they face, their priorities in resolving these, and what their change-goals are.

    Figure 3. Constraints on Design Posed by Wicked Problems (Rittel & Webber, 1973)

    A wicked problem can be understood as a web of interrelated problems. It is not always clear what the consequences will be, of solving any part of this mess. Some of the problems may have “obvious” solutions. But implementing  these solutions may make other, related problems worse or better. This is why iterative design is central                      to resolving wicked problems. In general, stakeholders don’t understand what they need until they see it. So solutions must be designed flexibly, for changes to be implemented as the consequences are realized and to permit adaptation-in-use by stakeholders and users. People are infinitely improvisational. They develop work-arounds and strategies to manage poor design. But, as Norman observes, why should users have to develop work-arounds for poor design? What is it, about the design process, that leads us to such constraining IT systems, interfaces, and work procedures that are based on the system design, rather than system designs that are based on 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.

    References

    Norman, D. A. (2013). The Design of Everyday Things: Revised and Expanded Edition. Basic Books, New York.

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

  • Systemic Thinking

    Systemic Thinking

    Vatican spiral staircase to represent iterative design spiral

    Soft systems are systems of human activity. Typically, we define a single goal that conflates the multiple, often conflicting, objectives of the system of organizational work. This complicates, rather than simplifies the design of work-systems, as it excludes support for the multiple other purposes that people aim for in their work. Many times, purposes conflict with each other (like a healthcare system aiming to both manage costs and optimize health improvement outcomes). We need to be nuanced in designing systems that balance support for various objectives. This nuanced design requires a systemic approach, where we consider what human-activities need to be performed for each outcome, before reconciling these with support for other change objectives. This requires a recursive (spiral) approach to design, where we periodically “complicate” our thinking – and then ask “so what do we do now, understanding this new information?”

    Soft Systems Analysis

    Soft Systems Methodology (SSM) takes a divide-and-conquer approach to analyzing a problem-situation. We represent the problem-situation with as little extraneous structure as possible, as a set of interactions between people-doing-things.

    • We separate the subsets of activity performed for an identifiable purpose
    • We model each subset as an “ideal world” process-flow.
    • Comparing each to the real world allows us to define actionable changes, which recognize organizational, political, and economic constraints.
    • Finally, we prioritize the resultant changes, to produce a plan of action.
  • Human-Centered Design

    Human-Centered Design

    Small group of people gathered around computer to discuss human-centered design.

    Most design approaches are still based on scientific management – the late 19th/early 20th century thinking that saw the point of organizational change as improving efficiency.

    IT does not replace people – it supplements them. It doesn’t get happy, it doesn’t get sad (or bored), it just runs programs. And that is the problem – even AI can’t do things it is not programmed to do. Human beings, on the other hand, are excellent at exception-handling! They can spot anomalies in your process output before they become a huge problem.

    The real problems with IT and business process design is that we have been suckered into thinking that – if only we get the program right – everything will work perfectly. It won’t. Stuff changes, in the business environment, in customer perceptions, and in what our competitors are offering. That is why, for example, the US is struggling so much with supply-chain management. Our systems are designed for everything to go right. We just don’t understand how to design systems.

  • Boundary-Spanning Design

    Boundary-Spanning Design

    … is improvisational.

    We may plan business strategy, process change and IT roadmaps, but we always need to adapt to contingencies and the knowledge that emerges from collaboration across work domains. This is why organizational change involves wicked problems. It requires a systemic thinker to synchronize transformation across multiple functions and organizational boundaries. Someone who can pull together multiple – often conflicting – perspectives, to create actionable insights.

    Adaptive Thinking

    Systemic analysis requires different skills than the bottom-line driven approaches to business change that we normally use. A systemic thinker must see the big picture, then prioritize areas for change. This requires a  divide-and-conquer approach, that separates out (rather than conflating and confusing) the different purposes of the organizational system of human-activity.

    The real problems with IT and business process design is that we have been suckered into thinking that – if only we get the program right – everything will work perfectly. It won’t. Stuff changes, in the business environment, in customer perceptions, and in what our competitors are offering. That is why, for example, the US is struggling so much with supply-chain management. Our systems are designed for everything to go right. We just don’t understand how to design systems that devolve decision-making to the people who can make sense of what is happening.