How To Brief A Project When The Problem Is Still Fuzzy

A fuzzy problem statement is a normal starting point for Creative Navy

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.

Creative Navy treats an undefined or partially defined problem as a normal starting point for complex software work. The initial task is not to force the client to prepare a complete brief before contact. The initial task is to understand the problem well enough to decide what kind of engagement is appropriate, what the scoping walkthrough should focus on, and whether Creative Navy's Critical Systems Design method is the right instrument for the situation.

A written brief is not a prerequisite for the first conversation

Creative Navy does not require a brief format, a minimum documentation threshold, or a complete set of assembled information before a first conversation. In Creative Navy's experience of engaging with complex-systems clients, at least a third of engagements have no written brief in any form when the first conversation happens.

This absence of a written brief is not treated as a gap. The products Creative Navy works with are often not simple enough for the problem to be fully characterised before a structured diagnostic conversation. When a written brief exists, it usually describes what someone inside the product believes the problem to be. That belief is a starting point, not a specification.

A written brief can provide a starting frame, organisational context, and a sense of what the client believes is wrong. A written brief does not reliably provide the full picture of how users experience the system, what operational reality looks like, what organisational constraints are shaping the problem, or what assumptions the client team holds about the solution. Those details emerge through conversation and, for operational conditions and user behaviour, through direct research.

Oral explanation can reveal uncertainty, assumptions, and previous attempts

Creative Navy treats the initial conversation as a diagnostic conversation rather than a briefing session based only on information transfer. A product director explaining a problem orally can respond to questions, correct the explanation, show where there is confidence or uncertainty, and reveal which parts of the problem are difficult to answer.

A written brief compresses this information. The writer chooses what to include, how to frame it, and how much detail to provide. Those choices encode the current model of the problem. In complex software, that model may be accurate, but it may also be part of why the problem has remained unresolved.

The way a problem is described is itself informative. The examples that come to mind, the comparisons that are made, and the questions that are difficult to answer all help Creative Navy understand the current frame. A written brief can complement that conversation when it exists, but it does not replace it.

The diagnostic conversation defines the right engagement shape

The first conversation with Creative Navy usually covers the system at an operational level: what the software does, who uses it, the conditions of use, what correct use looks like, and what failure looks like. The conversation is not primarily a technical architecture review.

Creative Navy also asks what has already been tried. Previous redesigns, previous agencies, and previous internal attempts are treated as evidence. The difference between what previous interventions changed and what they failed to change can indicate where the structural problem lies.

The client team's own problem description is treated as a starting hypothesis. If an organisation says that users find the navigation confusing, the diagnostic conversation should surface what users are actually doing when they navigate, rather than simply confirming navigation as the problem category.

The conversation also covers what success would mean in product and operational terms. Creative Navy does not treat success only as a deliverables question. The useful question is what would be different about the product and its operation if the engagement succeeded.

Constraints are part of the diagnosis. Budget, timeline, technical architecture, regulatory requirements, team structure, and organisational appetite for change shape what an engagement can produce. Creative Navy treats these constraints as parameters rather than as separate obstacles.

Useful preparation is optional and can be informal

Creative Navy does not require formal preparation before the first conversation. The conversation starts from wherever the client is.

Several inputs are useful when they already exist. Access to the system itself is often more informative than a description. Screenshots, a demo environment, or a brief walkthrough can reveal the gap between how the system is described and how it behaves.

Concrete examples are more useful than generalisations. A specific workflow that users struggle with, a support ticket describing a common failure, or a demo moment that requires explanation can provide a stronger diagnostic anchor than a broad statement such as interface complexity.

Context about the user population is also useful. Creative Navy is looking for a description of the actual people doing the actual work: their roles, their conditions of use, and the operational setting. This does not need to be a persona document. It can be described in conversation, demonstrated live, or pulled up informally.

Creative Navy case evidence shows fuzzy problems becoming specific through research

Many Creative Navy engagements began with a problem that was only vaguely characterised at the outset and became specific during the Sandbox Experiments phase. In Creative Navy's Critical Systems Design method, Sandbox Experiments is the first phase, where domain learning, user research, and structured investigation are conducted before design work begins.

In the Triopsis Workforce Management SaaS case study, the engagement began with a general awareness that users were struggling with the interface and that sales calls were turning into product explanations. The specific structural problem was not in the brief. Creative Navy found that the interface was organised around system architecture rather than around how each user role thought about the work. That finding emerged from 47 microtask observations across three user roles.

In the IDEXX Animana engagement, the starting brief was explicit but deliberately non-prescriptive: map user needs and pain points across the platform. The specific issues emerged from field research across 35 clinics in three countries. They included fragmented navigation between consultation screens, documentation flows that required repeated section changes during time-pressured consultations, and role differentiation between vets and nurses that the platform did not accommodate.

In the WCO/IPM engagement, the starting point was a deployed platform that was being routed around. The brief recognised an adoption problem. The specific reasons were diagnosed through direct research with operational teams: three user groups had incompatible information structures while sharing a single interface, and workflows required the platform only after tasks had already been completed elsewhere.

Fuzzy problem statements usually signal one of three diagnostic conditions

In complex software, a hard-to-articulate problem can mean the problem is real but diffuse. Users may be struggling in observable ways, while workarounds, unofficial procedures, and informal assistance mask the interface failures from formal reporting. The problem may appear in support ticket volume, onboarding duration, user turnover, or reluctance to let new colleagues attempt certain tasks unsupported.

A fuzzy problem statement can also mean the frame is wrong or too broad. “The interface is complicated” does not distinguish between essential complexity that reflects genuine domain difficulty and accidental complexity that accumulated without purpose. “Users do not engage with the advanced features” does not distinguish between features users do not want, features users cannot find, and features users find but cannot operate without expert guidance.

A fuzzy project brief can also encode disagreement about cause. The product team, engineering team, sales team, and support team may each have a different explanation for why users struggle. Creative Navy's Sandbox Experiments phase is used to produce shared understanding across competing explanations by grounding diagnosis in evidence rather than in advocacy.

Boundaries of a project brief in complex operational software

A project brief is useful when it exists, but Creative Navy does not treat it as the final account of the problem. The brief is a starting frame that can be tested, refined, or replaced through diagnostic conversation and direct research.

A client does not need to resolve the fuzzy-problem situation before speaking with Creative Navy. The point of the early engagement process is to convert an initial problem statement into an operational account specific enough to support design decisions.