How I run a design project from first call to final file

Most design projects don't fail because of bad design. They fail because of unclear expectations, feedback that arrives in bulk after weeks of silence, and a process that treats clients as approvers rather than collaborators.

Here's how I run a project. It's evolved through dozens of engagements and has one goal: no surprises at the end.

The first call

I don't take briefs before a first call. I want to hear the problem described out loud — unprepared — because that's where the real priorities surface.

Three questions I always ask:

"What does success look like 6 months after we launch?" This gets the client thinking about outcomes instead of deliverables. The answer tells me what actually matters.

"What has already been tried?" Every client has tried something. Understanding what didn't work — and why they think it didn't — tells me more about the constraints than any brief.

"Who has final approval, and what would cause them to reject the work?" Stakeholder mapping on the first call. If there's someone I haven't met who can kill the project in week 4, I want to know now.

The audit phase

Before I design anything, I review what exists. Current site, competitors, analytics if they'll share it, any brand guidelines. I'm not looking for what's ugly — I'm looking for what's working and what decisions were already made consciously.

Respecting past decisions (even bad ones) builds trust. Blowing up everything implies the client made nothing but mistakes, which is rarely true.

The alignment document

After the audit, I write a one-page alignment doc. Not a proposal — an alignment. It covers:

• The problem as I understand it
• The constraints (budget, timeline, scope)
• What I will NOT be doing (this is the most important section)
• The single metric we're optimizing for
• The decision-making process (who approves what, by when)

The client signs off on this before I open Figma. If they want to change scope later, we revisit this document together. Scope creep dies here.

Design in visible stages

I show work at three stages: rough direction, developed concept, final polish.

Rough direction: one or two moodboards or very rough wireframe directions. No colors, no fonts, no polish. The goal is to confirm we're solving the right problem before I invest hours in the wrong direction.

Developed concept: one direction, reasonably complete, real content where possible. This is where most of the feedback should happen.

Final polish: production-ready. By this stage, the only feedback that should arrive is bugs and copy changes. Structural feedback at this stage is a process failure — usually mine for not getting better alignment earlier.

I'd rather show rough work early and collect feedback than show polished work late and collect corrections.

Feedback rounds

I do two feedback rounds per stage. The first collects everything. The second addresses what was collected. If new feedback arrives after round two, it's a scope addition — handled separately.

The format matters. I send designs with specific questions attached: "Does the hero communicate the core value proposition clearly?" is better than "What do you think?" Open-ended questions produce open-ended (and often unfocused) feedback.

Handoff

Every project ends with a handoff doc: a plain-language explanation of the design decisions, what to do and not do with each element, and notes for the developer. This takes 2–3 hours to write and saves 10–15 hours of back-and-forth post-handoff.

The best handoff is one the developer never needs to email me about. I'm not always there — the document should be.

---

This process doesn't work perfectly every time. Clients are busy, stakeholders appear late, requirements shift. But having a documented process means deviations are visible and correctable, rather than just chaos that accumulates invisibly until launch day.