AskNiels

The method existed. It was not queryable.

Niels' methodology was rich and precise, but it lived in documents and human memory. Before an AI assistant could be useful, the entire corpus had to be restructured into a format that was machine-readable, semantically consistent and faithful to the original doctrine.

Structure the corpus before building the interface.

All 57 activities were deconstructed and rewritten as structured knowledge units — each with context, use cases, decision criteria and expected outputs. Chunking strategy, embedding logic and retrieval architecture were designed to surface the right activity for the right context, not just the closest keyword match.

57 activities. One queryable, doctrine-faithful corpus.

The knowledge architecture became the foundation everything else was built on. Doctrinal guardrails were embedded at the corpus level to prevent the assistant from producing generic design advice dressed up in Niels vocabulary. Quality of output was determined by quality of structure.

AI without doctrine produces noise.

The default behavior of a general-purpose AI is to be helpful in the broadest possible sense. For AskNiels, that was a failure mode. An assistant that produced plausible-sounding design advice without methodological grounding would undermine the entire value proposition.

Define the behavior model before the interface.

The assistant's behavior was designed explicitly: context before output, operational answers over inspirational content, method-faithful recommendations over generic best practice. Response principles were documented and tested against real coaching scenarios. The interaction model was built around four modes: understand, recommend, guide, produce.

An assistant that activates the method. Not one that replaces it.

The AI behavior model became the governance layer of the product. Every response had to help a user decide, prepare, facilitate or produce something concrete. Answers that felt smart but were not actionable were treated as bugs, not features.

Different users. Different maturity levels. One system.

AskNiels had to serve coaches who knew the method deeply, clients who had never seen it, and learners trying to build fluency. A single interface serving all three contexts without degrading the experience for any of them required explicit workflow design, not just a search box.

Design for usage scenarios, not for features.

Five core usage scenarios were defined and designed: understand the method, choose an activity, prepare a workshop, adapt a framework, generate structured outputs. Each scenario had its own interaction logic, response format and success condition. The platform UX was built around these scenarios, not around feature completeness.

Reusable workflows across coaching, learning and consulting.

The platform became operational across multiple usage contexts without requiring customisation for each. Coaches prepared workshops faster. Clients accessed the method without needing an expert in the room. The system scaled the methodology beyond the people who originally held it.