is a style change mid-project out of scope?

A revision refines work toward the visual direction everyone approved; a style change replaces that direction. Inside a revision round you adjust execution against a fixed target — refine the layout, tune the color, sharpen the type — all still serving the look the client signed off on. A style change moves the target itself: the client no longer wants the approved direction at all and wants a different one built from scratch. The tell is whether the approved direction still stands. If you're improving work toward the agreed style, that's the revision you owe; if the agreed style is being thrown out and replaced, that's a second design effort that cascades through everything already built on the old direction. The approval is the dividing line, which is exactly why locking it explicitly protects both sides.

It matters to the relationship but not to the scope. Approval is approval: when the client signed off on a direction, you reasonably relied on it and built downstream work against it, and their later realization that they weren't thrilled doesn't retroactively make that work free to redo. People do sometimes approve a direction and warm to it less over time, and you can be sympathetic to that without absorbing the cost of a full rebuild. Point gently back to the approval and the work it authorized, then offer the new direction as a change order. If the approval process itself was rushed or unclear, that's a lesson for how you lock directions next time — but for the current swap, the approved direction is the reference point, and rebuilding away from it is new work.

Then the change is much closer to absorbable, and judgment matters more than principle. The cost of a style swap scales with how much downstream work was built on the old direction; if you've barely started, the rebuild is small and the goodwill of flexibility may outweigh charging for it. A swap that lands after one screen is very different from one that lands after a dozen finished pages. Early, low-cascade changes are part of the normal texture of design work, and reaching for a change order over a single screen can read as rigid. Save the formal change order for swaps that force substantial rebuilding. The same request — 'let's try a different style' — can be a minor course-correction or a second project depending entirely on how much already depends on the direction being replaced.

Yes, and it makes your pricing both fairer and more convincing. A style swap is rarely total — the information architecture, the content structure, the discovery work, sometimes whole components survive the change of look. Itemizing what carries over and pricing only the genuinely new design work shows the client you're charging for labor rather than penalizing them for changing their mind. It also keeps the number honest, which keeps the conversation calm. The version of this that sours a relationship is quoting a full second project fee when half the structure still stands; the version that lands well is a clear ledger of what survives, what must be rebuilt, and the cost of the rebuild. Transparency about reuse is the move that lets you hold the boundary and keep the client's trust at the same time.

Lock it the same way you should have locked the first one — with an explicit written approval before you build, and a fixed number of revision rounds after. The risk in a mid-project style swap is that the new direction is even less settled than the client thinks, so rebuilding against an unconfirmed look just sets up a third version. Before you quote the change order, get the new direction approved in writing as a clear lock point, and make explicit that further direction changes are further change orders. This converts an open-ended 'let's try something different' into a bounded piece of work with the same protections as the original project. The structure that should have guarded the first direction — explore, approve, lock, revise within rounds — is exactly what guards the rebuild.

Name the direction-approval moment as an explicit milestone and spell out what it authorizes. State that the project includes exploring a set number of directions, that the client selects and approves one, and that this approval locks the visual direction for the downstream work — with refinements handled inside the agreed revision rounds and any change of direction after approval treated as a separate change order. That language does the quiet but crucial job of distinguishing the exploration you include from the wholesale swap you don't. It also gives you a specific clause to point to when a late style change arrives, instead of arguing from memory about what was agreed. A few precise sentences around the lock point prevent the most expensive version of this dispute before it can start.