The statechart work on a data access service a few months ago was clarifying in ways I did not expect. Applying Harel's formalism to a real service - mapping its states, transitions, preconditions - revealed dead-end states and unassigned triggers that the existing journey maps had not surfaced. The formalism worked. But afterwards, trying to articulate what I had actually done, I found myself stuck at "well, I drew a statechart" - which is not a useful account of a design activity. The question I could not answer was: how do you decide what the states are? The statechart notation tells you how to express states and transitions once you have them; it does not tell you how to identify them in the first place. That gap pointed to something I had been circling around without landing on: what does state-space construction look like as a design activity, not just as a retrospective analysis?
What follows is an attempt to describe that activity. It is not a method - not a sequence of steps to follow. State-space construction is design work, and design work resists proceduralisation precisely because the problem and the framework co-evolve. What I can offer is a description of a mode of inquiry - a way of attending to a domain that foregrounds states over actions, configurations over sequences, and possibility structures over prescribed flows.
The co-evolution problem
I have been arguing that design is "logically prior" to planning - that constructing the state space is a different and more fundamental activity than navigating within it. But something about this formulation has been bothering me, and the practical work crystallised it: it can sound as if design first constructs the complete state space, and then planning navigates within it. A temporal sequence: first design, then plan.
The design research literature, however, has established that this temporal reading is wrong - and wrong in ways that matter for practice. Dorst (2015) describes frame creation as a process in which the problem and the solution co-evolve; you do not fully understand the problem before you begin working on the solution, because working on the solution is part of how you come to understand the problem. Gedenryd (1998) makes the stronger claim that design cognition is not internal deliberation followed by external action but a continuous loop between thinking and acting - what he calls "interactive cognition". The designer does not first think through the problem and then act; thinking and acting are interleaved, each informing the other.
Applied to state-space construction, this means: you do not construct the complete state space and then plan within it. You begin with a provisional, incomplete understanding of the domain - some variables that seem relevant, some transitions that seem possible, some goals that seem desirable - and you begin planning provisionally within this incomplete framework. The planning reveals gaps: states you had not considered, transitions you cannot specify, goals that are incoherent given the domain's actual structure. These gaps feed back into state-space construction: you revise the framework, add dimensions, collapse distinctions that do not hold, discover new transitions. The revised framework reshapes what plans are possible. You iterate.
The "logically prior" claim remains correct in the sense that matters: state-space construction is the more fundamental activity, because it determines what planning can even attempt. But it does not come first in time; it is woven through the entire design process, surfacing whenever the current framework proves inadequate and retreating whenever the framework proves sufficient for the task at hand.
What state-space construction involves
If state-space construction is not a sequential phase but a recurring mode of inquiry, what does the inquiry actually involve? Drawing on the formal apparatus from the earlier posts and on the practical experience of the statechart work, several interleaved activities are discernible.
The first is identifying the dimensions that matter. This draws directly on Gärdenfors's (2000) conceptual spaces: the designer works with stakeholders to surface the quality dimensions along which the domain varies. For the data access service, the relevant dimensions included application status, data governance approval, technical provisioning, and user access level. For vocational rehabilitation, they included health condition, functional capacity, employment status, benefit entitlement, and social situation. The design question is which dimensions to include - and, just as importantly, which to exclude. As the earlier post argued, every exclusion has consequences: it determines what the resulting model can see and what it renders invisible.
The second is specifying the transitions. Once the dimensions are provisionally identified, the question becomes: how does the system move between states? What actions, events, or conditions trigger transitions? What preconditions must hold? This is where Harel's (1987) statecharts become practically useful - not because every service needs a full statechart, but because the discipline of asking "what triggers this transition, and what must be true for it to occur?" forces precision that narrative representations avoid. The statechart work on the data access service revealed transitions that had no assigned trigger - the system could, in principle, move between states, but nobody had specified what caused the movement - and states from which there was no exit. These are the kinds of gaps that action-oriented representations (journey maps, process flows) do not force you to confront.
The third is testing against situated knowledge. Burns and Hajdukiewicz (2017) argue, in the ecological interface design tradition, that the designer's task is to make the work domain's constraint structure visible - to reveal the boundaries and affordances that practitioners need to see in order to act effectively. Applied to state-space construction, this means that the formal model must be tested continuously against the situated understanding of people who work in the domain. Does this state actually occur? Is this transition really possible? Are there states the model does not capture that practitioners routinely encounter? The model is a hypothesis about the domain's structure; situated knowledge is the evidence against which it is tested.
The fourth is iterating as the plan reveals new requirements. This is the co-evolution described above: as provisional planning proceeds within the provisional state space, it reveals what the state space needs but does not yet have. A plan that requires a transition the model does not contain reveals a missing transition. A plan that reaches a state the model does not recognise reveals a missing state. A plan that cannot achieve its goal reveals either an impossible goal or insufficient transitions. Each revelation feeds back into state-space construction, and the iteration continues until the model is adequate for the planning task at hand - not complete (completeness is unachievable for complex domains), but adequate.
What this requires of the designer
State-space construction as inquiry is not a mechanical activity. It requires something I have not yet fully articulated - a form of evaluative capacity that allows the designer to judge when a state space is adequate, when a dimension is relevant, when a transition is correctly specified, when a gap in the model reflects a genuine gap in the domain rather than an artefact of the modelling process. This is closer to what Aristotle called phronesis - practical wisdom, the capacity for situated judgement - than to technical skill. The designer needs enough formal understanding to work with state-oriented representations (statecharts, state tables, transition diagrams) and enough domain understanding to recognise when the representation captures something real and when it distorts.
Schön (1983) described this as "reflection-in-action" - the practitioner's capacity to think about what they are doing while they are doing it, adjusting their approach in response to what the situation reveals. In state-space construction, reflection-in-action manifests as the continuous assessment of whether the emerging model is illuminating the domain or imposing a structure on it - whether the formalism is revealing the constraint structure (as Burns and Hajdukiewicz would have it) or constructing a constraint structure that serves the formalism's requirements rather than the domain's reality. This evaluative capacity - and how seven different theoretical accounts illuminate its nature - is a question I expect to return to.
The limits of proceduralisation
A description of state-space construction as inquiry is, deliberately, less satisfying than a method would be. It does not tell the practitioner what to do on Monday morning. It describes a mode of attention (states over actions), a set of conceptual resources (conceptual spaces for dimensions, statecharts for transitions, ecological interface design for constraint revelation), a process structure (co-evolutionary iteration), and a capacity requirement (evaluative judgement). But it does not prescribe a sequence of steps, because if design constructs the framework rather than operating within one, then any procedural account of design work would be self-undermining. To prescribe a procedure for state-space construction would be to treat the framework as given (the procedure) when the whole point is that the framework must be constructed.
This is the design paradox that Cross (2004) identifies in a different context: expertise in design cannot be fully codified, because the situations that demand design are precisely the situations where existing codifications are inadequate. What can be offered is not a method but a repertoire - a set of conceptual tools, representational practices, and modes of inquiry that the designer draws on as the situation requires. The formal apparatus from the earlier posts - conceptual spaces, state spaces, statecharts, promises, grammars - is part of that repertoire. What makes it a design repertoire rather than an engineering specification is that the designer must judge when and how to use it; the repertoire does not prescribe its own application.
References
Burns, C. and Hajdukiewicz, J. (2017). Ecological Interface Design. CRC Press.
Cross, N. (2004). Expertise in Design: An Overview. Design Studies, 25(5), 427–441.
Dorst, K. (2015). Frame Innovation: Create New Thinking by Design. MIT Press.
Gärdenfors, P. (2000). Conceptual Spaces: The Geometry of Thinking. MIT Press.
Gedenryd, H. (1998). How Designers Work: Making Sense of Authentic Cognitive Activities. PhD thesis, Lund University.
Harel, D. (1987). Statecharts: A Visual Formalism for Complex Systems. Science of Computer Programming, 8(3), 231–274.
Schön, D. (1983). The Reflective Practitioner: How Professionals Think in Action. Basic Books.