By the end of the lesson, you can narrow the semester project to a single, manageable task. You can tell the proven elements of the brief from assumptions, and you can map who is affected by a decision beyond the end user.
Why do we need a brief?
After the research you have many ideas, directions, and opportunities in front of you. The biggest danger then is not that there are few options, but that you want to solve everything at once. The brief guards against this: it records what you take on and what you do not. A well-written brief is the point you can return to during the project when a new idea would extend the scope, or an argument would draw attention away from the main task.
What is the brief for?
A project brief is a document recording the problem, goal, frames, and open questions of the project. Let us look at a weak and a good version:
Weak: "I am designing an app for university administration." This points to too many people, processes, and consequences; no testable task can be derived from it.
Better: "I will examine how a first-year student can identify and submit the documents needed for a single supplementary application, without searching in several places for contradictory information." Here the user, the task, the assumed obstacle, and a designable boundary are already visible.
The basic elements of the brief
For a semester project it is generally enough if the brief contains the following.
Element
Question
Example (Mai program)
Problem area
What situation do you examine?
Students' choice of an evening program
Target user
Whom do you design for?
A student looking for a spontaneous program
Primary task
What do they want to achieve?
Choose a suitable program for tonight
Current situation
How do they solve it today?
On several pages, based on friends' messages
Organizational goal
What does the operator want?
As many events and users as possible
Constraints
What sets limits?
External data sources, no payment integration
Research questions
What do you not yet know?
Which data are decisive?
Success criterion
How do you know it is better?
Finds a suitable event within two minutes
Exclusions
What do you not take on?
Payment, organizer interface, reviews
The exclusion is especially important: for example, the project does not deal with developing the back-end system, payment, or every possible user role. An exclusion is not a weakness, but a conscious decision.
For every sentence, ask where it comes from. A brief can be started from client information, your own observation, or preliminary research, but do not mix these together. "Students do not understand the process" can be an assumption to research, while "there are three different forms in the system" is a verifiable fact. Use the evidence labels learned in chapter 1.
Scope and decision discipline
The scope is the boundary of the tasks taken on in the project and consciously excluded. Narrowing the scope is not belittling the problem, but a condition of learning. If you want to design everything in a prototype (search, account management, notification, payment, admin interface), you will research or test none of the decisions in a meaningful way. Choose one high-value, high-uncertainty task, and draw a clear start and end around it.
A useful question: at which point would the user suffer the greatest loss if they made an error or gave up? This can be choosing the right service, checking the data, or interpreting the confirmation. The goal of the brief is not to answer everything, but to mark which questions deserve research.
In a semester project, a well-researched and tested solution of a single high-risk task is a much stronger result than ten merely drawn screens.
Who are the stakeholders?
A stakeholder is a person or organization who is affected by the service or a design decision, or who affects it. There are stakeholders beyond the target user. In an administration interface, a stakeholder can be the clerk who receives incomplete applications; the department that sets the rule; the IT operations that maintain the system; and the student's helper to whom they turn when stuck.
A stakeholder map does not mean that you build a separate product for everyone. It means that you see who provides data, who makes rules, who bears the consequence of the error, and who may later be a decision maker.
Make a table:
Stakeholder
Goal / interest
Effect on the project
Open question
Student (target user)
Find a suitable program quickly
The main task
Which data are the most important?
Event organizer
As many participants as possible
They provide the data
How much data are they willing to provide?
Operator (university organization)
An active, reliable service
Decides on the frames
What metric do they watch?
Maintainer
A maintainable system
Technical constraint
In what format do they get data?
This reveals conflicts early. The user wants fast submission, but the clerk wants complete documentation. A good design does not necessarily choose one over the other: for example, with a preliminary check and clear requirements the burden on both sides can be reduced.
A useful addition is the power–interest grid: you place the stakeholders on two axes (how affected they are, how much they can influence the project). It is worth consulting early with the high-influence, high-interest actors; for the low-influence ones it is enough to inform them.
Worked example: the brief of Mai program
First idea: "searching for events and managing registration in one place". Before research, however, it is not known whether users decide rather by price, location, group size, or time. The research (chapter 2) showed that price, language, and registration requirement are decisive. The brief therefore narrows to:
Comparing tonight's events and understanding the registration requirement for a student looking for a spontaneous program.
It excludes payment integration and the organizer interface, but notes that these are external constraints. The stakeholder table shows that the data quality of organizers is a condition of success, so in the brief there is a separate open question: "How much data are organizers willing to provide?".
Common misconceptions
Claim
Clarification
"The brief is the client's business, not the designer's."
The designer also has to understand it and, if needed, ask back about the frames.
"The more features it contains, the better."
The brief gives focus; the exclusions are as important as the commitments.
"A stakeholder map is unnecessary in a student project."
Even a simple table reveals hidden conflicts and constraints.
In brief
The brief records what you take on and what you do not, and names the source of the claims.
Narrowing the scope is a condition of learning; one task examined in depth is worth more than many superficially.
The stakeholder table reveals who has what goal, who provides data, who bears the consequence.
Review questions
What is the single task in your project that you can research and test through to the end?
Which of your brief's claims is a fact, and which is only an assumption?
Who would bear the greatest consequence if the main task failed?
Project brief and stakeholders
Objectives
By the end of the lesson, you can narrow the semester project to a single, manageable task. You can tell the proven elements of the brief from assumptions, and you can map who is affected by a decision beyond the end user.
Why do we need a brief?
After the research you have many ideas, directions, and opportunities in front of you. The biggest danger then is not that there are few options, but that you want to solve everything at once. The brief guards against this: it records what you take on and what you do not. A well-written brief is the point you can return to during the project when a new idea would extend the scope, or an argument would draw attention away from the main task.
What is the brief for?
A project brief is a document recording the problem, goal, frames, and open questions of the project. Let us look at a weak and a good version:
The basic elements of the brief
For a semester project it is generally enough if the brief contains the following.
The exclusion is especially important: for example, the project does not deal with developing the back-end system, payment, or every possible user role. An exclusion is not a weakness, but a conscious decision.
For every sentence, ask where it comes from. A brief can be started from client information, your own observation, or preliminary research, but do not mix these together. "Students do not understand the process" can be an assumption to research, while "there are three different forms in the system" is a verifiable fact. Use the evidence labels learned in chapter 1.
Scope and decision discipline
The scope is the boundary of the tasks taken on in the project and consciously excluded. Narrowing the scope is not belittling the problem, but a condition of learning. If you want to design everything in a prototype (search, account management, notification, payment, admin interface), you will research or test none of the decisions in a meaningful way. Choose one high-value, high-uncertainty task, and draw a clear start and end around it.
A useful question: at which point would the user suffer the greatest loss if they made an error or gave up? This can be choosing the right service, checking the data, or interpreting the confirmation. The goal of the brief is not to answer everything, but to mark which questions deserve research.
In a semester project, a well-researched and tested solution of a single high-risk task is a much stronger result than ten merely drawn screens.
Who are the stakeholders?
A stakeholder is a person or organization who is affected by the service or a design decision, or who affects it. There are stakeholders beyond the target user. In an administration interface, a stakeholder can be the clerk who receives incomplete applications; the department that sets the rule; the IT operations that maintain the system; and the student's helper to whom they turn when stuck.
A stakeholder map does not mean that you build a separate product for everyone. It means that you see who provides data, who makes rules, who bears the consequence of the error, and who may later be a decision maker.
Make a table:
This reveals conflicts early. The user wants fast submission, but the clerk wants complete documentation. A good design does not necessarily choose one over the other: for example, with a preliminary check and clear requirements the burden on both sides can be reduced.
A useful addition is the power–interest grid: you place the stakeholders on two axes (how affected they are, how much they can influence the project). It is worth consulting early with the high-influence, high-interest actors; for the low-influence ones it is enough to inform them.
Worked example: the brief of Mai program
First idea: "searching for events and managing registration in one place". Before research, however, it is not known whether users decide rather by price, location, group size, or time. The research (chapter 2) showed that price, language, and registration requirement are decisive. The brief therefore narrows to:
It excludes payment integration and the organizer interface, but notes that these are external constraints. The stakeholder table shows that the data quality of organizers is a condition of success, so in the brief there is a separate open question: "How much data are organizers willing to provide?".
Common misconceptions
In brief
Review questions