IBIS as a Design Methodology

This article is based on a Jan 2006 post to Blue Oxen Collaboratories mailing list. For some excellent follow-up discussion, visit that link. As I wrote then, “The ontology guys are going to love this one.” (Because this article presents an ontology for design discussions carried on using a structuring language based on Horst Rittel’s IBIS methodology, or “Information-Based Information System” (via Jeff Conklin). (#)

Introduction    (#)

Ever since I first heard of it, I’ve been thinking of IBIS in terms of a design methodology. Today, it occurred to me that IBIS can be taken a step further, so that it is directly targeted at generating designs collaboratively, rather than at “understanding issues” (which is an admittedly important part of the process).

(For those who don’t know what IBIS is, an explanation is coming up shortly.)    (#)

Note, that even if we weren’t really improving on IBIS– if we were only re-casting the IBIS concept as a design methodology — there would still be several important benefits from doing so:    (#)

• • It refocuses attention on solutions, rather than problems. That makes it more appealing, because people care about solutions, and would rather not be reminded of problems. So they’ll be more likely to think of IBIS as a good idea, even if they don’t know much about how it works.    (#)
  • Artists, architects, software builders, and other professionals will tend to be more interested in the project, because it relates to their primary activity: design. (To that end, it can be used as a solo design tool — one that happens to dovetail nicely into collaborative discussions.)    (#)

When applied to issues like global warming, it will be readily apparent that we are facing a design problem. That slight shift in focus will (I believe) will help us think about the issue in more productive terms.    (#)

So if the only thing we did was to portray IBIS as a design tool, it would tend to be a good thing. But as you’ll see, I think we can do quite a bit more. I think we can use IBIS as a basis to create something even stronger — something that overcomes at least one significant, inherent limitation in the IBIS process.    (#)

Before we get to the “new and improved IBIS”, though, we’ll take a short look at IBIS as it stands today.    (#)

IBIS as a Discussion Methodology    (#)

This is background material. If you’re familiar with IBIS, you can probably skip it. But you may want to read it anyway to figure out what I mean when I say “IBIS”–and so the cognoscenti can correct me on the addled way in which I’ve presented it.

IBIS stands for Issue Based Information System. It was developed by Horst Rittel, and has been used extensively by Jeff Conklin, who popularized it first in a particularly clear paper, and later in his book (below).    (#)

The basic structure of an IBIS conversation, as I grokked it quite a while ago, was:    (#)

    Q: Question
       A: Alternative / Answer
          P: Pro
          C: Con    (#)

In this system, the possible statements have types, and there is a structure among the types. Multiple instances of each type can exist, and they can link to each other in bizarre ways, creating convoluted diagrams that to the kinds of conversations we actually carry on in real life.    (#)

One of the important parts of the process was that it was not possible to put forth “the answer” without first putting forth “a question”–thereby allowing for other possible alternatives. (A practice which, if followed by religions and politicians, would benefit all of us.) So the system immediately moves us away from thinking that is based on “the one right and true way”.    (#)

One of the major benefits of an IBIS discussion, as related to me by a past participant, is that everyone can relax. Any idea they bring up is recorded. The conversation isn’t finished until all of the recorded ideas are examined and evaluated, so people don’t get antsy about getting their ideas across. They can relax while other ideas are examined, knowing that their idea will get its turn.    (#)

Another benefit is that it tends to get people more focused on the problem. When an idea is recorded it is “out there”, and “on the board”. The person who originally presented it can then find themselves challenging it as vigorously as anyone.    (#)

In a purely oral conversation, on the other hand, people tend to feel the need to defend a proposal since, (a) the idea is “inside” them (it only exists when they speak), so it’s “their baby”, and b) since they are the only repository for the idea, it is likely to die the moment they stop defending it, because people will then be able to “simplify their lives” by having one less proposal to consider. (“Politics” seem to emerge in such situations, because people instinctively seek alliances to help “keep their baby alive”.)    (#)

The social benefit of the process is that all of the relevant ideas tend to surface and be examined, so there is a much stronger chance that the best idea will be adopted, rather than the one that happens to be promoted by the loudest or most well-known voice in the room. (Ever see how quickly discussion stops when the CEO voices an opinion?)    (#)

For more on IBIS see:    (#)

• Dialogue Mapping: Building Shared Understanding of Wicked Problems.
  Jeff Conklin. John Wiley and Sons, 2005.    (#)
• Wicked Problems and Social Complexity (Chapter 1 of the book)
  https://www.cognexus.org/wpf/wickedproblems.pdf    (#)
• The IBIS Manual, Jeff Conklin
  https://www.touchstone.com/tr/wp/IBIS.html    (#)

IBIS as a Design Methodology    (#)

The IBIS mechanism centers around a discussion. It’s highly useful for those wide-ranging, infinitely branching discussions of “wicked problems”, where the nature of the problem isn’t clear, and where most everyone in the room has a different concept of the problem they’re there to solve.

But many of the same techniques can be applied to carrying out a discussion that is (or is at least intended to be) slightly more focused: a design discussion — one whose objective is the construction and selection of one or more designs which are aimed at solving a problem or achieving a desired result.    (#)

Since design discussions involving multiple participants frequently turn out to be “wicked” in nature, a design methodology based on IBIS techniques makes sense. But a good methodology can help a solo designer, as well, helping him or her to clarify and understand the needs of the target audience.    (#)

Note:
In essence, the construction of a design-enabling system is an Engelbartian “C” level activity. (A “C” level activity focuses on the design and construction of tools and methods that can be used by “B” level designers, who are trying to improve the processes and procedures used to accomplish “A” level tasks that are being performed currently with whatever tools and techniques happen to be available.)    (#)

Goals   (#)

The goals of the system are:

• To carry out an effective design discussion online.    (#)
• At the end of the discussion process, to be able to print or display either the full text or the summary view of a proposal that has resulted from the discussion, listing its advantages and drawbacks with respect to the requirements.    (#)
• To print or display alternative proposals as well, highlighting their advantages and drawbacks.    (#)
• To print or display the list of requirements that emerged from the discussion.    (#)
• To print or display a table of proposals and requirement to show how they compared.    (#)

Mechanism    (#)

Note:
Most of the italicized terms in this section define and describe the different kinds of statements you can make, and how they relate to one another.    (#)

A discussion consists of statements of various types.

a) A design has requirements, in the form of things we need to achieve. For example:    (#)

REQ: Maintain a stable temperature that supports life on earth.    (#)

b) Issues are things that violate a design requirement:    (#)

ISS: Global warming is raising temperatures.    (#)

Note:
The value of an issue is that it raises one or more requirements that need to be satisfied. Human dissatisfaction and stress are, in general, the result of social systems, government bureaucracies, corporate bureaucracies, and software systems that leave important requirements unaddressed. To the degree that we can identify those requirements and consciously address them, we can greatly alleviate human suffering!    (#)

c) Proposals are ways of addressing the collected requirements.    (#)

d) Proposals can have multiple components, with each component (or combination of components) addressing one or more of the requirements.    (#)

e) Components also have multiple versions. The satisfaction of some requirements may be deferred to later versions. (There may therefore be multiple viable alternatives, with each alternative addressing some requirements earlier, and some later than the others.)    (#)

f) Requirements have different priority levels , reflecting their importance: Level 1: Immediate Need Level 2: Important but deferrable Level 3: Nice, but not vital Level 4: Low level of desirability Level 5: Not important at all    (#)

Note:
I have conflated desirability and timeliness here. At the moment, I don’t have a problem with that. I think it will work. But I could be wrong.    (#)

Identifying the requirements and the levels that need to be assigned to them is a major part of the discussion-and-decision process.    (#)

Creating design proposals is a matter of identifying component/version sequences and relating them to the requirements.    (#)

g) A design proposal can list drawbacks. A drawback always refers to a requirement.    (#)

This is fairly huge, actually. Jeff Conklin pointed out that an “argument against” is very often a new issue in disguise, and that much of the art of the moderator lies in recognizing them.    (#)

At one point, Conklin and his crew created a tool that allowed people to hold an IBIS discussion online. In a private conversation, he relayed to me that it didn’t work out all that well, primarily because it turned out to be a crucial to have a facilitator present– mostly to identify the issue(s) buried in an objection.    (#)

In this system, stating a drawback brings a requirement into existence if it didn’t exist already. So lower level counter-arguments bring higher level requirements to light. That function may reduce the need for a moderator to the point that the process can work online. (There are other important considerations as well, mentioned later.)    (#)

Note:
When making a proposal, you’re free (and encouraged) to put forth the drawbacks as well as the advantages. Listing the pro’s and con’s in that manner gives people an opportunity to let you know that one or more of the supposed “requirements” may not be as important as you had thought.    (#)

h) Proposals are supported by advantage statements. Advantages, too, are related to requirements. So listing reasons in support of a proposal also brings to light requirements that may have been previously hidden, and which can then be applied to other proposals.    (#)

i) Any statement in the system can be supported by reasons. (Evidence?)    (#)

j) Any statement in the system can also be countered with an objection, or supported with an agreement.    (#)

At this point, the normal IBIS machinery may well enter into the picture, in order to facilitate exploration of the reasons and/or evidence for or against a given point of view.    (#)

k) Objections and agreements may be /put forth/ and withdrawn or retracted.    (#)

l) A drawback statement is invalid if it is not yet linked to a requirement — but it can still be present in the system.    (#)

It seems small but this is another big deal. People generally dislike structured authoring systems for two reasons: (1) they’re forced to choose a type when they don’t yet know how to categorize what they want to say and (2) they’re forced to do things in an uncomfortable sequence because the system doesn’t allow “illegal” states (like a drawback without a requirement to link to), even temporarily.    (#)

It may or may not be possible to address the first issue. That’s a usability issue that involves entering random comments or questions and changing them later. It’s an open question that has yet to be decided.    (#)

The second issue can be addressed at the outset, however, by declaring that a drawback can be created that does not yet have a requirement to point to. The requirement can be created subsequently, and a link to it added.    (#)

m) A proposal is incomplete if it has: * invalid drawbacks * invalid advantages * major unaddressed requirements    (#)

An invalid drawback or advantage must therefore be either retracted or validated (by linking it to a requirement) before the proposal can be considered complete.    (#)

A proposal can also be considered “substantially complete” if it has not yet addressed all of the minor requirements. It’s not incomplete, at least.    (#)

n) A proposal addresses, violates, or fails to address a requirement. A requirement is addressed by an advantage statement. It is violated by a drawback statement, and is unaddressed if neither statement is present (in which case the proposal is incomplete).    (#)

o) A proposal is sound if it has no major drawbacks –even if there are minor drawbacks. But it is only viable when it is both sound and complete (all major requirements have been addressed).    (#)

A preliminary proposal may be sound as far as it goes, but if major requirements remain unaddressed, then it is incomplete and not yet viable.    (#)

In many cases, minor requirements may be left unaddressed. They may only become important when there are multiple viable alternatives, at which point minor requirements may become the deciding factor.    (#)

To be decided: How to heuristically determine or allow the participant to designate primary author, co-authors, and other such distinguishments.    (#)

p) A proposal is /adopted by default/ if there are no other viable alternatives. When there are multiple choices, some other basis must be used for deciding among them.    (#)

At this point, the mechanism for choosing among viable alternatives is undecided. It could (and probably should) operate completely outside of the design system. Choices could be made by voting, by personal whim, or by any other mechanism. I’m not sure it matters. As long as we’re choosing from a collection of viable alternatives, things will be heck of lot better than they might otherwise have been.    (#)

q) Other statement types may make sense for editing, such as clarification, correction, restatement, or question. That kind of capability would distinguish edits from substantive statements. (The details still need to be worked out.)    (#)

System Requirements    (#)

To do all this, a mechanism is needed for tagged, threaded, and attributed discussions:

Tagged so that a proposal is distinguished from an objection, and so that a schema can enforce the structure.    (#)

• Threaded so that people can respond within the context of a proposal, as when quoting an email –but without having to quote and re-re-quote material so that it winds up duplicated in every post in the thread. (Part of the reason for implementing purple numbers in the Yak email archive was to permit operations of that kind in the future, and to at least allow for granular linking in the meantime.)    (#)
• Attributed so that the author of any particular statement can be identified. (Important, since only the author of a statement and the all-powerful editor (sys op) can retract a statement.)    (#)

However:    (#)

• Attributions should be maintained by the system, but they should generally be hidden.    (#)

(Interesting wrinkles: The ability to ask “did I say that?”, an option that causes everything you wrote to be marked as such, and the ability to get the system to send a message to the author of a statement — for example, to ask them to retract it –and to track the request so that the editor can be involved if an author hasn’t responded in several weeks, or days, depending on what is considered “timely” for that project.)    (#)

• Hiding attributions is important for a discussion because (a) it prevents knee-jerk, hero-worshiping agreement, (b) it prevents knee-jerk, devil-despising disagreement, (c) it gives people freedom to speak their minds without fear, and (d) it helps to give the original author some distance, making them even less likely to become defensive.    (#)
• Attributions should probably never be shown for individual statements. (Otherwise, there is a need tell the system that a discussion is “finished”, so that it can be displayed in a way that reveals the attributions. But that implies the possibility of “reopening” a discussion, which can defeat the purpose of hiding attributions.)    (#)
• Instead, attributions should probably be collected at the top of (a) the requirements view and (b) each proposal, using some heuristic that involves chronology for the original author(s), and statement types, sizes, and/or numbers to distinguish authors from contributors.    (#)

For example, restatements and corrections would represent contributions, while a substantive proposal represents authoring. So it would be possible, for example, to become one of the authors of the requirements while contributing to one or more of the proposals.    (#)

And just to be clear: The author of several failed proposals would probably find themselves listed as an author of the requirements, but would not be listed as the author of the “winning” proposal. (Maybe that’s why I’m so good at requirements. Having built enough things that didn’t pan out certainly ought to qualify me for something…)    (#)

The interface for such a system needs to solve a couple of interesting problems:    (#)

• Indenting. The original text will have indentation. Responses from others need to be indented, as well. Some way to distinguish the two kinds of indentation is needed so that, when displayed or printed, the discussion reads like a well-structured dialogue, rather than a linear dialogue (as at Slashdot, for example).    (#)
• Highlighting. Like an RSS aggregator, the tool used to watch and participate in the discussion must make it possible to highlight things you haven’t yet read.    (#)
• Fast Access. It should also be possible to quickly jump to the next unread passage. It should also be possible to flag a passage, see an index of flags, jump to a passage from the index, and jump from flag to flag.    (#)
• Filtering. Display a proposal without drawbacks, with only drawbacks, with or without objections, etc.    (#)
• Collecting and Partitioning. It should be possible to work on multiple projects in the same workspace, putting them in folders and picking up where you left off when you revisit them. So you may collaborate on project A with X, Y, and Z but collaborate on project B with M, N, and O. You’ll only work on one project at any one time, but you should be able to see all of your project folders in a single tree, switch between them rapidly, copy files between them, and possibly share authoring templates and other “personal” (non-collaborative) files between them.    (#)

For more thoughts on the requirements for such a system, see:    (#)

• Requirements for a Collaborative Design/Discussion/Decision System    (#)
• What’s Wrong with Email? (for collaboration)   (#)
• A Simple Collaboration System (Proposal)  (#)
• Technical Impediments to Persistent Collaboration Tools    (#)

Summary    (#)

Extending IBIS into a design methodology has a number of potential advantages:

• Every discussion is immediately characterized as a “design” problem. (I happen to think that’s good. I think it puts people in the right frame of mine to be productive and find a solution.)    (#)
• It ameliorates one of the problems that has made it difficult to carry on an IBIS discussion online –the need for a facilitator — because lower level drawbacks call into existence higher level requirements (if they do not already exist) to serve as a foundation.    (#)
• Significantly, the requirements that emerge from that process are then automatically applied to every other proposal in the system — so stating one good drawback can suddenly and immediately invalidate a wide array of proposals, as it probably should have done at the outset.    (#)
• The technologies and techniques used to facilitate IBIS discussions can be used in the design context. (For existing tools and techniques, see CogNexus.org and CompendiumInstitute.org)    (#)
• It can help to get software designers and other designers interested in using (and developing) the system.    (#)

Maybe the only really important task left at this stage of the process is to come up with a catchy name. We could simply add a D: DIBS? IBIDS? BIDS? SPID? Or maybe it could be named after a noted problem solver or peacemaker. (Buckminster? Bucky? Wright Stuff?)    (#)

Any other ideas?    (#)

Copyright © 2006, 2008 , TreeLight PenWorks

Please share!