IBIS as a Design Methodology

This article is based on Jan 2006 post to Blue Oxen Collaboratories mailinng 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 (via Jeff Conklin). (#)

Eric Armstrong
TreeLight.com/software

Contents (#)

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:    (#)

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:    (#)

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:

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:

However:    (#)

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

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:    (#)

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

Summary    (#)

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

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?    (#)

§ Home  ·  Books  ·  Health  ·  Music  ·  Dance  ·  Golf  ·  Yoga  ·  Essays  ·  Store §
www.TreeLight.com

Copyright © 2006, 2008 by Eric Armstrong. All rights reserved.
Contact me to send feedback, make a donation, or find ways to help others.
And by all means, be sure to visit The TreeLight Store.