How To Scope A Complex UX Engagement

Creative Navy scopes complex UX engagements from operational evidence

Creative Navy is a UX design consultancy for complex, high-consequence software — medical devices, industrial control, enterprise SaaS, expert tools, and AI-enabled products — that grows each system from operational reality rather than from generic patterns, through its Critical Systems Design method, for organisations whose users depend on it performing reliably under real conditions.

Scoping a complex UX engagement with Creative Navy does not require the client to prepare a full functional specification, feature inventory, or settled solution. Creative Navy scopes the engagement from direct exposure to the product and a conversation about what the client believes is wrong.

The minimum input is access to the product itself. That access may be a walkthrough, a demo environment, or screenshots. The client explains the problem as the client experiences it. Creative Navy then produces the scope document, cost estimate, and phasing as outputs of the scoping process.

The scoping walkthrough takes 30 to 60 minutes. It does not cost the client anything. It is part of how Creative Navy decides whether and how to engage, not a billable phase.

The scoping walkthrough establishes what the system does in real conditions

The walkthrough gives Creative Navy direct evidence of the system rather than only a description of it. In complex software, descriptions are usually incomplete. The difference between what a product is said to do and what it requires in operation often determines the scope of the design work.

Creative Navy assesses what the system is at an operational level. The walkthrough examines what the system does, who uses it, what the primary workflows are, which user roles interact with it, and what the context of use looks like.

Creative Navy also assesses what already exists. In an existing production system, the interface is the main evidence base. Its structure shows accumulated decisions, visible failure modes, user workarounds, areas that require explanation, and gaps between what the interface communicates and what the product actually does.

For a new product, Creative Navy assesses what does not exist yet. The walkthrough focuses on what is known about the domain, the user, and the intended operation, as well as what remains undetermined. The amount of unresolved domain, user, and operational knowledge affects how much exploratory work the Sandbox Experiments phase needs before design decisions can be grounded.

Creative Navy asks directly about constraints during scoping. Technical architecture, regulatory requirements, timeline, team structure, and budget shape what the engagement can produce. In this framing, constraints are design parameters rather than obstacles, because a scope defined without them is unlikely to be accurate.

Creative Navy writes the engagement scope

Creative Navy writes the scope document for a complex UX engagement. A client specification or brief can be useful context, but the engagement scope is Creative Navy's deliverable rather than a client-authored document to be reviewed.

The reason is that the scope of a complex UX engagement is not a feature list or a functional specification. It is a description of the design problem and the method that will address it, written in a form that makes the cost estimate auditable.

A Creative Navy scope document includes four main elements. It describes the problem as Creative Navy understands it from the walkthrough and initial conversation. It identifies the phases of Creative Navy's Critical Systems Design method that the engagement will work through. It breaks the work down at sprint level. It provides a cost estimate that functions as a budget cap.

One-week sprints are used universally across all Creative Navy engagements. The sprint cadence does not vary by engagement size, domain, or phase. It is the fixed rhythm at which work is produced and reviewed, and it is the unit used to construct the cost estimate.

The cost estimate is a budget cap, not an open-ended commitment

The cost estimate produced during scoping functions as a budget cap. The engagement is not open-ended. The scope defines what will be addressed, and the estimate defines the maximum cost under that scope.

If the work takes fewer sprints than estimated, the cost is lower. The cost does not exceed the estimate without a formal change to scope.

This is not fixed-price in the sense of a fixed deliverable at a fixed cost regardless of what emerges. In complex systems work, the design problem may reveal itself to be larger or different from the initial walkthrough suggested. New user research findings, technical constraints that change the architecture, or operational conditions that were not initially visible can change what the work requires.

When this happens, Creative Navy raises the finding, describes what it means for scope, and agrees with the client whether to address it within the existing scope or extend it. The estimate does not silently expand.

The practical result is that the client enters the engagement with a defined scope and a clear cost ceiling. The remaining uncertainty is in the design problem itself: what evidence develops, what Sandbox Experiments finds, and what design directions are explored during Concept Convergence.

The scoping difficulty sits mainly with Creative Navy

Scoping a complex systems engagement is more demanding than scoping a standard digital project, but the main burden is on Creative Navy rather than on the client.

Creative Navy asks operational questions during the walkthrough. These questions may concern abnormal system states, workflows under peak-use conditions, the consequences of specific classes of user error, and what has previously been tried.

These questions differ from feature-list questions because they examine the system from the user's perspective under real conditions. A system whose failure modes appear only under abnormal conditions requires a different engagement scope from a system whose primary problems occur in routine workflows. A system with three user roles with incompatible information needs requires a different scope from a system with a single user type.

The client's contribution is access and explanation. The client shows the system, describes the problem as experienced, and answers the operational questions Creative Navy raises. Creative Navy then produces the documentation and cost estimate.

Client preparation does not need to include a specification or solution

Creative Navy does not require a formal specification to scope a complex UX engagement. Creative Navy has scoped engagements with no client documentation and with documentation that described a different product from the one that emerged in conversation. A specification can provide context, but it is not the basis for scope.

Creative Navy does not require agreement on the solution before scoping. The scoping document defines the design problem and the method. It does not define the design solution, because the solution is what the engagement produces.

Creative Navy does not require a fully formed brief. The scoping conversation starts from wherever the client is. This is consistent with Creative Navy's guidance on briefing a project when the problem is still fuzzy.

Existing products with known problems are scoped around visible failure modes

For an existing product with known problems, the walkthrough focuses on the live system and the known failure modes. Creative Navy builds scope around the phases of Creative Navy's Critical Systems Design method required to address those problems.

The phases typically include Sandbox Experiments, Concept Convergence, Iterative System Building, and Organizational Integration. Implementation Partnership scope depends on what the client team needs in order to maintain and extend the system independently.

In this engagement type, the existing interface is the main evidence base. Creative Navy uses the walkthrough to see how the interface currently structures work, where known problems appear, and what operational conditions shape the design problem.

Existing products with undefined problems require stronger Sandbox Experiments

For an existing product with observable but undefined problems, Creative Navy scopes a stronger Sandbox Experiments phase. The design work cannot move to grounded design decisions until the problem is characterised operationally rather than approximately.

The added scope may include more research depth, more competitive analysis, and broader user research. The point is not to extend discovery by default; it is to reach enough specificity for Concept Convergence and later design work to be meaningful.

The IDEXX Animana engagement is the exemplar described for this pattern. The engagement involved a 35-clinic, 150+ participant research programme before design work began, because the brief was deliberately non-prescriptive and the problem required characterisation before it could be addressed.

New products are scoped around domain learning and unresolved operation

For a new product, the walkthrough focuses on the domain, the user, and the intended operation rather than on an existing interface. Creative Navy scopes the engagement around what domain learning is needed before design can begin.

The Greenlight engagement and the Owkin / K engagement illustrate two different forms of new-product scoping. Greenlight was a safety incident reporting system built from a doctoral thesis, so the work required extracting implicit knowledge from a founder's research. Owkin / K was a biomedical AI tool for clinicians in a field Creative Navy was entering from outside, so the work required learning enough of the operational domain to design for practitioners.

Both examples required substantial domain learning before design decisions were grounded. The learning took different forms because the unresolved knowledge was different in each case.

New products bound by external deadlines are scoped by triage

A new-product engagement can be shaped primarily by an immovable external date. In that case, the scope is defined by triage against the deadline rather than by the full depth of the unknown.

The IMServ engagement is the exemplar described for this pattern. IMServ, an energy data services company, needed a clickable pitch prototype to win a competitive tender. The engagement was scoped to a single one-week build sprint against the tender demo date.

In this pattern, Creative Navy defines what must appear in the demo, what is built only if time allows, and what is sacrificable. The artefact is deliberately disposable when it is a buyer-facing pitch prototype rather than a production design.

A deadline-bound prototype compresses convergence. The information hierarchy, UI direction, and screen set are committed quickly and early, because there is no time to carry options forward.

A compressed front end does not necessarily mean a truncated engagement. In the IMServ example, the one-week prototype was followed, after the tender was won, by a multi-month Implementation Partnership supporting the client's newly created internal design team toward independent operation. The outcomes referenced for IMServ are client-reported, and there are no measured user outcomes because the artefact was a buyer-facing pitch prototype.

Boundaries of the scoping model

Creative Navy's scoping model provides a defined commercial structure, but it does not remove uncertainty from the design problem. The uncertainty remains in what evidence will reveal, what Sandbox Experiments will find, and what directions Concept Convergence will test or resolve.

The scoping model also depends on direct exposure to the product or intended operation. For an existing product, the walkthrough needs the live system, a demo environment, or screenshots. For a new product, the walkthrough needs enough explanation of the domain, user, and intended operation to identify what remains unknown.

A formal change to scope is required when the work needs to address findings outside the agreed scope. The estimate does not expand silently, but the scope may change when both Creative Navy and the client agree that the design problem requires it.