client-communication March 25, 2026 10 min read

How to Present a Website to a Client: A Freelancer's Step-by-Step Guide

The way you present a website to a client determines the quality of feedback you get back. A staging link dropped into an email with "let me know your thoughts" invites reactive, scattered feedback. A structured presentation — even a simple one — produces focused, useful input that leads to fewer revision rounds and faster sign-off. This guide walks through exactly how to present a website to a client at every stage of a project, from first design to final approval.

Why the Presentation Moment Matters

Most freelancers treat presenting a website as an afterthought — you build the thing, you send the link, you wait. But the presentation moment is actually one of the highest-leverage points in the project.

When clients receive a website without context, they respond to their first impression, which is emotional and unfocused. They notice the color that feels slightly off, miss the navigation structure you spent a week thinking through, and send you three-paragraph feedback that's really about one button.

When clients receive a website with context — a brief explanation of what they're looking at, what to focus on, and a clear mechanism for leaving feedback — they engage with the work as collaborators rather than critics. The feedback quality goes up, the rounds go down.

Step 1: Choose the Right Format for the Stage

Different project stages call for different presentation formats.

Early-stage design (wireframes, style direction): Keep it lightweight. A short Loom video (3–5 minutes) walking through the thinking is more effective than a live call at this stage. The client can watch it when they're ready, pause, and review. Follow it with a visual feedback link for written comments.

Mid-project review (first full design or staging build): This is the main event. A live call works well here — you walk through the site together, explain the decisions, and invite real-time reactions. Follow the call with a dotts link so written feedback is structured and anchored to specific elements.

Late-stage review (near-final version): Async works fine here. Share a visual feedback link with a clear focus: "This is the near-final version. Please focus on anything that needs to change before we go live — copy errors, anything broken on your device, or anything that feels wrong. We're not making structural changes at this stage."

Step 2: Set Context Before Sharing the Link

Never share a staging link without a brief context message. This is one of the most impactful habits you can build, and it takes two minutes.

A good context message answers four questions:

What are they looking at? (Which pages, which version)
What should they focus on? (What stage of review this is)
What should they not focus on? (Placeholder copy, images not yet finalised)
When do you need feedback by?

Example:

"Here's the first full build for review: [link]. This includes the homepage, About, Services, and Contact pages. At this stage, please focus on layout, overall feel, and whether the content is accurate — we're not finalising copy or fine-tuning fonts yet. Placeholder images are marked with [IMAGE]. Feedback deadline: Thursday. You don't need to create an account — just click on anything you want to address and leave a comment."

That message takes 90 seconds to write and eliminates the most common sources of unfocused feedback.

Step 3: Use a Visual Feedback Tool, Not Email

Once you've set context, the feedback mechanism is the other half of the equation. Email invites descriptions. A visual tool invites precision.

With dotts, you share a link that opens the staging site in review mode. The client clicks anywhere on the page — a headline, a section, a button — and leaves a comment pinned to that exact location. You see a pin map of everything they flagged, each comment anchored to the pixel they meant.

The difference in feedback quality is significant. Instead of "the hero looks off", you get a pin on the hero image with a note: "This photo feels too generic — can we use one from our office?". Instead of "something on the contact page", you get a pin on the form with "The submit button color doesn't match our brand."

Each comment also includes the client's browser and screen size automatically — which matters when they report layout issues you can't reproduce on your setup.

Step 4: Walk Through It Together (When Possible)

For major milestones, a live walkthrough is worth the time. Not because the client can't review on their own — but because the conversation you have during a walkthrough surfaces things that never make it into written feedback.

Clients hesitate to write certain things. They'll think "this whole section feels wrong" but write "maybe tweak the spacing?". In a live call, that instinct comes out naturally, and you can address the real issue instead of the symptom.

A good walkthrough structure:

Set the frame: "I'm going to walk you through the thinking behind each section before we talk about changes."
Explain, don't just show: Tell them why you made the decisions you made. This prevents feedback driven purely by preference from overriding strategic decisions.
Invite reactions section by section: Don't let feedback pool up at the end. Pause after each section and ask: "Does this feel right? Anything here?"
Capture everything in writing after the call: Send a summary of what was discussed and agreed, and share the dotts link for any written additions.

Step 5: Frame What 'Good' Looks Like

Clients who've never worked with a designer before don't know what to look for. Before asking for feedback, tell them what good feedback looks like.

A short note in your presentation message does it:

"As you review, helpful feedback sounds like: 'The headline on the services page doesn't reflect what we actually do — here's how we'd describe it.' Less helpful feedback sounds like: 'Make it more modern.' If something feels off, try to describe what the feeling is rather than the fix — I'll handle the how."

This isn't condescending if it's framed as a practical guide. Most clients genuinely appreciate knowing what's useful. And it dramatically improves what you receive.

Step 6: Separate Structural Feedback from Fine-Tuning

One of the most common presentation mistakes is inviting all types of feedback at the same time. When a client is looking at a first draft and you ask "what do you think?", they'll comment on the color of a button and the font weight in the same breath as "actually, I think we need a completely different page structure here."

These are different categories of feedback with completely different implications for your timeline. Keep them separate:

Round 1: Structure, layout, content — does this solve the right problem? Is the information architecture right?
Round 2: Visual refinement — does the styling feel right? Is anything inconsistent or off-brand?
Round 3 (pre-launch): Copy accuracy, QA, anything broken — nothing structural.

Communicate these stages explicitly at each presentation. "We're in round 2 — structural decisions are locked in. What we're looking for now is anything in the styling that needs adjustment."

Step 7: Close the Presentation with a Clear Next Step

Every presentation should end with an explicit action item — either from the client or from you. Never leave a presentation open-ended.

If you're sharing async: "Please leave your feedback on the link by [date]. I'll confirm when I've received it and share a timeline for implementing the changes."

After a live call: "I'll send a summary of everything we discussed and a link for any additional written feedback. Can you review and confirm by [date]?"

After the final round: "Once you confirm everything is ready, I'll move to the launch checklist. Is there anything else before we proceed?"

The explicit next step creates a clear handoff and prevents the project from lingering in an undefined review state.

Real Example: The Difference a Structured Presentation Makes

Kira is a freelance web designer who used to send staging links via email with a one-liner: "Here's the first version — let me know what you think."

Her average revision rounds: 3.5. Her average time from first draft to approval: 6 weeks.

She changed one thing: started writing a two-paragraph context message with every link, switched to dotts for feedback collection, and added a round focus to each presentation ("round 1 is about structure, not styling").

Her average revision rounds: 1.8. Time to approval: 3.5 weeks. Same quality of work. Different process.

The clients didn't change. The work didn't change. The presentation did.

Bottom Line

Presenting a website well isn't about performance or polish — it's about giving the client the context and tools to give you useful feedback. A brief framing message, a visual feedback link, a clear round focus, and an explicit next step. That's the entire system. It takes 10 minutes to set up and saves hours per project.

FAQ

How do I present a website to a client for the first time?

Start with a brief context message explaining what they're looking at, what to focus on, and when you need feedback by. Share a visual feedback link (like dotts) so they can click directly on elements rather than describing them in email. For major milestones, consider a short Loom walkthrough before asking for written feedback.

Should I present a website live or async?

Both work, depending on the stage. Live calls are valuable for first full design reviews — the conversation surfaces things that don't make it into written feedback. Async works well for later rounds when most decisions are locked in. A good default: live call for the first presentation, async with a visual feedback link for subsequent rounds.

How do I stop clients from giving vague feedback on my website presentation?

Tell them what good feedback looks like before they give it. A brief note in your presentation message — "helpful feedback describes what feels wrong, not the specific fix" — shifts the quality of what comes back. Pairing this with a visual feedback tool (so they click on what they mean) handles the other half of the vagueness problem.

What is the best tool for sharing a website with a client for feedback?

dotts is the most streamlined option for freelancers. Clients open the link and click directly on elements to comment — no account required. Device and browser data is captured automatically. It works on live websites, PDFs, and images.

How many rounds of feedback should a website presentation include?

Two rounds is standard for most projects. Round 1 covers structure and content; round 2 covers visual refinement. A final pre-launch QA round is separate. Define the number in your contract and communicate it at each presentation so clients know the scope.

How do I handle a client who sends feedback outside the presentation structure?

Acknowledge it, document it, and redirect to the proper channel: "Thanks — could you add that to the feedback link so I have it in writing and don't lose it?" For feedback that arrives outside the included revision rounds, note it clearly: "This is outside our current round — I'll add it to the change log."

How do I get a client to approve a website and actually close the project?

Ask explicitly after each round: "Please confirm we're ready to move forward, or let me know if there's anything else to address." After the final round: "Everything is ready for launch pending your confirmation. Please reply to proceed." Explicit approval language closes projects; implicit approval assumptions keep them open indefinitely.

Make your next client presentation smoother. [Try dotts free →](https://dotts.se)

Start Collecting Feedback in Seconds with dotts

Forget messy email threads and unclear revision requests. dotts makes feedback fast, clear, and organized so you can focus on what matters—getting work done.

Try it for Free