Project Work Made Me a Stranger to Every System I Designed
For most of my career, I worked on projects. Discrete engagements. Scoped briefs. Define the problem, ship the solution, hand it over, move on.
It took me too long to realise that model is bad for the work.
The context tax
The first six weeks of any new client engagement are spent learning context the previous designer already had. The product's history. The team's politics. The customer's actual workflows. The decisions that look strange in the code but made sense at the time. By the time you understand any of it well enough to do strong work, you're already halfway out the door.
Then the engagement ends. The next designer arrives. They spend six weeks learning what you just learned. And what you learned walks out the door with you.
The economics of project work are great for design agencies. They're terrible for product quality. It's one of the reasons design subscriptions don't work either: both models trade depth for volume.
Every project handover destroys accumulated context. The new designer doesn't just lack knowledge of the product. They lack the judgment that comes from watching how users actually behave with it over time. They can read the documentation, but they can't read the history.
What retainer work changed
What changed everything for me was switching to retainer engagements. One day a week. Same client. For years.
Now I'm in the room when the product pivots. I see the customer interview that changes everything. I know why the original navigation pattern exists, because I designed it. When a new feature needs to be integrated, I'm not relearning the system. I'm extending it.
That accumulated context is the thing clients are actually paying for. Not the pixels. Not the deliverables. It's why I stay booked out: the context compounds into better decisions every week. The fact that someone with years of memory about their product is the one making the next design decision.
How the work compounds
The work compounds. Each engagement makes the next one sharper. Patterns get established. Trust gets built. The client stops briefing me on basics because I already know.
I know which stakeholders need visual evidence to be convinced. I know which parts of the codebase are fragile. I know which users complain loudest and which ones quietly churn. That context compounds into better design decisions every single week.
That's not consulting. That's partnership.
When project work makes sense
Project work isn't going away. Some engagements genuinely should be discrete. A founder shipping a new product needs a defined engagement with a clear outcome. A team with a specific design challenge, whether a redesign, a new feature, or a design system, can benefit from a focused project.
I still take project work when the fit is right. Some clients start with a project and move to retainer once the relationship is established.
But for any product that's going to keep evolving, which is most of them, the project model is a worse deal for everyone involved. The client pays for ramp-up time they've already paid for with the last designer. The designer never gets deep enough to do their best work. And the product accumulates layers of decisions made by people who didn't stick around to see the consequences. The best design work requires exactly the kind of sustained engagement that project work prevents.
---
