Website relaunch feedback

For website relaunch: For relaunch projects where many stakeholders review one staging version at the same time.

In short

Everyone comments on the same staging URL, and each note stays on its page and element. Because notes carry status and ownership, you see per page what is still open – the go-live punch list builds itself without a separate spreadsheet.

Typical problems this removes

Old and new design live in different tools
Stakeholders comment on screenshots instead of the real site
Changes are noted in the wrong document
Launch date approaches while feedback is still unclear
Content migration and design feedback run in parallel with no cross-check
Redirects and URL structure only get checked after launch
Nobody knows which remaining items actually block go-live

A relaunch is coordination, not just design

During a relaunch, marketing, management, external consultants and developers work simultaneously on the same staging version. nootiz collects their feedback where it belongs: on the new site itself, instead of scattered across email, Slack and meeting notes.

How do you run a pre-launch review with a client?

Before the client sees the new site, the internal team reviews staging first and clears out obvious gaps. Only then does the approval link go to the client, so their feedback addresses substance rather than placeholder copy or missing images.

Every note is a TODO with context

URL, screen size and browser are captured automatically. The development team knows immediately which version is meant – no follow-up questions about which subpage or device was affected.

How do you keep content migration and design review apart?

Use the same note list for content issues (missing copy, wrong images) and design issues (spacing, colors), but describe the type in the note. Project management then sees at a glance whether an item belongs to editorial or development, without maintaining two separate tools.

How do you check redirects and URL structure before launch?

Open the new site under the planned final URLs on staging, where the setup allows it, and flag mismatched paths or missing redirects directly on the affected page. That keeps the SEO check part of the same approval round as the visual feedback.

Approval instead of endless loops

Status and ownership make the approval state transparent. The launch date becomes predictable because open items are visible early and the punch list doesn't hide in a separate spreadsheet.

How do you decide what actually blocks the launch?

Flag critical items with high priority directly in the note, instead of letting them get lost among cosmetic details in the same list. Project management decides whether the launch date holds or slips based on open high-priority notes.

How does a relaunch approval end in a binding way?

The launch is only approved once every critical note is set to Done and the client side explicitly confirms it. Cosmetic remaining items can deliberately be pushed to after launch, as long as that's documented.

How the workflow works

1
Create project
Set up the staging version of the new site as a new nootiz project.
2
Add the snippet
Insert the snippet before </head> on the staging site.
3
Run an internal pre-check
The team reviews the page first, fixes obvious gaps and flags unclear items.
4
Share link
Send the approval link to all stakeholders – no account, no invitation.
5
Collect feedback
Collect notes directly on the page, sort them by priority and assign them.
6
Work through critical items
Implement high-priority notes first so the launch date doesn't hinge on minor details.
7
Sign off
Move notes to Done and sign off for launch.

Frequently asked questions

Can I collect feedback before launch?

Yes, nootiz runs on staging environments and password-protected sites. That lets you complete internal approvals before going live.

What happens to the snippet after launch?

Simply remove it from the live site, or keep using nootiz for later optimizations and bug reports.

How do I handle feedback that's still open past the launch date?

Separate critical items from cosmetic ones. Critical notes block the launch, while cosmetic ones can be tracked as a follow-up list for the first week after go-live.

How do I sync feedback across multiple project stakeholders?

Everyone works on the same link and the same note list. There are no parallel versions, because every note is bound to an element on the current staging page.

Can I carry over old design notes from the previous site?

No, a relaunch project starts clean on the new staging URL. Notes on the old site stay in its own project if you documented them there in parallel.

How do I handle different approval deadlines per department?

You can keep separate notes with their own priority per department and check overall status based on open notes per area, without creating separate projects.

What if the page structure still changes after the review?

If an element shifts significantly, its note can lose context. After major structural changes, briefly check whether open notes still sit on the right element.