Digital products ·
An AI-assisted brief does not begin with a prompt
AI can produce a substantial technical brief for a website or app in a minute. It may contain roles, features, integrations and even a recommended stack. A convincing structure, however, does not prove that the problem has been understood. A good brief begins with decisions made by a person; AI helps make those decisions explicit and coherent.
Begin with the intended change
“We need a website” identifies only a presumed form. It says nothing about who will visit, what they should understand or do, or which result the business expects. The same question applies to an app: what work moves into the new interface, and why is the current way no longer sufficient?
Start with the change that should occur. A client can choose a service without calling. An employee no longer copies data between a spreadsheet and the CRM. A manager sees a deviation before the end of the month. This definition establishes the boundary of the project better than a list of screens.
AI can examine the statement, ask clarifying questions, find a missing participant and expose a result that cannot be verified. The answers must still come from the real process rather than the model's most probable template.
A journey matters more than a feature list
A list such as “registration, account, notifications” appears specific without explaining how someone reaches a goal. An account may store documents, display an order status or manage a subscription. These are different products with different data and risks.
A journey connects the person, starting point, action and result. What do they know at the beginning? Which information do they enter? Where do they choose? What follows confirmation? How can they correct an error or return to unfinished work? The answers turn a feature into observable behaviour.
AI is useful as an interlocutor that walks through the journey in several roles. It can act as a new customer, an experienced employee or an administrator and reveal a missing transition. Each resulting assumption then needs to be checked with the people who will use the product.
Data and exceptions define complexity
Two websites that look identical on a diagram may work very differently. One displays a prepared catalogue. Another calculates a personal offer, checks stock, creates a contract and sends the order to an external system. Visually, this may be one button; technically, it contains several dependencies.
The brief should therefore name the source of every important value, the owner of that data and the expected response to failure. What happens if the CRM is unavailable? Can a payment be repeated safely? Who corrects a wrong address? Which information may a user delete? Exceptions reveal the real scope before it emerges in code.
AI can suggest edge cases, but it does not know the company's internal rules. Its list is material for discussion rather than a finished product policy.
Constraints protect the Concept
A brief often states what the system should do while omitting what it must not do. Constraints preserve direction. The first version accepts one type of request. An agent prepares a response but cannot send it. The app stores the minimum personal data. A person must approve every non-standard price.
These boundaries reduce hidden decisions during development. Without a written constraint, a model or developer will select a plausible option. It may work technically while contradicting the business, the law or the character of the product.
Devices, languages, accessibility, speed, security and required integrations should be recorded separately. They are not additions to the design; they are part of the product's form.
Write acceptance before implementation
“Make the interface convenient” cannot be accepted or rejected. A verifiable criterion describes conditions and an observable result: a new customer submits a request from a phone; the manager sees it in the CRM within one minute; a repeated submission creates no duplicate; an integration error remains visible without losing the entered data.
Acceptance criteria belong beside the journey, before development is complete. They help define the first version, prepare test data and distinguish a finished path from an attractive demonstration.
Within the Method, I use AI to clarify and test a brief without handing over the definition of the problem. The Concept defines the intended change, journeys describe the path, constraints hold the boundary, and acceptance criteria connect the product's promise to its real operation.
Start with the website's purpose
If you are planning a website or rethinking one, we can begin with its role in your business, its structure and the visitor's path to an enquiry.