Start with the journeys that matter most
A pre-launch review is more useful when it follows what a visitor is trying to do, rather than checking pages in isolation. List the project’s main goals: contacting a freelancer, requesting a quote, finding a resource, signing up for an event or viewing a portfolio piece. For each goal, write down the starting page, the steps a visitor takes and the result they should see. These short paths are your key user flows.
Keep the list manageable. A small portfolio might need flows for opening a project from the home page, reaching the contact form and returning to the main navigation. A team site might also need a resource download or an enquiry routed to the right person. Test the most important flows first so that a minor formatting issue does not distract from a broken contact route.
Test forms from input to follow-up
Submitting a form successfully is only one part of the test. Open each form as a visitor would and check whether its purpose, required fields and submit button are clear. Try a normal submission, then try leaving required fields blank or entering an invalid email address. Confirm that error messages identify what needs fixing and that entered information is not needlessly lost.
After a valid submission, check what happens on screen. A confirmation should make it clear that the action is complete and, where appropriate, what the visitor can expect next. Then check the destination: did the submission arrive in the intended inbox, dashboard or project tool, and does it contain the details needed to respond? Use test information rather than a real person’s private details, and remove test entries when they are no longer needed.
If a form sends an automatic reply, inspect that too. Read it for clarity, check its links and make sure it does not promise a response time the team cannot reliably meet. When several people share responsibility for enquiries, agree who will monitor the destination after launch; a working form is of little use if its messages go unnoticed.
Check links in context
Review links while moving through each user flow, then make a separate pass through navigation, footer links, buttons and prominent calls to action. Check that each one opens the intended destination, not merely that it opens a page. A “View project” button leading to the portfolio index may technically work while still interrupting the visitor’s task.
Pay particular attention to links that are easy to overlook: image links, downloadable files, email addresses, social profiles and links within confirmation messages. Check whether external destinations are still appropriate and whether files have clear names. For links within the site, note dead ends that leave visitors without a sensible next step. Automated link checks can help find missing pages, but a person still needs to judge whether the destination makes sense.
Repeat the flows in realistic conditions
Run the main journeys on a narrow screen as well as a larger one. Menus, form fields and buttons can behave differently when space is limited. Use a keyboard to move through important actions and check that focus remains visible and follows a sensible order. Where possible, ask someone unfamiliar with the project to complete a task without guidance; their hesitation may reveal unclear labels or missing instructions.
Test both the expected route and a few common detours. What happens if a visitor starts on a project page instead of the home page, opens a link in a new tab or needs to correct a form entry? You do not need to explore every possible combination. The goal is to confirm that essential tasks remain understandable and completable from the places visitors are likely to begin.
Record issues, fix them and make a final pass
Keep one shared issue list rather than scattering findings across messages. For each issue, record the page or flow, the steps to reproduce it, what happened, what should happen and who will address it. A screenshot can help when the problem depends on screen size or visual state. Mark issues that prevent a key task as higher priority than small presentation changes.
After a fix, repeat the affected steps instead of assuming the change worked. Then do a short final pass through the highest-priority flows on the version that will actually launch. Assign someone to confirm the form destination and someone to approve the visitor-facing wording. This creates a clear handover: the team knows what was tested, what was fixed and whether any minor issues remain for a later update.
