Clients say it with good intentions. "I trust you — just make it look good." They mean: I don't want to micromanage you. I'm not a designer. I'll know it when I see it.

What they're actually saying, from a project management perspective, is: I have no definition of done, and I'll evaluate the work against whatever I feel when I see it.

That's the most expensive thing you can say to a developer.

What happens when scope is undefined

When a project starts without a clear definition of what "good" means, everyone fills in the blanks differently. The developer builds what seems good to them — their sense of aesthetics, their defaults, their interpretation of the industry. The client sees it and realizes their mental image was different.

"I was thinking more modern." "The other site I liked had a different feel." "Can we try it with more color?" "This isn't quite what I had in mind."

All of this feedback is valid. None of it was predictable. And now both parties are in an uncomfortable position: the developer has built something earnestly, the client doesn't love it, and there's no shared definition to return to and evaluate against.

This is where revision spirals start. Each round of feedback produces another round of interpretation, another round of changes, another round of "I'll know it when I see it." The project stretches. Frustration builds on both sides.

The developer thinks the client is indecisive. The client thinks the developer isn't listening. What actually happened is that neither of them defined success before the work started.

Why "I'll know it when I see it" is a dangerous standard

This phrase is understandable. Aesthetics are hard to articulate before you've seen something. But it sets a standard that's impossible to design toward.

When the evaluation criterion is the client's gut reaction to something they haven't seen yet, based on a mental image that exists only in their head, the feedback will always reference that unexpressed image. "Not quite right" means "not what I was picturing," and what you were picturing is only fully visible after you see something that isn't it.

The fix isn't to eliminate subjectivity — it's to create shared reference points before work begins. Not a full design spec, just enough to triangulate the direction.

What "looking good" actually means

Before any design work starts, it's worth spending time on a few concrete questions:

Who is the audience? Design that appeals to a 55-year-old financial planner is different from design that appeals to a 28-year-old startup founder. "Looking good" means different things to different audiences.

What do you want people to feel when they land on the site? Trustworthy and established? Innovative and fast? Approachable and warm? These aren't the same, and they produce different design decisions.

What do you like and not like? Three or four example sites with specific notes — "I like the photography style here," "I like how this one uses white space," "I don't want anything that looks like this" — are worth more than a thousand words of description.

What's the primary action? Design decisions that support a single primary call to action are different from design decisions for a content-heavy site. Knowing what the site needs to do shapes what "good" looks like.

What to say instead

You don't have to hand over a detailed design brief to avoid the "just make it look good" trap. You just need to give the designer or developer enough to work from:

"Our audience is small business owners in their 40s and 50s. We want to feel established and trustworthy, not flashy. Here are two sites I think are close to the vibe we want. The main thing we want people to do is schedule a call."

That's one paragraph. It's enough to design toward. It's enough to evaluate against. It makes the feedback process substantially less subjective.

The developer can now make decisions that are grounded in something you've both agreed on, and you can evaluate the work against that shared standard instead of an unexpressed internal image.

The time this saves

The most expensive revisions are the ones that happen because the work went in the wrong direction, not because it was executed poorly. Catching a directional misalignment after one wireframe is cheap. Catching it after two weeks of development is not.

Upfront clarity doesn't eliminate all revisions. Design is iterative and there will always be things you want to adjust once you see them. But the revisions become refinements rather than redirections — which is a significantly cheaper and more productive loop.

If you're starting a web project and want to think through what "good" actually means for your specific situation before anyone opens a design tool, get in touch. That conversation is where good projects start.