Category: improvisation

Why Is Design Improvisational?

The focus of IS design has moved “upstream” of the waterfall model, from technical design to the co-design of business-processes and IT systems. This focus requires an improvisational design approach. IT-related organizational innovation deals with wicked problems. Wicked problems tend to span functional and organizational boundaries as business process and information management problems are intertwined. There are clusters of interrelated problems: these cannot be defined objectively because the problem is defined differently, depending on who you ask. IS designers cannot analyze this type of problem in isolation – we need to involve diverse groups of stakeholders in negotiating suitable problem definitions and boundaries for change. But wicked problems also involve distributed knowledge, where understanding of the problems is stretched across (rather than shared between) stakeholders. So design goals evolve, as designers and stakeholders learn more about the context and the problems facing the organization by engaging in incremental change. This is often approached by means of agile design methods. But our lack of understanding about how to establish a “common language” for this type of design means that information system innovation tends to be pretty hit-and-miss. Most design initiatives spend more time arguing about process definitions than achieving change.

We talk about design as if it were ﬁxed: 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 speciﬁc 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 ﬁt speciﬁc 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 ﬁt 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 ﬂaws and gaps in the design. The problem with this is that (as the Princess said) youhavetokiss 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 ﬁrst 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 deﬁnition. Deﬁning 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 deﬁne how it should work. This is ﬁne 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 deﬁned objectively, for all the reasons identiﬁed 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 ﬂexibly, for changes to be implemented as the consequences are realized and to permit adaptation-in-use by stakeholders and users.

People are inﬁnitely 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 ﬂexible work- procedures?This website reﬂects ﬁndings from my research studies and reﬂections 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.

April 25, 2025
Design as the Serendipity of Location
As I ruminate on design processes, I can’t help but reflect on the similarities between research methods, processes and outcomes, and design methods, processes and outcomes. I read an article which argued that there were two types of people: people with tidy offices and people with untidy offices¹. Tidy-office people are organized and so can find anything they need. These are the people who work top-down, creating an outline then writing or designing according to that scheme. Untidy-office people are disorganized, spend a great deal of time searching for things, but also tend to be more creative because they are inspired by things which they bump into, while looking for other things. These people work bottom-up, assembling elements into a coherent whole. The article argued that there are cognitive rewards in both styles of working, that lead people to subconsciously adopt one or the other style consistently.

I was reflecting on this as I try to make sense of the piles of material that I have assembled for the book. I am definitely an untidy-office type and I wonder if this has something to do with introvert/extrovert personalities? [My project management students and I just explored an online Myers-Briggs personality test; as expected, I was an INTP type.] Perhaps introverts just prefer a “life of the mind,” where we can construct inductive models of the real world?².

My semi-organized and shifting piles of research data, models and representations, interim findings, academic articles, and books provide a three-dimensional, systemic representation of design processes that can be reorganized as I comprehend different patterns. Of course, they are both preceded and supplemented by painstaking (and frequently revisited) processes of categorization, synthesis, and validation. But the kaleidoscope of patterns that they reflect is invaluable in suggesting different views of my findings. The same is true for design – we create the patterns that we perceive as relevant in the problem situation. As our perceptions shift, so do the design patterns that we follow.

I would argue that innovative design is neither deductive or inductive, but consists of cycles of induction and deduction. It follows a hermeneutic circle of sensemaking, as designers attempt to work from problem to solution and to reconcile those fragments of a solution that they understand back to a meaningful problem definition. The combination of deductive and inductive thinking has been described as abductive reasoning, but reasoning about design is more disciplined and rigorous than most descriptions of abduction [a hunch] would indicate. I prefer Thagard and Shelley’s (1997) argument that hypotheses about reality are layered, incomplete, and too complex to be comprehended easily³. Often, the only way to comprehend complex, interrelated elements of behavior and context is to use a visual, systemic representation.

As someone who has spent a good portion of their career as a systems designer, I have never considered design creative. Design is more about synthesizing from preconceived elements than creating from scratch⁴. But I wonder if – just as in research – the greatest inspiration in design derives from the serendipity of location?

Footnotes (click on ↩ to return to post)
1. If anyone knows the reference for this paper, please let me know. I saw an NYT article on the subject, but I can’t locate the academic paper again – which was published in an information science journal, if I recall correctly … ↩
2. There is a neat discussion of deductive vs. inductive reasoning over at the research methods knowledge base. ↩
3. Paul Thagard and Cameron Shelley (1997) “Abductive reasoning: Logic, visual thinking, and coherence.” Available at http://cogsci.uwaterloo.ca/Articles/Pages/%7FAbductive.html (last accessed 11/27/2009). ↩
4. Like sex, design seems to be 30% inspiration and 70% perspiration … ↩
November 27, 2023
The Co-Design of Business & IT Systems

Multiple Perspectives of “The Problem”

Modern organizations are complex, and the sorts of problems that remain to be resolved using process redesign, IT systems design, or the combination of both that we call the co-design of business & IT systems can’t be defined around a simple set of issues. There are multiple managers and groups of stakeholders, with competing goals for change. Some of these overlap, some complement each other, and some are in conflict with those of other stakeholders. Even a group of people who work together will have differing requirements and goals, depending on their experience, their professional background, and their position in the organization. People understand the parts of the organization they have experience of. Those who have worked in multiple groups will have a much wider – and more complex – view of what needs to change than those who have worked in the same role for years.

There’s a management consultancy joke that says if you get five stakeholders around a table, you’ll have at least fifteen different goals.

The co-design of business & IT systems is like piecing together a jigsaw puzzle without the picture. You get an edge here and there, part of a building outline, or a connecting feature, but mainly you are assembling bits and pieces that are tacked together in whatever way makes sense at the time. Most IT analysts fudge this by merging stakeholder requirements for change under a single, vague business goal. But this doesn’t prevent the shift in focus between multiple objectives that stakeholders prioritize, as these become salient to the current area of design. Change analysts have to understand multiple business domains, as stakeholders’ requirements indicate different types of solution and the analyst attempts to integrate these around a coherent business vision. Even business managers don’t really understand their processes – and know very little of the processes with which their area of responsibility interfaces. Conflicts, priorities, and omissions in change objectives are seldom realized as the logical analysis methods used for IT requirements don’t provide ways to map out the full scope of change – the big picture.

We lack ways to represent the big picture of how the organization “works” in ways that would allow business managers to understand the implications of changing things. Business analysts, change managers, and IT systems analysts are in a no-win situation. They are expected to understand myriad interpretations of the business strategy, reconcile conflicting viewpoints on how business processes work, and somehow define a coherent set of change objectives that pleases everyone. All while business managers and stakeholders each understand only a fraction of what the business does.

Goal-based design is a myth

In today’s complex organizations, very few design goals are understood to the point that they can just be stated and agreed across stakeholders. Design-goals are constantly changing between iterations, as shown in Figure 1. 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 1. Goal-emergence in design

Organizational change requires repeated cycles of appreciation, enculturation, inquiry, learning, change, and evaluation – until the design is good enough. Not perfect – and certainly not optimal – good enough is good enough [2]. 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? Because designers fail to design for changes to business processes.

The co-design of complex organizational processes & IT systems

We cannot implement changes to IT systems without changing the way in which people work, how work is organized, and what it achieves. Most often, achieving improved business goals is the whole reason for IT change, as business environments and competitors change – and our business strategy needs to change to match this (or anticipate it).
The drivers of change are shown in Figure 2.

Figure 2. Drivers of IT Change

Because IT change is always accompanied by changes to how people work, we need to design IT systems to support the changes we want, rather than work against them. For example, if we want people to collaborate, designing a system that prevents people from sharing information is a non-starter. So we need analysis methods that models the various systems of work-activity, understands the complex purposes of these systems, and defines requirements for the IT system to achieve these purposes. As shown in Figure 2, IS applications support business processes – they do not define them. Too often, IT design is performed in isolation, by technical developers who do not understand how the business works.

Figure 3 presents a revision of Leavitt’s diamond model (Leavitt, 1960), updated for the 2020s. The original model related four aspects of the organization – structure, technology, task, and people – in a diamond model that communicated how changing any of these factors impacted the others. In 1991, Michael Scott Morton updated the model, to place managerial processes at the center, redefining the four “diamond model” factors as structure, strategy, technology, and individuals & roles. Scott Morton also related the organization to the external technological and socioeconomic environment.

Figure 3. Leavitt’s diamond model, Updated for the 2020s

The updated model presented here is my version of this framework. It presents the organization as situated within its environments – business/competitive, global, socioeconomic, and technological – rather than separate from these. Organizations are much more complex than in the 1990s. They incorporate multiple structures and power-centers/roles (management), business strategy cannot be separated from business intelligence, IT is integrated with data management and analytics, and people are identified with the work-activities they perform and the knowledge that they bring to their work. These four aspects of business organization are organized around the flows of high-level business processes that are performed to achieved each of the multiple purposes that the business exists to achieve.

References

Leavitt, H. J. (1964). Managerial psychology: An introduction to individuals, pairs and groups in organizations. Chicago: University of Chicago Press.

Scott Morton, M. (1991) The Corporation of the 1990s: Information Technology and Organizational Transformation, Oxford University Press.

August 7, 2023

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

April 15, 2015

Improvising Design for Wicked Problems

Improvising Design for Wicked Problems

IT-related change in complex business organizations involves the co-design of business (work-activity) systems and systems of IT. These designs emerge, as we learn about the situation as we deal 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

Explore the co-design of business and IT systems, why wicked problems require improvisational design, and appreciate the history of IS design.

Systemic Analysis

Understand what systemic analysis involves and why you need to use it!
Then explore Soft Systems Analysis, a method for defining change to business processes and IT in tandem

Human-Centered Collaboration

Appreciate the difference between user-centered and human-centered design, how to design knowledge systems, and how to understand requirements for boundary-spanning systems .

References

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

December 24, 2014
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