How Architects Turn Unclear Client Briefs Into Better Design Direction

A client's initial brief may reflect trends or assumptions rather than their actual needs. Understanding their daily routines and frustrations helps uncover their real priorities. For example, a homeowner may want a larger bathroom when poor storage and fixture placement are the real issues. A smarter layout could solve these problems without expanding the space.

The focus shifts from expansion to improving the existing layout. Better fixture placement, built-in storage, and improved circulation can increase comfort while reducing costs. This approach addresses the client's actual needs rather than their initial assumptions. This is an illustrative scenario, but it shows how a simple conversation can influence an entire project.

Once the client's needs are clear, confirm their priorities before refining the design. Discuss essential features, personal preferences, and practical limitations using sketches and layout options. Early feedback helps prevent misunderstandings and costly changes. Listening and questioning assumptions lead to better, more practical designs.

When a brief is thin, I go after what's underneath it fast. Somebody tells you "we need more space" or "this kitchen has to go," and that's rarely the whole story. Maybe they can't host the holidays anymore. Maybe the stairs are turning into a problem. Maybe the house has to move in 45 days because the carrying costs are bleeding them dry.

I've been buying homes across New Jersey for 10 years, and the first brief is almost always a blend of three things. Some facts, some worries, and a pile of guesses. So I ask questions that drag the guesses into the open. What's the problem you're actually trying to solve first? What happens if nothing changes for six months? Who else has to live with this call? Where's the money ceiling before this stops making sense? Ask it that way and people answer differently. They quit talking about finishes and start talking about the pressure they're under.

The conversation that flipped a direction for me was an inherited house in Union County. The family came in talking full gut renovation, because the place looked rough. Old carpet, a dated kitchen, maybe $80,000 in obvious repairs staring you in the face. Twenty minutes in, the real issue surfaced, and it had nothing to do with design taste. Two of the heirs lived out of state, one of them wanted the sale closed before winter, and not one of them wanted to deal with permits or a cleanout. Follow that first brief and you're looking at a big renovation and a sale that drags for months. The right move was an as-is purchase, fast closing, and we handled the cleanout after we closed.

For architects it's the same trap. Don't take the stated request at face value. Client wants an addition? Ask what daily headache the addition is supposed to kill. Client wants an open kitchen? Ask what's actually broken about how they cook and eat and gather right now. The brief you can use is usually buried in the awkward stuff nobody leads with. Budget, timing, family friction, and what they're quietly scared will happen if the whole thing stalls out.

I never rely completely on the initial client brief; it is more of an introduction. When beginning a new project, I ask to visit clients in their current space and our discussion in addition to their original brief provides the program direction. Before our meeting, I always ask them to answer (in list form) two questions, what are the "must have" requirements and what are the "desired" items. It is helpful for them to distinguish between what is non-negotiable and what they think might be nice to have. It is also helpful for me to observe clients in their current space to better understand what is working for them and what problems are impacting what they believe they need in a new space as outlined in the initial brief. I can clearly assess why they created the initial program brief and see any issues they currently are confronting. In the design process I focus first on the must have items and then see how many extras make sense while keeping budget and spatial constraints in mind.

I begin by trying to understand why each item in the request was requested (the decision-making process), because this provides me with flexibility when responding to the client's request. Then, I explore who will actually use the space during the entire course of the day, what problems exist now that need addressing, and which items are truly important. This helps identify the minimum requirements for all users, and whether or not these requirements were part of the original thinking.

The main takeaway from my experience has been that the initial (first) request of clients isn't always the real issue they are trying to resolve. An architect's best course of action will be to identify what problems or needs lie beneath the surface prior to designing potential solutions for their client. A simple way to start identifying problems/needs is by asking, "What would you like to see changed in your life if we were able to improve only one aspect of this project?" This is helpful because it gives the architect a good starting point for developing various different solutions without being tied down to any single solution.

We usually ask more questions to gain clarity but it can't be any questions and that decision depends on what the underlying reason for the unclear brief is. Sometimes decision-makers don't realise what they need or what the problem is. Sometimes the end user can't see beyond what they know to understand what could work better. Sometimes it is competing requirements creating a conflicting set of recommendations that dilutes the core vision of the project. There are occasions where designers are expected to suggest a solution off of incomplete information, of course, and in those times engagement may not be possible, but it is beneficial to try and support the process of brief building as much as possible. Our role (whether as designers/architects or consultants in environmental psychology/evidence-based design in my case) is to work with teams to uncover what that challenge is about. We may run codesign workshops, share engagement surveys, conduct interviews and focus groups. Sometimes we may also come with evidence from research (academic or industry-based) that the client can respond to, or images and findings (eg POE) from similar projects with the intention to start a discussion rather than set a direction. There is no single approach that solves everything every time. There may be general patterns and common challenges across projects and sectors, but equally each project has its own challenges and opportunities as much as it has its own occupants and decision-makers with unique views and experiences. The most important thing is to start this process with curiosity and the right tools (whether methods, frameworks, precedents or evidence) to support/facilitate teams in coming to their own conclusions about what they need rather than necessarily directing them as 'the expert'. We may have technical expertise but the end users, occupants and project owners are the experts of their own lives and spaces, so we ought to listen first. That usually also solves a lot of problems down the line, buy in issues, disagreements, trust-building etc.

I would start by asking how the client expects to use the space day to day, rather than treating the first brief as fixed. That conversation usually exposes assumptions about layout, storage, access, privacy and future needs that drawings alone will not reveal. The early question I favour is, "What would make this space frustrating to live with?" It often identifies practical constraints before they become expensive design changes.

Incomplete briefs are normal. The client knows their business problem, not the spatial solution, so the gap is expected.

The question we ask early that changes everything: "What breaks down in the space you have now?" Not what they want, but what's failing. That answer is almost always more honest than a wishlist.

With one Nordic client, the brief came in as "modern open office, glass partitions, Scandinavian feel." Standard. But when we asked what wasn't working in their current layout, the answer was that their senior team was constantly interrupted and had stopped doing deep work at the office altogether. The real brief became about acoustic separation and focus zones, not aesthetics.

Running 3D Studio alongside Pageloot since 2018 taught me that clients in both worlds arrive with a surface-level ask. The faster you get to the operational pain underneath it, the less rework you do later.

The other thing worth doing early: show rough spatial concepts before the brief is finalized. Not polished renders, just massing and flow diagrams. Clients react to something visible in ways they can't when it's abstract. You learn more from one reaction to a rough layout than from three briefing calls.

The goal in that first conversation isn't to gather information. It's to find the constraint they haven't named yet.

When an initial requirement is incomplete, I avoid starting with the requested technical solution. I first try to understand the business decision the stakeholder is attempting to make. Often, the first request describes what someone thinks should be built rather than the underlying problem they need solved.

One early conversation that has helped me is walking through the expected output metric by metric.I ask what each metric means to the business, what should be in or out, what exceptions are there and what users expect to happen in unusual cases. Those conversations often reveal assumptions not obvious from a schema or technical specification alone.

I've seen requirements that initially appeared to call for changes to the reporting structure become much clearer once the underlying business rules were discussed. Sometimes the real issue is not the final report at all, but how data is transformed or classified upstream.

My rule is to clarify the decision before designing the architecture. A technically elegant system can still be the wrong solution if it was built around an untested assumption.