To all notes

The project where the client loved the version you made in twenty minutes

Fast work that lands well is its own kind of mystery and the hardest part is trusting it without needing to explain it.

The version you almost did not send
You made it quickly because you were warming up. It was not the real attempt. It was the thing you do before the thing, a rough pass to get your hands moving before you committed to actually solving the problem. Somewhere in those twenty minutes a direction appeared that felt right in a way you could not immediately justify, so you set it aside and kept working. Hours later, with several more considered versions in front of you, you dropped the early one into the presentation almost as a placeholder. The client responded to it immediately. Not politely. Not with the measured enthusiasm that usually means they are being careful with your feelings. They responded the way people respond when something already looks like what they had in their head.
Speed did not make it good
The instinct after a moment like that is to build a theory. You tell yourself you were loose and open, that the absence of pressure freed you from overthinking. That is a comfortable story but it is probably not the accurate one. The work was not good because it was fast. It was fast because something aligned early, before you had the chance to second-guess it out of existence.
Fast work that lands well is not the absence of process. It is process that has gone quiet enough to stop getting in its own way.
Front view of the iPhone 03ML mockup displaying a vibrant app interface.
Why the quick version is so hard to defend
The real difficulty with work that arrives fast is that you cannot walk anyone through the process, including yourself. When a client asks what led you to a particular decision, you have a whole architecture of reasoning available for the work you labored over. You can describe the references you considered, the structural logic you tested, the alternatives you ruled out. With the twenty-minute version, the honest answer is that you opened a file and something appeared. That answer does not feel professional to say out loud. It does not sound like craft. It sounds like luck, which is uncomfortable in a field where expertise is supposed to be legible. So you reverse-engineer a rationale after the fact, which is a strange position to be in when the work is genuinely good and the client is genuinely happy. The process produced the right outcome without producing the kind of evidence you normally use to prove that you know what you are doing.
The twenty-minute version does not need a better explanation. It needs you to stop treating speed as evidence that something went wrong.
What fast work actually reveals
Angled view of a billboard mockup integrated into an urban street scene with buildings.
A version that arrives quickly and holds up under scrutiny is not evidence that process does not matter. It is evidence that your process has become internalized enough to run without narration. The judgment calls that would have taken you an hour of deliberate work happened in the background, below the threshold of conscious decision-making. That is not luck. That is accumulated experience operating without announcing itself. The problem is that internalized process is invisible, which makes it hard to trust and even harder to repeat on purpose.