No creative team sets out to build a broken process. It accumulates — one workaround at a time, one "we'll fix this later" at a time, until you look up one day and realize that making a simple design change requires touching six different tools and sending two status-update emails. The dysfunction is rarely dramatic. It's a slow tide.
We've talked to hundreds of creative teams across design agencies, in-house brand studios, and product teams. The broken processes aren't random — they follow recognizable patterns. Here are the five we see most often, and what they actually signal about what's gone wrong underneath.
Sign 1: You Have a "Final" File Naming Convention
You know the one. hero-banner-v3-FINAL.psd. Then hero-banner-v3-FINAL-client-notes.psd. Then hero-banner-v3-FINAL-client-notes-2.psd. Then — inevitably — hero-banner-v3-FINAL-USE-THIS-ONE.psd.
This pattern isn't a naming problem. It's a version control problem that's been patched with a naming convention. The real issue is that there's no single source of truth for what "current" means. Every team member has their own local copy, and the only way to assert which one is authoritative is to put it in the filename. It works, barely, until it doesn't — and when it stops working, you've already shipped the wrong version to a client.
Sign 2: You're Doing More Revision Rounds Than Deliverables
One deliverable, seven revision rounds. If this sounds familiar, the instinct is to blame the client for changing their mind, or the brief for being unclear. Sometimes that's true. But in our experience, more than half the time the excess revisions are caused by feedback that was misunderstood, partially implemented, or addressed in the wrong version. The designer was working from a different understanding than the person requesting changes.
Teams with centralized, spatially-anchored feedback average 2.1 revision rounds per deliverable. Teams routing feedback through email and chat average 4.7. That 2.6 revision gap is almost entirely explained by ambiguity — the content of the feedback didn't change, but the clarity of it did.
Sign 3: Approvals Happen Verbally and Are Disputed Later
The Zoom call ends, everyone nods, you proceed. Two weeks later, the stakeholder who nodded is asking why you made the change they clearly approved in that meeting. This isn't bad faith — human memory is genuinely unreliable for decisions made in passing during a busy call. Without a written record tied to the actual artifact that was approved, the approval effectively never happened.
The practical fix isn't to require sign-off on everything — that creates its own process overhead. The fix is to make written approval the path of least resistance, so it happens naturally rather than requiring extra effort.
Sign 4: Handoffs Require a Live Walkthrough
If every design-to-development handoff requires a 30-minute Zoom call to walk the developer through what they're looking at, that's a signal that the design isn't self-documenting. The developer shouldn't need an explanation to understand spacing, component states, interaction behavior, and asset specs. If they do, either the design files lack the context they need, or there's no shared language between design and development about what good documentation looks like.
The average handoff walkthrough call is 47 minutes. At two handoffs per project and 20 active projects per year, that's 31 hours of senior designer time spent narrating files that should have spoken for themselves. That's almost a full work week, per designer, per year.
Sign 5: You Can't Find the Reason a Decision Was Made
The footer color changed six months ago. Nobody remembers why. The navigation structure is the way it is because of a client request from 18 months ago that everyone has forgotten. A major layout decision was made to solve a problem that no longer exists, but since nobody documented the reasoning, the solution outlived the problem by years.
This is the most expensive broken pattern because it compounds silently. Every new team member inherits a set of design decisions with no context. Every design review has to reconstruct history from memory. Every attempt at updating the system risks accidentally undoing something that was there for a good reason that nobody can articulate anymore.
The fix isn't documentation for its own sake — it's building a process where context is captured as a side effect of normal work, not as extra overhead. When feedback lives alongside the design, when approvals are recorded, when version history is automatic, the decision trail builds itself. You don't need to ask people to write things down if the tools do it for them.
