What One Day a Week of Senior Product Design Actually Gets You
"One day a week" is easy to sell and easy to misunderstand.
Founders hear it and picture one of two things: a consultant who turns up to nod at a roadmap, or a full-time designer at a discount. It is neither, and the gap between those two pictures is where most disappointment with fractional design comes from.
Here is what the month actually looks like, including the parts that are less flattering.
Week one: the day is mostly listening
The first day with a new product is not a design day.
It is a day of watching people use the thing and asking why it works that way. Support tickets, sales call recordings, the onboarding doc nobody has updated, and the spreadsheet someone built to work around a missing feature. That spreadsheet is usually the most honest design document in the company. Somebody diagnosed a problem precisely enough to build a workaround for it, and then never told anyone it was a problem.
I am also working out something less comfortable: whether the thing you have asked for is the thing you need. Most briefs arrive as a solution. "We need to redesign the dashboard" is a solution. The problem underneath it might be that nobody can tell which jobs are late, and that might not be a dashboard problem at all.
Nothing ships that week. If that is a problem, the retainer model is the wrong purchase and a scoped project is the better one.
Weeks two and three: the work compounds
By the second day I have enough context to make decisions without asking permission for each one. That is the whole point of the model.
A day of design work from someone who already holds the product in their head is worth considerably more than a day from someone rebuilding that context each time. The second day is not twice the first day. It is closer to four times, and the gap keeps widening for the first couple of months.
A typical day in this stretch:
- Two or three hours on the current problem, uninterrupted
- An hour with engineering on what is being built right now, usually catching something that would have been built wrong
- The rest on the next thing, so there is always work ready when the team gets to it
This is the same argument as giving one client one full day. Depth needs room, and a sliced day never gets there.
Week four: the unglamorous half
Edge cases. Empty states. Error states. Permissions. What the screen does when the data is missing, wrong, or there is far too much of it.
This is the work that determines whether people keep using a product, and it is the first thing cut when design capacity is thin. Not because anyone decides it is unimportant, but because it never feels urgent in the week it should be done. It becomes urgent later, as a support load nobody attributes to design.
It is also the work most designers won't go near, which is exactly why it is worth buying deliberately rather than hoping it gets absorbed.
What the month produces
Concretely, over a typical four-day month on an existing product:
- One substantial area designed properly, end to end, including the states nobody asks for
- A handful of smaller decisions resolved as they come up
- Whatever engineering needed unblocked, usually same week
- A running view of what is coming next, so the following month does not start cold
What one day a week does not get you
Worth being blunt, because these are the expectations that break retainers.
Not a design system from nothing in a month. A system is months of work and needs engineering committed alongside it. A day a week can start one, or maintain one, but it cannot conjure one.
Not in-house responsiveness. If you need something reviewed on Tuesday and my day is Thursday, it waits until Thursday, or we move the day. Most teams adapt to this within a fortnight and it stops mattering. Some cannot, and for those an in-house hire is genuinely the right answer.
Not linear scaling. Two days a week with one person is not the same as two designers. It is one person with more hours, which helps, but it does not parallelise. If your roadmap genuinely needs more than one person can hold in their head, you need a team, and I will tell you that rather than sell you a second day.
Not a substitute for product decisions. I can shape a decision, argue for one, and show you what each option looks like. I cannot make it for you. Retainers stall when design is treated as the place where strategy gets decided by default.
The dependency nobody plans for
The thing that most often slows a retainer down is not design capacity. It is access.
If I cannot talk to the people using the product, I am guessing, and guessing at pace is just a faster route to the wrong answer. The engagements that work have a standing way for me to reach real users: a recurring call, an intro to two or three of them, permission to sit in on support.
The ones that stall are the ones where every question routes through a product manager who is already at capacity. The design does not get worse in an obvious way. It gets more generic, because generic is what you produce when you cannot check.
What it costs you, beyond the fee
Three things, and it is fairer to say so up front:
Some coordination. A standing day works best when the team knows it is coming. Roughly an hour a week of someone's time to keep things pointed in the right direction.
Decisions on a cadence. Work arrives continuously, so approvals have to as well. A retainer paired with a two-week approval cycle wastes most of what you are paying for.
Tolerance for the first month. Month one is the worst value you will get, because context is being built rather than spent. Month three is where the model justifies itself. If you need to prove value inside four weeks, buy a project instead.
Who this suits
A product that exists, has users, and has outgrown the design attention it is getting. Usually a team where engineering is moving faster than the design decisions being fed to it, and where someone has started noticing that features ship and adoption does not follow.
If you are pre-product, with nothing built and no users, a scoped project is a better use of your money. You need a set of decisions made well, once, not a continuous cadence against a product that does not exist yet.
If you already have an in-house designer and the problem is seniority rather than capacity, a short engagement aimed at specific hard problems beats an ongoing day.
If that first description sounds like your situation, email me a bit about the product and I will tell you honestly whether the retainer is the right shape for it, including when it is not.
---
