The instinct, when giving clients access to a project, is to give them as much information as possible. Transparency builds trust. Clients who feel informed are easier to work with. The more they can see, the less they'll ask.
This is true up to a point. Past that point, too much client visibility creates its own problems: clients who are drawn into internal coordination conversations they're not equipped to interpret, who see work-in-progress sketches and react as if they're proposed designs, or who develop opinions about things outside their scope of decision-making.
The art is in deciding what clients should see — and enforcing that boundary consistently.
The Three Categories of Project Information
Not all project information is created equal, and not all of it belongs in front of the client.
Decision-ready information. — deliverables, formal submittals, approved items, decisions requiring client input. This is the core of what clients should see. It's curated, complete, and presented for a purpose: to inform a decision or to provide a record of what's been decided.
Status information. — schedule status, milestone completion, open items requiring client action. Clients benefit from knowing where the project stands. They don't need a live feed of the team's work-in-progress; they need a structured summary at regular intervals.
Working information.: internal coordination drawings, work-in-progress sketches, consultant coordination files, internal team communication. This is the engine room. It's messy by nature, that's what design iteration looks like. Clients who see it without context often misinterpret it, react to options as if they're proposals, or raise concerns about things that would have resolved themselves in the normal course of design.
The default rule: clients see decision-ready and status information. Working information stays internal.
When Clients Want More Access
Some clients, particularly sophisticated developers or institutional clients with in-house design staff, will push for broader access. They want to see the coordination files. They want to review the consultant drawings. They want to be in the communication channel with the consultants.
This can work. But it requires a different setup:
- Clear communication about what they're looking at and its stage of development
- Explicit agreement about the client's role in the process (review only, or actually providing input?)
- A protocol for how client feedback on working documents gets processed: does it go directly into the design, or does it route through the PM?
Without this structure, a client with broad access to working documents becomes a participant in the design process in ways that weren't intended, aren't accounted for in the scope, and can generate significant rework.
The Version Problem
One of the strongest arguments for controlling client access is the version problem.
When clients have broad, uncontrolled access to the project file system, they can access documents at any stage of development. They can download a drawing that's one week away from being revised and share it with their board before the revision is made. They can reference a spec section that's still in draft.
Controlled access, where clients see current, formally issued documents, not the full working set — prevents this. The client is always looking at what you intended them to see, at the stage you intended them to see it.
The Access Decision Framework
When deciding what access level to set up for a specific client, three questions:
What decisions does this client need to make?. Work backward from the decisions to the information they need to make them. Give them access to that. Nothing more as a starting point.
What's their comfort level with the design process?. A first-time client who has never managed a design project before will be confused and possibly alarmed by work-in-progress drawings. An experienced developer knows that a sketch isn't a proposal. Calibrate the access level to their experience.
What's the organizational complexity on the client side?. If the client is an individual, they control what they share. If the client is a twenty-person organization with multiple stakeholders, every document you share with the primary contact is likely to get forwarded to people who don't have context for it. This argues for more curation, not less.
Building the Right View
The practical implementation of this is straightforward: use an access control system that lets you set what each project participant can see, rather than relying on trust or informal agreements.
A client should be able to access current, approved documents organized by project. They shouldn't be able to browse the full project file structure. They shouldn't see internal team communication. And they shouldn't see documents that are still in draft.
This isn't about hiding information from clients. It's about giving them a professional, curated view of their project: one that serves them better than a raw dump of everything in the project folder.
Olumba's access model works this way: clients and external collaborators see exactly what you give them access to, scoped to their project. If this kind of structured client access is something your firm has been doing informally (or not at all), it's worth seeing how it works in practice.
