Project Briefs & Communication
.comKnownIntent
Start with what the requester actually said
KnownIntent suggests an intention that has been expressed and can be referred to. It could name a brief workspace, a collection of clarification resources or a documentation practice. The domain is held for development or acquisition. These directions focus on stated objectives and their context, without claiming access to private motives or treating a confident interpretation as confirmation.
A name with possibilities.
Overview
Known should point to an expression, not a guess
Intent concerns an aim or purpose. Known invites a question about how that aim has been understood. Together, the words can support an identity built around explicit requests and recorded clarifications. The surrounding copy should show where the understanding comes from and leave space for the person who made the request to correct it.
Stated purpose ↗A workspace for briefs that retain their source
A software direction could connect a project objective to the message or conversation in which it was stated. A first workflow might help a small design team separate a client’s requested outcome from a proposed layout change. The record would include the source wording, the team’s interpretation and any clarification received. KnownIntent gives this workflow a clear identity. The product description would need to explain how people review the record, rather than imply that software can automatically determine what another person really wants.
Resources for asking a better follow-up question
A resource collection could help people turn an incomplete request into a useful conversation. Each worksheet might identify what is already stated, what has been assumed and what answer would change the next step. The first examples could focus on ordinary project briefs, such as making an event page easier to navigate. KnownIntent fits this attention to shared understanding. A resource should produce a specific question or a clearer brief, rather than encourage endless interpretation without giving the requester a chance to respond.
Documentation for decisions made during a project
A documentation practice could help teams keep track of how a brief changes over time. An engagement might organise initial objectives, later clarifications and the choices made in response. KnownIntent would name the practice, while the service description identifies the actual records and deliverables. The work should distinguish a requester’s statement from the team’s decision about how to address it. This keeps the account useful when someone returns later and needs to understand why the current version differs from the original proposal.
Perspective
Keep the requested outcome separate from your first solution
Imagine a fictional organiser asking, “Make the timetable easier to find.” A designer immediately proposes adding a menu item. This original worksheet slows the jump from request to implementation long enough to identify what remains unclear. It is a planning example, not a report that a navigation change has been built or evaluated.
Confirm the brief ↗