Saliem Talash: A worked website handoff for a fictional flower shop

Worked example

A site can look ready while the person who owns it still cannot make the next ordinary change. The useful test is specific: if the shop changes its Saturday hours on Friday afternoon, can the owner update the public page, check the result, and know where enquiries went?

Below is a complete fictional demonstration of the Website Project Workbook. The shop, people, addresses and outcomes are illustrative. This is not a client case study or a claim that a real site passed these checks.

1. Write the brief as a visitor task

Project: a small neighborhood flower shop website. Audience: someone nearby who wants to see the shop's opening hours, understand what can be ordered, and ask about a custom arrangement. Primary visitor task: find accurate hours and send an enquiry without guessing whether the shop is open.

The brief should also say what the site does not do. In this example, it does not promise same-day delivery, take payment, or confirm custom orders automatically. Those decisions matter because a button labelled “Order now” would make a promise the proposed workflow cannot keep. “Ask about an arrangement” is more accurate until an order and fulfilment process exists.

Acceptance question: Can a first-time visitor find the current hours and the enquiry form from the home page on a phone?

2. Make launch checks observable

A checklist becomes useful when it records where the check happened and what was seen. For this demonstration, the launch review would contain:

• Page: the public home page, plus the contact page reached from its main button.
• Devices: a narrow phone viewport and a laptop browser. Record browser and date when a real review happens.
• Navigation: the hours and contact path are visible without relying on a hidden menu; the back path is clear.
• Keyboard: the main link and form controls can be reached and operated in a sensible order. If this has not been tested, record “not tested,” not a green check.
• Enquiry: submit a test message, read the confirmation, and verify arrival in the agreed inbox. A success message by itself does not prove delivery.
• Decision: publish only after the public page and delivery path have been checked. If the inbox test is pending, record the owner and next action.

These are prompts for a real review, not certification of accessibility, security or compliance. The fictional example does not assert that any test has actually run.

3. Turn a vague problem into an issue record

Imagine the owner reports, “The contact form feels broken.” That sentence is useful as a signal, but it is not yet an actionable issue. The workbook's issue record asks for enough detail to reproduce and resolve it:

• Observed problem: after submitting the contact form in a phone browser, a confirmation appears, but no test message is found in the agreed inbox.
• Reproduction: record the public URL, browser, time, the test address used, and the visible confirmation. Do not put a private customer's enquiry in a public issue record.
• Impact: potential enquiries may not reach the shop. Mark this as a launch blocker until delivery is confirmed.
• Next action: the form owner checks the configured destination and provider logs, sends another test, and records the result.
• Recheck: close the issue only when the public form displays the expected message and the test reaches the inbox.

That sequence avoids a common mistake: treating a pleasant success screen as proof that the complete service worked.

4. Hand over ownership, not a pile of passwords

The handoff should identify the account owner for the domain, site editor, hosting, analytics and form provider. It should say where approved access instructions live and who renews each service. It should not copy credentials into a shared workbook or public document.

For this shop, the first practice task would be changing the Saturday hours in a preview. The owner follows the written steps, checks the phone layout, publishes the change, and opens the public page in a fresh tab to confirm it. If the steps fail, the handoff is unfinished even if the original builder can make the edit.

A compact final handoff entry might read: “To update hours, open the site editor's Hours section, change the Saturday row, preview on phone and desktop, publish, then verify the public contact page and footer. If the update does not appear, check publication status before repeating the edit.” The exact controls depend on the chosen platform; a real handoff must name them accurately.

5. Keep one decision that prevents later confusion

Question: Should the site accept paid orders now? Decision: no; the first version offers an enquiry for custom arrangements. Reason: the example shop has no verified availability and fulfilment workflow to support an immediate purchase promise. Revisit when: the owner has documented inventory, payment, delivery and refund processes and tested the public flow.

This small record lets a future editor understand why the button says “Ask” rather than “Buy.” It does not freeze the design forever; it names the condition for changing it responsibly.

Use the example in your own project

Replace the fictional shop with your own visitor task. Fill one brief, one real launch observation, one issue if you find one, and one routine owner edit. Save progress explicitly before closing the workbook; it does not autosave. The progress file contains the text you enter, so keep it with your project records and share it only with intended collaborators.

Open the Website Project Workbook · Read why it works offline

By Saliem Talash. Prepared with AI assistance. The flower-shop scenario is fictional and does not describe client work, a real launch test or a customer outcome.