PHI (Procedural Hierarchy of Issues) extends the IBIS (Issue-Based Information System) method developed by Rittel to support an argumentative approach to design. PHI extends that approach because it uses an additional argumentative process and deals with a greater range of design issues. PHI has recently gained recognition as the conceptual foundation for a number of design hypermedia systems.
Procedural Hierarchy of Issues (PHI) is a version of IBIS that addresses the main problems identified with the original method. It differs from IBIS in four main ways.
What constitutes an issue?
In IBIS, issues are only the design questions that are deliberated in any sense; that is, design decisions that are agreed without discussion do not become issues in an IBIS issue map. In PHI, however, all questions related to the design are regarded as issues, whether they are deliberated or not, and are documented as such.
How to relate issue?
PHI introduces an element of hierarchy in its relationships, and deals only with two notions: which issues serve the current issue, and which issues does it serve? The serving relationship is defined as follows: issue A serves issue B if resolving A helps to resolve B.
How to resolve issues
Like IBIS, PHI uses deliberation to resolve issues, looking at the arguments for and against each proposed answer and deciding, on that basis, which answers to choose. However, PHI extends this idea with the notion of generality/specificity of answers. PHI also does away with the idea of categorizing arguments as being for or against possible answers, and simply thinks of them all as arguments.
How to raise issues
PHI is more restrictive than IBIS in the order in which issues can be raised. PHI has two rules for identifying issues:
Generate the issue hierarchy in a top-down manner, starting with a Prime Issue and proceeding down a hierarchy of sub-issues until no more sub-issues can be identified.
Perform sub-issue generation breadth-first.
Photo by Chaozzy Lin on Unsplash