Ask an owner what matters in a project, and the list grows quickly. Space for the family. Natural light. A real connection to the yard. Quiet. Durability. A look that feels right. A budget that holds. Every item is sincere, and nothing on the list is wrong.
But a list isn't a brief.
A project without priorities has a list, not a brief
A list records everything that matters. A brief establishes something harder: what matters most when the things that matter begin to compete. And they will compete. Site conditions, zoning, the project budget and the schedule all place limits on what any project can do at once, which means every project eventually arrives at a moment where something has to give.
If that moment arrives and the priorities were never established, the decision gets made anyway — by assumption, by whoever happens to be drawing, or under the pressure of a deadline or a number that came back higher than expected. None of those is a good way to decide what a place should become.
Where objectives collide
Most of the real tradeoffs in a project are between things that are individually good:
- Generous spaceversusThe project investment
- Openness between roomsversusAcoustic privacy
- Daylight and viewsversusPrivacy and thermal comfort
- Preserving what existsversusAchieving the full program
- The earliest possible completionversusTime for investigation, approvals and coordination
- Lower initial costversusLong-term durability and operating cost
None of these has a universal right answer. The right answer depends on the project and the people it serves.
A project without priorities doesn't have a brief. It has a list.
Priorities aren't a ranking of everything
Establishing priorities doesn't mean numbering every item from one to thirty. That exercise usually collapses, because everything ends up near the top. It's more useful to sort what matters into a few honest groups: what has to hold no matter what, what matters strongly but could bend, and what's genuinely flexible.
The most reliable way to find those groups isn't to ask how important something is. Nearly everything is important. It's to ask tradeoff questions:
- If you could only have one of these two, which would you choose?
- If the project had to give something up first, what would it be?
- What would make the project feel like a failure even if everything else worked?
People often learn something from their own answers. A feature they assumed was essential turns out to be negotiable, and something they'd barely mentioned turns out to be the point of the whole project.
Why this belongs before design
Priorities are what design uses when conditions force a choice. With them, an architect can develop and recommend responses consistent with what the project has established as most important — and explain the tradeoffs clearly. Without them, every conflict becomes a question that has to be reopened, often late, when options have narrowed and changing course costs more.
Priorities aren't fixed forever. Site conditions, the project budget and what the design reveals can all change what's realistic, and a project can reasonably adjust. The point is that changes happen deliberately, against something the project has already established, rather than by default.
Definition includes what matters most
Defining a project isn't only gathering requirements. It's establishing the needs, the conditions and the investment — and what the project should protect when those pull against each other. That's the part a list can't do, and it's the part that lets design begin with a direction instead of an inventory.