Developing design principles as navigation in the design knowledge space

Design science research builds things in order to learn something reusable. The most common form that reusable knowledge takes is the design principle: a statement that links a design action to a desired outcome for a class of problems. Because principles sit between abstract theory and concrete systems, they promise both rigour and usefulness.

In practice, two failure modes recur. Some principles stay so close to the original system that they are heuristics nobody else can apply. Others are lifted so high that they offer no guidance for any actual design decision. Previous work has done much to clarify what a well-formed principle looks like, its anatomy of aim, mechanism, context, and rationale, and to propose procedures for arriving at one. What it says less about is how researchers actually move between problem understanding and solution insight while a principle is taking shape, and how they choose the level of abstraction at which it finally rests.

Our research question follows from that gap: how can the development of design principles be understood as navigation across modes of reasoning and levels of abstraction?

The first element is a way of describing what researchers are doing at any moment, without prescribing an order. Three modes recur, and a project moves between them repeatedly rather than passing through them once.

Framing alone yields requirements, not principles. Reflection alone yields features, not principles. Principles emerge in synthesis, when the two sides are matched. This is why projects that stay theory-led produce aspirational principles that are hard to build, and why projects that stay solution-led produce narrow ones. One can read the framework as a specialisation of Hevner’s three-cycle view of design science, applied to principles.

The second element explains the failure modes. Requirements, principles, and features can each be written more concretely or more abstractly. There is no correct level for any of them in isolation. What matters is their position relative to each other.

Three misalignments follow. Requirements framed for a broad problem class with features tied to one system produce vague principles, because the gap between them is too wide to reason across. Narrow, situated requirements with highly abstract features collapse into local heuristics. And principles articulated at a level that neither requirements nor features support look theoretically appealing but are grounded in nothing. Naming these patterns turns the model into a diagnostic tool: when a candidate principle will not settle, ask which side is at the wrong level.

The third element is a vocabulary for the recurring actions through which researchers actually navigate the space. They are not steps in a method. They can be combined, repeated, and revisited.

To show that the scaffold describes something real, we reconstructed the history of a single principle from our earlier project on virtual companionship: the principle of relationship, which addresses the move from transactional assistance to sustained companionship.

It began in framing mode, derived almost entirely from theories of interpersonal relationships and the need to belong. The result was a candidate principle with a strong aspiration and little actionable content. When we tried to build it, it was unclear which system properties would actually deliver a long-term relationship. That forced a shift into reflection mode: we analysed the companion app Replika and ran a longitudinal study, and abstracted the features that seemed to sustain relationship continuity. Synthesis then matched the two sides, and the principle stabilised into the version that was published.

The demonstration is an analytical illustration, not an evaluation of a method. Its point is that the evolution of a principle becomes traceable and discussable once the moves are named.

Existing guidance tells researchers which activities to perform, and what a finished principle should contain. This paper supplies what sits between: an account of the reasoning that development must manage, and an explanation of why quality problems arise when it is not managed. It does not favour theory-led or solution-led strategies. It says that principle quality depends on whether the two sides are expressed at compatible levels.

For practitioners, who tend to use principles as flexible orientation rather than strict instruction, making requirements, principles, and features explicit and aligned turns abstract prescriptions into something discussable without collapsing into implementation detail.