Your web project.
The right questions.
You don’t need technical language to explain your idea. These seven questions help separate what is essential, what can wait and what still needs to be clarified.
Download the text brief No sign-up. Fill it in at your own pace.What should your website help people do?
“Having a website” describes the medium, but not yet the need. Should someone understand your offer, request a quote, view a document or use a tool?
Fill in: “When someone arrives, I want them to be able to ______, then ______.”
For this portfolio, the intended journey is simple: understand the offer, explore the projects and then describe an idea by email. It does not require an account.
Who is it for, and in what situation?
Think of a specific person: what they are looking for, what they already know and the device they use. A client reviewing a deliverable has different needs from a traveller looking for help on the move.
In Feavara’s origin story, vanlife and unexpected situations define the context. This is a design intention for the prototype, not evidence of expertise already achieved.
Note the main audience, their question on arrival and what might stop them from moving forward.
What needs to work first?
Write out an end-to-end journey before listing lots of features. For example: open a project → view its latest version → leave a comment. Then separate essential needs from ideas to explore later.
The Portail-agence mockup illustrates this focus on next actions. Its data is fictional: it helps discuss the interface without serving as proof that private workflows work.
Two lists are enough: “needed at the start” and “can wait”. Payments, connections to other services and multiple user roles each deserve a separate discussion.
What do you already have?
Gather your copy, logo, photos you have permission to use, project examples and the contact details you want to make public. Identify what still needs to be written, photographed or approved.
For visual references, explain what you like: typography, contrast, navigation or atmosphere. You can also show what you don’t want. A reference guides the discussion. It does not mean it should be copied.
Include two or three references with comments and a list of existing materials. There is no need to send all your files.
What needs to stay private?
Say whether the project will involve accounts, messages, internal documents or personal information. Specify who should see what: visitor, client, team member or administrator.
Do not send passwords, API keys or confidential client documents in an initial brief. Describe the need using fictional examples. Required access and how to manage it should be defined separately.
Clarify the roles, the information actually needed and what can be shown publicly.
What requirements must the project meet?
Does a domain already exist? Is there a tool to keep, a planned launch or someone who needs to approve the work? Note your preferred timeline and any flexibility.
If you know your budget, give a range and say whether it also needs to cover hosting or other services. Otherwise, simply write “to be defined”. The brief prepares a discussion. It is neither a quote nor a commitment to a deadline.
Note what needs to be preserved, known technical constraints, your expected budget and preferred date.
How will you know it is useful?
Choose a few observable situations: someone finds information on a phone, a client finds the right version, or a visitor understands how to contact you. User journey tests check these actions.
Visits, enquiries and sales are different things. Decide what you want to track without promising business results before you have data.
Fill in: “The project is useful if someone can ______ without ______.”
A few answers are enough to get started.
You can send me your brief or just a few lines about your idea. You don’t need to have every answer.
Describe my projectDevoryo · design and creative direction. Development with Codex.