A defined question.
A reviewable result.
An engagement starts with the information environment as it exists, then identifies a useful change that can be explained, implemented, and assessed.
Bring the situation,
not a perfect brief.
A useful first conversation can begin with a repeated problem: editors correcting the same detail, readers asking for documents that already exist, or records disagreeing across platforms. Describe where the difficulty appears and who encounters it.
We then identify what needs clarification before a responsible scope can be proposed. The conversation may reveal a technical task, an information-design task, or a dependency that needs to be resolved first. Any paid discovery work, implementation, or support should be separately agreed before it begins.
Look at a representative sample.
Review a manageable collection of records, pages, queries, or workflows. Look for patterns and exceptions. Confirm that any shared material is appropriate to disclose; public examples or anonymized descriptions are often sufficient at the beginning.
A concise view of the current situation and the open questions.
Frame the first useful scope.
Describe the intended users, the change being considered, and the limits of the first delivery. Identify platform access, decision owners, dependencies, and any assumptions that could affect feasibility. Agree on deliverables and a review method.
A written scope with responsibilities and acceptance considerations.
Make the proposal tangible.
Depending on the engagement, this may mean a content model, a navigation prototype, an implemented collection, or a limited system connection. Use representative information to review behavior and clarify decisions while the work is still manageable.
A concrete artifact that can be inspected against the agreed task.
Review the behavior and the gaps.
Check the normal task alongside relevant exceptions: missing information, empty results, permission boundaries, unavailable dependencies, and narrow-screen use. Record unresolved items and explain their impact rather than hiding them in a final demonstration.
A review record that distinguishes completed work from known limitations.
Hand over with context.
Explain routine updates, operating dependencies, access ownership, and relevant recovery steps. Confirm who receives the work and what ongoing responsibilities remain. Future changes and support arrangements should be explicit rather than assumed.
A maintainable result with the agreed documentation and next actions.
Timing and commercial terms depend on the agreed scope. This framework describes a way of organizing an engagement; it does not create a service commitment or imply that every step is required for every project.
Tell us where you are starting