I start by making the problem and the decision understandable. The sequence changes with the project, but the work has to connect what people need with something a team can deliver and maintain.
Learn enough to choose
I look at the task people are trying to complete, the content and systems they encounter, and what the team already knows. Interviews, existing research, content inventories, analytics or a close reading of the current experience can each answer a different question. A method is useful when its findings can change a decision.
The output might be a shared problem statement, a map of users and responsibilities, or a short list of assumptions to test. Those are examples of possible deliverables, not a promise that every project follows the same research program.
Make relationships explicit
When people are using the same word for different things, I put the relationships on the page. A content model can distinguish an object from the page that presents it. A taxonomy can give a team a shared way to organize something. An ownership map can reveal a decision with no responsible person.
The ritual content-model example shows why the unit being organized matters. Consolidating files and improving an ongoing practice are different claims and need different evidence.
Put a decision into a working form
I turn an approach into an example people can inspect: a draft, a model, a prototype, an interface state or a workflow. I name the constraint that changed the choice and distinguish a documented alternative from a retrospective interpretation.
For this website, separating canonical content from rendering makes audience decisions inspectable before a build. The reason-to-result example connects that decision to checks against the generated output.
Test the thing that could be wrong
A review needs a question. Can someone find the intended content? Does the model distinguish the cases that matter? Does a denied action remain denied in the generated artifact? Can the person maintaining the system recover from a failed change?
I use deterministic checks for repeatable mechanics and human review for interpretation, tone, relevance and judgment. AI can help draft, compare or implement within a defined task. I remain responsible for the brief, scope and review; a convincing answer does not establish that the claimed action happened. The d8p case study includes an experiment that makes that limit concrete.
Leave someone able to continue
I finish a handoff with the result, its owner, the evidence behind it and the next condition that should trigger review. Maintenance belongs in the design: who can change the source, who approves a release and how to recover the prior state.
A lightweight record that someone can use is more valuable than a large one they cannot keep current. Explore the d8p case study or compare the portfolio cases.