From draft to publication: a small-site checklist

A laid-out page is not necessarily ready to publish. Links may still lead to placeholders, a form may show an animation without saving anything, and a phone screen may hide part of an explanation. A pre-publication review does not need ceremony. It needs to follow the route a visitor will actually take: reading, making, saving, and returning.

First, check whether the content holds up

Read the title and opening paragraph. Do they explain what the page provides? Look for unreplaced sample names, invented usage counts, or unsupported promises. Follow any instructions exactly as written. If an article presents a design judgment, identify its example and limits. Distinguish what is available, what is planned, and what is unsupported.

Then review the sources. Do citations reach the original material? Is the origin of each image known? Can recommended resources still be opened? Publication and revision dates should describe actual events. Do not make old material appear newly published merely to create activity.

Next, finish a real task

Suppose you want a monogram. Enter text, adjust colors, preview it, export it, and open the downloaded file. A success message only confirms that an action was triggered; the output still needs checking. If account saving is available, reopen, modify, duplicate, and delete the work. Try empty names, a failed connection, and a project updated in another window as well as the ideal route.

Review correspondence similarly. Send a clearly identified test letter and confirm that a receipt appears. Try correct and incorrect credentials, and ensure private text does not appear on public pages. Remove test records according to the agreed process instead of letting them become apparent operational activity.

Then change how you browse

Narrow the window to a phone-sized view and look for horizontal overflow. Navigate with a keyboard and check whether focus and controls are usable. Enlarge the text and reread a long passage, making sure essential explanations remain available. The W3C page structure tutorial and Resize Text guidance provide references for these checks.

Finally, review failure messages. A visitor needs to know what happened, whether their work remains, and what to do next. “Something went wrong” rarely answers all three. “Saving failed; your settings remain in this browser, so try again later” is more useful—but only if the settings really were retained.

For this exercise, write ten checks for one small work, limited to things you can verify. Record the result and date, leaving unfinished items on a task list. Make an entrance card with the share-card tool, including the real address, purpose, and limitations. A first release can be small; its promises should match its behavior.