← DTRT Lab watch page

THE BUILD SESSION · OCTOBER 11, 2026

From a clip to
a credible project.

Make a clear edit, a useful project page, and a release you can verify. This companion collects the steps and original diagrams from DTRT Lab’s prepared visual workshop.

Diagrams are illustrative. The café project is fictional; sample measurements are hypothetical. Source-pattern labels describe the public DTRT site. These are worked examples, not client case studies or promises of results.

Download the blank release worksheet (.txt)

From gameplay to a clear portfolio

Start with one viewer question

A portfolio clip needs a clear editorial purpose before it needs decoration.

  1. Choose a question Write the question a stranger should answer after watching, before you touch the editing timeline.
  2. Locate the evidence Find the frames that answer your question and mark the moment where the situation changes.
  3. Make one decision visible Choose the cut, crop, or label that helps someone follow that specific change on screen.
  4. Define a useful result A finished example should show the decision clearly enough for someone to explain your reasoning.
See the worked diagramORIGINAL WORKSHOP DIAGRAMStart with one viewer question01Question02Evidence03Decision04Result4 / 4 decisions visibleSTEP 4 / 4

Inspect the material first

Inspect duration, framing, repetition, and sound before designing the chapter.

  1. Measure the originals The three supplied edits measure fifteen point seven, fifteen point four five, and fifteen point nine five seconds.
  2. Check the frame All three source files use a portrait canvas with an overview and a larger detail view.
  3. Remove repeated action Their opening previews repeat later action; those previews and the first edit’s slowed replay are removed here.
  4. Separate sound from permission These workshop excerpts contain no audio stream; soundtrack permission is not inferred from possession of a file.
See the worked diagramORIGINAL WORKSHOP DIAGRAMInspect the material first115.700s source215.450s source315.950s source4Audio removedSTEP 4 / 4

Build a beat map

Use precise beats as an editing plan, then adjust them to the actual action.

  1. Sketch twelve seconds This twelve second timeline is an original planning illustration, not a measurement of the next clip.
  2. Give the setup a job Reserve three seconds to establish where attention belongs, then remove information that does not support it.
  3. Let the action develop Place the meaningful change between three and eight point five seconds, with its spatial context intact.
  4. Keep the result readable Use the remaining three point five seconds to make the consequence legible before the viewer leaves.
See the worked diagramORIGINAL WORKSHOP DIAGRAMBuild a beat mapILLUSTRATED PLAN · 12.0 SECONDSSetup3s0sAction5.5s3sResult3.5s8.5s12sSETUP → CHANGE → CONSEQUENCESTEP 4 / 4

Preserve spatial orientation

A crop should preserve the relationship that makes the action understandable.

  1. Identify the relationship In this original diagram, the player, opening, and target establish a relationship that the edit must preserve.
  2. Mark the destination Keep the opening visible long enough for someone to understand where the player expects action.
  3. Test the tighter view A tighter view can enlarge the target while accidentally removing the route that explains the moment.
  4. Check both ends Before accepting the crop, verify that attention can travel from the player’s position to the relevant opening.
See the worked diagramORIGINAL WORKSHOP DIAGRAMPreserve spatial orientationSYNTHETIC SCENEPlayerOpeningTargetKeep the relationship readableShared frameSTEP 4 / 4

Choose a frame deliberately

Format is an editorial choice; inspect the information lost at its edges.

  1. Start with the source This diagram compares a wide source with a portrait delivery frame; both are deliberately synthetic examples.
  2. Place the portrait window Move the portrait window around the important action before committing to a fixed center crop.
  3. Compare what disappears Check the left and right edges for information that the smaller delivery frame would remove.
  4. Choose the layout that explains If one crop cannot preserve the relationship, use a composed layout that gives context its own space.
See the worked diagramORIGINAL WORKSHOP DIAGRAMChoose a frame deliberatelyILLUSTRATED 16:9 SOURCEContextActionCOMPOSED 9:16STEP 4 / 4

Give two views different jobs

A second view earns its space by answering a different visual question.

  1. Assign the overview The supplied edits use an overview above a detail view; this schematic isolates those two jobs.
  2. Assign the detail The larger detail area should make one action easier to read while the overview preserves location.
  3. Explain the relationship A short timing label can explain how the views relate when the edit moves through the round.
  4. Check the smallest display Review the composition at its actual viewing size so both views contribute useful information to the screen.
See the worked diagramORIGINAL WORKSHOP DIAGRAMGive two views different jobsCONTEXTDETAILLATER IN THE ROUND0102STEP 4 / 4

Create a reading order

Title, action, timing, and destination should form a readable order.

  1. Name the moment Use a short title that describes the visible situation without promising an outcome the footage cannot support.
  2. Protect the action Keep the gameplay visually dominant so the title introduces the moment without competing with every moving detail.
  3. Add timing only where useful Place a small timing label near its relevant view when a transition needs extra orientation.
  4. Finish with one destination A single site link at the end gives interested viewers a clear next step after the action.
See the worked diagramORIGINAL WORKSHOP DIAGRAMCreate a reading orderONE CLEAR MOMENTACTIONEARLIER IN THE ROUNDDTRTLAB.COMSTEP 4 / 4

Make labels survive the background

Evaluate the finished label over difficult imagery and at a realistic viewing size.

  1. Start with a difficult background The synthetic pattern makes thin text harder to read, much like movement and texture behind a caption.
  2. Separate text from texture Place a solid dark backing behind the label so its letters remain distinct through changing imagery.
  3. Shorten the label Reduce the words until the label communicates one idea without covering the action it should explain.
  4. Review the actual output Read the rendered label at the size viewers will see; an enlarged editing preview can hide weaknesses.
See the worked diagramORIGINAL WORKSHOP DIAGRAMMake labels survive the backgroundHOLD THE DOORCHECK AT VIEWING SIZESTEP 4 / 4

Leave room around key information

Margins are a starting point; the destination preview is the practical check.

  1. Treat edges as fragile This illustrated frame uses a working margin because important text becomes vulnerable when displays crop or overlay content.
  2. Move essential words inward Keep the main headline and destination comfortably inside the frame while allowing decorative elements nearer the edges.
  3. Protect the subject too Check the subject’s important movement alongside the text; a safe headline cannot rescue a hidden payoff.
  4. Verify each destination Platform interfaces vary, so inspect the actual destination preview before assuming this example margin will be sufficient.
See the worked diagramORIGINAL WORKSHOP DIAGRAMLeave room around key informationILLUSTRATED DELIVERY FRAMEWORKING MARGINESSENTIAL WORDSPreview interface overlaysSTEP 4 / 4

Cut repeated information

Shortening works when it removes repeated information while preserving cause and consequence.

  1. Map the information This original thirty second diagram separates locating the scene, waiting, meaningful change, and the visible consequence.
  2. Identify the empty hold Ask what the waiting section teaches that the setup has not already made clear to the viewer.
  3. Close the unnecessary gap Remove the redundant wait while preserving the setup, meaningful change, and consequence in their correct order.
  4. Check the join Watch across the new join for a jump that could confuse position, timing, or the action’s cause.
See the worked diagramORIGINAL WORKSHOP DIAGRAMCut repeated informationILLUSTRATED PLAN · 18.0 SECONDSLocate6s0sChange7s6sResult5s13s18sReview context across both joinsSTEP 4 / 4

Use labels honestly

Editorial labels should clarify evidence without inventing dialogue, intent, or events.

  1. Describe what is visible A silent edit can use an action label to explain what the viewer can actually see.
  2. Separate labels from speech Keep editorial labels visually distinct from dialogue captions, especially when the program contains no audible speech.
  3. Attach words to the moment Show the label when its information becomes useful, then remove it when the relevant action changes.
  4. Remove unsupported wording Replace an uncertain explanation with a visible description whenever the footage cannot establish intention or causation.
See the worked diagramORIGINAL WORKSHOP DIAGRAMUse labels honestly01Observedaction02Short label03Correcttiming04Clearremoval4 / 4 decisions visibleSTEP 4 / 4

Keep the cover’s promise

A cover is a promise the finished edit must actually deliver.

  1. Choose an honest situation The synthetic cover describes a held doorway, giving the viewer a specific situation to look for.
  2. Keep the title specific A short concrete title creates a clearer expectation than a claim that the footage cannot demonstrate.
  3. Pair words with evidence Choose a frame where the doorway and relevant action remain visible enough to support that title.
  4. Check the payoff Watch the finished edit from its cover promise through its ending and confirm that the promised moment appears.
See the worked diagramORIGINAL WORKSHOP DIAGRAMKeep the cover’s promiseThe door was alreadycoveredPROMISE → EVIDENCESTEP 4 / 4

Build an export checklist

Canvas, timing, audio, and playback are separate checks.

  1. Match the delivery canvas Tonight’s stage uses a landscape canvas, with portrait examples placed inside it rather than stretched across the width.
  2. Choose a deliberate frame rate The supplied examples are sixty frames per second; the broadcast stage is configured for thirty frames per second.
  3. Verify silence in the file These derived examples contain video only, and the stage also mutes playback as a separate protective control.
  4. Open the delivered file Verify the actual encoded output instead of assuming that a successful export dialog proves correct playback and framing.
See the worked diagramORIGINAL WORKSHOP DIAGRAMBuild an export checklist1920 × 1080 STAGE60fps SOURCE → 30fps STAGEVIDEO ONLY · SILENTOPEN THE ENCODED FILESTEP 4 / 4

Review from beginning to end

Technical decode, sampled frames, and continuous playback answer different review questions.

  1. Inspect the first frame Look for black lead-in, cropped titles, or a start that arrives too late to explain the scene.
  2. Inspect every transition Review joins for frozen frames, accidental repeats, missing context, and labels that outlive the action they describe.
  3. Inspect the final frame Confirm the ending includes a readable result and destination without leaving an accidental blank section after completion.
  4. Check sound separately Inspect audio presence and listen when appropriate; a picture review cannot establish that the soundtrack is suitable.
See the worked diagramORIGINAL WORKSHOP DIAGRAMReview from beginning to end1First frame2Every transition3Final frame4Audio stateSTEP 4 / 4

Make the edit recoverable

A recoverable edit links source, decisions, delivered file, and verified public destination.

  1. Keep the source intact Preserve the original source separately so a new cut can be compared with the material that produced it.
  2. Record the decisions Save the source ranges, crop choice, label changes, and reason for the revision in a short edit note.
  3. Name the version clearly Use a simple versioned export name so the reviewed file cannot be confused with an earlier draft.
  4. Connect the public result Add the eventual public URL to the record after checking that it opens the intended published version.
See the worked diagramORIGINAL WORKSHOP DIAGRAMMake the edit recoverable01Source02Edit notes03Export04Public link4 / 4 decisions visibleSTEP 4 / 4

Turn the clip into a case

A strong case makes your judgment inspectable without inventing a business result.

  1. State the brief Describe what the edit needed to explain and where viewers would encounter the finished result.
  2. Show your judgment Name one meaningful choice, such as preserving an overview while enlarging a detail, and explain its purpose.
  3. Show the actual artifact Link the finished work and include a representative frame that makes the decision visible to a prospective collaborator.
  4. Bound the evidence Separate the completed editing work from outcomes you have not measured, keeping every claim proportionate to its evidence.
See the worked diagramORIGINAL WORKSHOP DIAGRAMTurn the clip into a caseBRIEFExplain a held angleDECISIONPreserve context; enlarge detailARTIFACTReviewed video + representative frameEVIDENCEDescribe checks; bound claimsSTEP 4 / 4

Revise one decision at a time

A focused revision makes the effect of an editing decision easier to inspect.

  1. Keep a comparable baseline Save the reviewed version before revising it so the original choice remains available for a direct comparison.
  2. Change one meaningful choice For this synthetic example, keep timing and footage fixed while changing only the label’s placement.
  3. Compare the same moment Inspect matching moments at the same viewing size to see whether the new position protects the important action.
  4. Write the result precisely Record whether the label remains readable and the action stays visible; broader performance remains a separate question.
See the worked diagramORIGINAL WORKSHOP DIAGRAMRevise one decision at a timeVERSION AVERSION BLABELCHANGE: LABEL POSITION ONLYLABELSTEP 4 / 4

A reusable editing worksheet

Question → source → beats → frame → labels → export → review → record.

  1. Write the question Begin your next edit by writing its viewer question and identifying the source frames that can answer it.
  2. Sketch the structure Map setup, action, and result, then choose a frame that preserves the relationship between them.
  3. Prepare the delivery Add only useful labels, choose the export format deliberately, and inspect the actual file at viewing size.
  4. Close the record Save what changed, what you checked, and where the verified result lives so the next revision starts clearly.
See the worked diagramORIGINAL WORKSHOP DIAGRAMA reusable editing worksheet1Question + source2Beats + framing3Labels + export4Review + recordSTEP 4 / 4

A website visitors can trust

Give each visitor a route

Design around a visitor decision before choosing decoration.

  1. Start with the visit A first visit brings three questions. Give each question a visible place to land.
  2. Attach useful destinations Connect those questions to an introduction, a real example, and a clear next action.
  3. Use the actual site map DTRT Lab separates work, dated results, and contact so visitors can choose their own route.
See the worked diagramDTRT source pattern01Work/clips/02Dated results/live/03Contact/contact.html

Write a promise you can show

Name the work and offer a way to inspect it.

  1. Find the missing object A phrase like “ideas without limits” leaves visitors guessing what you actually make.
  2. Name the visible work Replace abstract praise with a specific activity and a destination where people can inspect it.
  3. Keep the claim bounded The homepage describes edited videos and public records. Those are concrete things a visitor can open.
See the worked diagramDTRT source patternPAGE STRUCTUREEdited videosPublished releaseDated record

Give the first screen a hierarchy

Size and placement should reveal the first useful action.

  1. Spot competing emphasis Four equally loud blocks compete for attention. Decide which one serves the visitor first.
  2. Choose a starting point Make the work the focal point, then place supporting context beneath the main action.
  3. Check the reading order Read top to bottom: identity, purpose, example, next step. Remove anything that interrupts that sequence.
See the worked diagramWorked examplePAGE STRUCTUREProject identityWhat we makeOpen an exampleChoose next step

Turn a claim into a work card

A usable example is stronger evidence than a self-awarded label.

  1. Replace the empty adjective “Great editing” is a judgment. A visible project lets the viewer form that judgment independently.
  2. Build a complete card Give the example a descriptive title, an honest format label, and a destination that opens.
  3. Keep the source reachable DTRT’s archive includes native platform links alongside local previews, making the distinction visible.
See the worked diagramDTRT source pattern01Archive previewOn the site02Platform linkChosen by viewer03Native postPublication evidence

Label project maturity

Use different actions for work that is available and work in development.

  1. Separate available from planned A story page and a playable game are different deliverables. Give them different status labels.
  2. Match the available action Offer reading for the published story. Describe development without presenting a demo download.
  3. Caption illustrative images The project labels its story still as illustration, so visitors do not confuse it with captured gameplay.
See the worked diagramDTRT source patternBEFOREImage aloneUnclear evidenceAFTERStory stillNot captured gameplay

Distinguish preview from publication

A file on your website does not prove a social post is public.

  1. Name the local state A reviewed file can play on your website before any social platform has published it.
  2. Do not merge the states Keep the preview label until a native post exists and its public page has been checked.
  3. Show the distinction nearby DTRT’s archive explains this beside the player and provides specific links to already public posts.
See the worked diagramDTRT source patternPAGE STRUCTUREReviewed clipsPreview explanationAlready public: platform linksVideo player

Use navigation people understand

Navigation labels should describe destinations without requiring inside knowledge.

  1. Trade novelty for recognition Invented menu names require translation. Use ordinary words that describe the page someone will reach.
  2. Keep destination names steady Use the same label for the same destination across the header, footer, and related links.
  3. Mark the current page DTRT’s contact navigation marks Contact as current. Orientation should remain visible after someone follows a link.
See the worked diagramDTRT source patternPAGE STRUCTUREWork · ResultsAbout · ContactContact pageCurrent page: Contact

Make the small screen intentional

Stack information in a useful order instead of shrinking a desktop composition.

  1. Find the narrow-screen collision A cramped two-column layout forces short lines and awkward scanning on a small display.
  2. Stack the existing content The site’s responsive rules collapse several content grids into one column on narrower viewports.
  3. Preserve the useful sequence Keep the example above its supporting context, with the next action reachable after the explanation.
See the worked diagramWorked exampleNARROW VIEWPORTWatch the exampleRead the contextChoose next step

Use space to explain relationships

Spacing is part of the explanation, not spare room to fill.

  1. Group related pieces Keep a title, its explanation, and its action together so they read as one unit.
  2. Separate different decisions Increase the gap between unrelated sections while keeping the parts of each card closer together.
  3. Remove the duplicate sentence If two paragraphs explain the same action, keep the clearer one and let the work breathe.
See the worked diagramWorked exampleBEFOREWatch the projectSee our projectExplore this projectAFTERWatch the projectOpen example

Show keyboard users their location

A focus indicator must make the next keyboard action visible.

  1. Trace the focus route Imagine moving through the page with Tab. Each stop needs a visible location and a useful action.
  2. Reveal the focused control The theme adds an orange outline for several interactive controls. This illustrates one focused button.
  3. Check every control type Inspect links, buttons, inputs, selects, and text areas individually. A shared rule is not a complete review.
See the worked diagramWorked example✓Links and buttons✓Inputs and selects03Text areas

Offer a route past navigation

A skip link connects repeated navigation to the main content.

  1. Expose the shortcut DTRT’s skip link appears on focus, giving keyboard visitors a direct route to the content.
  2. Match the link and target The link points to main. The page supplies that exact identifier on its main element.
  3. Verify the destination Activate the shortcut during review and check where focus and reading continue on the actual page.
See the worked diagramWorked example01Focus shortcut02Activate link03Main content

Make headings describe the structure

Use a heading outline that still explains the page without its styling.

  1. Separate appearance from structure Large type draws the eye, but heading elements also describe how the document is organized.
  2. Build the content outline The homepage has a main heading and named sections for work, results, and the operating process.
  3. Read the outline alone Cover the paragraphs and scan only headings. Each section should still have a clear purpose.
See the worked diagramWorked exampleProject overviewAvailable workEvidence andlimitsContact

Choose links and buttons deliberately

A destination and an in-page action deserve controls that describe their jobs.

  1. Identify a destination Use a link when the visitor is going somewhere, such as a native post or contact page.
  2. Identify an action Use a button for an action inside the page, such as selecting a different clip.
  3. Describe the result Replace “click here” with the destination or action. The label should make sense outside its paragraph.
See the worked diagramWorked exampleBEFOREClick hereMoreAFTEROpen the clip archivePrepare email

Keep form labels visible

A field should keep its meaning after the visitor starts typing.

  1. Show the disappearing clue A placeholder-only field loses its instruction once somebody types. Keep a separate label visible.
  2. Connect the label and field DTRT wraps its email input in a label and specifies the email field type.
  3. Explain required information Make the request clear before submission, then inspect what happens when a required field is empty.
See the worked diagramWorked example✓Visible field labels✓Required fields identified03Empty-field check

Describe the real submission process

A prepared email and a sent message are different states.

  1. Follow the handoff The contact form prepares a message, opens the visitor’s email app, and leaves sending to them.
  2. Name the button accurately “Prepare email” describes the action. “Message sent” would claim an outcome the website has not verified.
  3. Explain the remaining step Keep a short instruction beside the action: review the draft and send it in your email app.
See the worked diagramDTRT source pattern01Prepared02Reviewed03Sent by visitor

Design the failure route too

A failed handoff needs an alternate route and truthful status.

  1. Consider the missing email app Some visitors will not have a working email-app handoff. Give them another visible contact route.
  2. Make the fallback available DTRT provides a direct email link and a no-JavaScript explanation alongside the form path.
  3. Keep status honest The partnership script says the email app was requested and that the website has not sent the inquiry.
See the worked diagramDTRT source patternBEFORESubmission successfulAssumed deliveryAFTEREmail app requestedWebsite has not sent

Map what leaves the page

Draw the data flow before writing a privacy claim.

  1. Draw each destination Map the browser, email provider, and analytics service separately. Each path serves a different purpose.
  2. Separate text from intent DTRT’s partnership analytics call names an intent event; it does not include the written brief.
  3. Describe external services plainly The privacy page names external players and fonts as separate services with their own data handling.
See the worked diagramDTRT source pattern01Site behaviorExplain what happens02External servicesIdentify the provider

Make analytics choices match behavior

Describe the actual controls without promising that every external request disappears.

  1. Start from the saved choice DTRT’s analytics code checks browser privacy signals and its saved analytics choice before relevant loading decisions.
  2. Show the explicit branch Its Google Analytics path requires configuration and permission. This diagram simplifies that source-code decision.
  3. Keep the boundary visible The privacy copy also explains that external players and font services are outside those analytics choices.
See the worked diagramDTRT source patternBEFOREAnalytics choiceOne part of behaviorAFTERExternal media and fontsSeparate servicerequests

Measure the action you actually observed

An intent event records a step in a journey, not the whole outcome.

  1. Give the event a precise name PartnershipBriefPrepared describes preparing a brief. The name does not claim an email was delivered.
  2. Keep outcomes separate A button click, prepared draft, and received message answer different questions. Do not combine them.
  3. Review the evidence boundary Before writing a result, ask which step the record can actually prove and label it accordingly.
See the worked diagramWorked example✓Name observed action✓Identify missing evidence03State only that result

Make a saved record look saved

A visible refresh does not make an old observation current.

  1. Separate refresh from collection A page can reload a saved file without collecting new platform data. Display the observation time.
  2. Keep missing data unknown When evidence is absent, show an unavailable state. A zero would be a different factual claim.
  3. Attach the limitations nearby The homepage distinguishes saved observations, historical totals, and unique people. Context belongs beside the figure.
See the worked diagramDTRT source pattern01ObservationSource and time02ScopeWhat the countincludes03LimitWhat it cannotprove

Keep the shared preview consistent

The title, description, and visible page should describe the same work.

  1. Inspect the entry point A shared link may appear as a title and description before anyone sees the full page.
  2. Match the page promise The homepage metadata names creator work and its story project, matching the visible introduction and destinations.
  3. Review after changing the offer When the page changes, review its title, description, preview image, and canonical destination together.
See the worked diagramWorked example✓Title and description✓Preview image03Canonical destination

Walk the complete visitor journey

Finish by trying the journey you are asking someone else to take.

  1. Test a cold arrival Start at the homepage with one task: find a real example without using your knowledge of the site.
  2. Try the next action Continue to contact, test the handoff, and inspect the fallback. Review the journey on a narrow screen too.
  3. Leave a clear public record Show what exists, explain its limits, and give people a useful next step they can actually complete.
See the worked diagramWorked examplePAGE STRUCTUREReal workClear limitsUseful next step

Worked example • fictional project

Turn a vague request into one useful release

Start with one audience, one action, and a defined deliverable.

  1. “Make our lunch visible.” Give the fictional café one concrete communication task before opening a design tool.
  2. Answer the lunch decision. A person scrolling on a phone needs the menu, hours, and next step.
  3. Choose one next step. Use the menu-details page as the single destination for this practice release.
  4. Make the request testable. Prepare one portrait image, its caption, accessible text, and a release checklist.
See the worked diagramTHE WORK PACKAGE — fictional worked exampleWORKED EXAMPLE · FICTIONAL PROJECTTHE WORK PACKAGEViewer receivesPortrait announcementMenu + hours + next stepCaptionSame approved factsOperator receivesAlternative textMeaningful image descriptionRelease checklistEvidence before completionFictional practice project • no real customer

Collect the smallest useful input set

Ask for public facts and permission; avoid collecting private customer data.

  1. Request approved public facts. Collect the menu names and service hours in writing so the draft has a reference.
  2. Keep customer records out. This announcement needs no customer list, order history, private messages, or payment records.
  3. Mark uncertainty explicitly. An unanswered detail stays pending; neither the draft nor an assistant should invent it.
  4. Use a text-led layout. A missing photo permission does not prevent a factual announcement built from original typography.
See the worked diagramPHOTO DECISION — fictional worked exampleWORKED EXAMPLE · FICTIONAL PROJECTPHOTO DECISIONPermission documented?Not yetKeep photo outside releaseSafe working choiceText-led artworkUse the approved factsFictional practice project • no real customer

Create a compact source of truth

Keep the approved facts together and carry them unchanged into every format.

  1. Write the menu literally. Use the two item names provided in this fictional brief, without extra product claims.
  2. Include days and hours. A time without a day can mislead; record the complete lunch service window.
  3. Keep the offer bounded. This sample announcement describes in-person lunch availability; delivery and reservations are outside its scope.
  4. Freeze one reference version. Name this fact sheet brief-v01, then require a new version when a factual detail changes.
See the worked diagramREFERENCE FILE — fictional worked exampleWORKED EXAMPLE · FICTIONAL PROJECTREFERENCE FILEsample-lunch/brief-v01.txtMenu • days • hours • routeChange ruleNew fact → new versionFictional practice project • no real customer

Translate audience questions into layout

A clear announcement answers the viewer’s questions in a useful order.

  1. Lead with the occasion. Place “Weekday lunch” first so a viewer understands the purpose before reading the items.
  2. Show the two choices. Keep the item names together and avoid decorative copy that competes with the actual menu.
  3. Place the service window. Put days and hours immediately below the menu where viewers expect the practical details.
  4. Finish with one action. Give the destination its own line, separated from the food and service information.
See the worked diagramARTWORK / ACTION — fictional worked exampleWORKED EXAMPLE · FICTIONAL PROJECTARTWORK / ACTIONSAMPLE ARTWORK / FICTIONALTuesday–Friday11 AM–2 PMVIEW MENU DETAILSexample.com/menuReading order4 · Next stepOne action onlySample linkIllustrative, not a café siteFictional practice project • no real customer

Set scope before production

Define the files, revisions, and exclusions before the project expands.

  1. Name the exact output. One portrait announcement and one matching caption are enough to test this release workflow.
  2. Bound the revision round. Ask the owner to review facts and readability together, then collect one consolidated correction list.
  3. Write down exclusions. This example does not include a website rebuild, account setup, ad buying, or promised sales.
  4. Turn changes into decisions. If a new request arrives, decide whether it replaces a deliverable or needs another release.
See the worked diagramNEW REQUEST: “ADD A FLYER” — fictional worked exampleWORKED EXAMPLE · FICTIONAL PROJECTNEW REQUEST: “ADD A FLYER”Option AReplace one outputKeep scope comparableOption BCreate a new briefAgree the additional workA new request does not silently change the agreed package

Define acceptance before calling work finished

Use observable acceptance checks; a generated file alone is not completion.

  1. Check the facts first. Every menu name, day, and hour must match the reference sheet before appearance can pass.
  2. Check the intended size. Inspect the image at a small phone-width preview and read the practical information without zooming.
  3. Check the handoff files. Confirm the image opens, the caption matches, and alternative text is included with the release.
  4. Separate ready from published. A reviewed package can be ready while publication remains pending; track those as different states.
See the worked diagramTWO DIFFERENT MILESTONES — fictional worked exampleWORKED EXAMPLE · FICTIONAL PROJECTTWO DIFFERENT MILESTONESDraftEditableNot yet approvedReadyReviewed packageCan be scheduledPublishedNative evidenceRequires a separatecheckFictional practice project • no real customer

Record the provenance of each ingredient

Know which facts and assets you can use; hold uncertain material.

  1. List the ingredients. Record where the facts, words, and artwork came from before combining them into the announcement.
  2. Make permission specific. A supplied photo needs permission for this intended use; receiving a file does not establish that.
  3. Choose a clean fallback. Remove the unconfirmed photograph and keep a useful announcement using the approved text.
  4. Keep the reference with it. Add a short source note to the package so the next operator understands the decision.
See the worked diagramPACKAGE / SOURCE NOTE — fictional worked exampleWORKED EXAMPLE · FICTIONAL PROJECTPACKAGE / SOURCE NOTEsource-note.txtFactsbrief-v01.txtImage treatmentOriginal typography; no photoOutstanding assetsUnconfirmed photo excludedFictional practice project • no real customer

Build copy that survives a quick glance

Use concrete facts and one action; remove unsupported claims.

  1. Start with a rough draft. The first version can expose problems: vague praise crowds out the menu and service details.
  2. Replace praise with specifics. Write the menu names directly so viewers can decide whether the offer fits their needs.
  3. Remove hidden assumptions. Do not add “fresh daily,” dietary claims, or availability promises unless the business can substantiate them.
  4. Close with the exact action. Use “View menu details” with the sample destination so the instruction matches what comes next.
See the worked diagramCOPY / FINAL ACTION — fictional worked exampleWORKED EXAMPLE · FICTIONAL PROJECTCOPY / FINAL ACTIONSAMPLE ARTWORK / FICTIONALVIEW MENU DETAILSexample.com/menuDestination must provideMatching menuSame items and hoursContact routeA clear way to askExample destination only • not a live customer campaign

Prepare a bilingual version with a review gate

Translate the meaning and facts, then request a competent human review.

  1. Keep the meaning aligned. Pair the English heading with a Spanish draft while preserving the same practical purpose.
  2. Translate the actual items. Use a plain Spanish draft for both items; the business confirms its preferred menu terminology.
  3. Keep time information consistent. Check Tuesday through Friday and eleven to two in both versions; translation must not alter availability.
  4. Review before release. A competent reviewer checks meaning, accents, menu terms, and reading order before this version becomes publishable.
See the worked diagramLANGUAGE RELEASE GATE — fictional worked exampleWORKED EXAMPLE · FICTIONAL PROJECTLANGUAGE RELEASE GATEHuman review requiredMeaning + factual matchPending in this worked exampleNatural local wordingPending in this worked exampleMachine-generated or draft translation is not automatic approval

Give the artwork a readable structure

Arrange content into stable blocks and inspect the result at the intended size.

  1. Use four clear blocks. Allocate separate areas for the heading, menu, service window, and action instead of scattering them.
  2. Make the menu dominant. Give the actual item names more visual weight than the decorative label or sample branding.
  3. Keep essential text together. Leave enough inner margin that the action and hours remain visible after a normal feed crop.
  4. Preview the actual export. Review the saved image, not only the design canvas, because export mistakes can change the result.
See the worked diagramCANVAS → EXPORT → INSPECT — fictional worked exampleWORKED EXAMPLE · FICTIONAL PROJECTCANVAS → EXPORT → INSPECTCanvasEditable draftLayout is preparedExportlunch-v01.pngOpen the saved fileInspectText + cropCompare withacceptance checksFictional practice project • no real customer

Repair a specific readability defect

A useful quality pass produces a concrete correction and a fresh check.

  1. Find one visible problem. In this example, the service hours become too small at phone width even though the heading reads.
  2. Move the hours upward. Group the service window beneath the menu and remove decoration to give those facts enough space.
  3. Recheck the saved version. Export version two, reopen it at the same preview width, and read the previously weak line.
  4. Record the exact correction. Write what changed and which check passed so the reviewer can inspect the improvement quickly.
See the worked diagramREVIEW LOG / EXAMPLE — fictional worked exampleWORKED EXAMPLE · FICTIONAL PROJECTREVIEW LOG / EXAMPLEVersion 02IssueHours unreadable at phone widthChangeLarger service blockRecheckRead the exported hours lineFictional practice project • no real customer

Include text access to the information

Alternative text and captions should preserve the practical meaning of the image.

  1. Describe the useful information. The alternative text should communicate the menu and service window, rather than merely saying “lunch poster.”
  2. Add the menu and hours. Include the two choices and their service window so the image’s main facts remain available as text.
  3. Make the caption stand alone. Someone should understand the announcement from its caption even if the image fails to load.
  4. Compare the three versions. Check image, caption, and alternative text against the same brief; fix contradictions before publishing.
See the worked diagramFACT CONSISTENCY — fictional worked exampleWORKED EXAMPLE · FICTIONAL PROJECTFACT CONSISTENCYCompareImage ↔ briefSame menu and hoursCaption ↔ briefSame menu and hoursCompareAlternative text ↔ briefSame useful factsTranslation ↔ briefHuman language review stillrequiredFictional practice project • no real customer

Verify the next step a viewer will take

A useful announcement has a destination that works and matches the promise.

  1. Map the full path. Follow the route from announcement to details to contact before asking a viewer to use it.
  2. Look for mismatched facts. If the destination shows different hours, hold publication until the business confirms which version is correct.
  3. Explain what the button does. If a form prepares an email, label it that way; opening a draft is not sending a request.
  4. Test without private details. Use a clearly marked test message, verify the expected behavior, then keep only the test outcome.
See the worked diagramCONTACT CHECK / ACTUAL PROJECT — fictional worked exampleWORKED EXAMPLE · FICTIONAL PROJECTCONTACT CHECK / ACTUAL PROJECTVerify before releaseDestination opensCorrect public pageButton behavior matchesDraft versus actual submissionRecord onlyTest outcomeNo private message contentsAny unresolved issueHold until correctedFictional practice project • no real customer

Package a release someone else can inspect

A small predictable file package reduces ambiguity at the handoff.

  1. Group the handoff files. Use one project folder so the image, copy, review notes, and reference sheet stay together.
  2. Include the less visible work. Place alternative text and the acceptance checklist beside the image instead of leaving them in a chat.
  3. Keep drafts distinguishable. Use version numbers and one approved folder so the operator does not accidentally upload an older image.
  4. State what remains pending. A short readme names the intended release, the files to use, and any unresolved approval gate.
See the worked diagramREADME / RELEASE STATUS — fictional worked exampleWORKED EXAMPLE · FICTIONAL PROJECTREADME / RELEASE STATUSOperator noteUse togetherImage v02 + caption v02PendingOwner and language approvalDo not publish yetReady for review, not releaseFictional practice project • no real customer

Make the approval checkpoint explicit

An automated workflow needs a human decision when facts, rights, or identity are unresolved.

  1. Give the owner a short checklist. Ask for a decision on facts, appearance, destination, and permissions rather than an open-ended reaction.
  2. Point to the exact version. Approval must identify the image and caption version; a vague “looks good” can refer to an earlier draft.
  3. Use a hold when facts change. If the owner changes a service hour, update every affected file and request review of the revision.
  4. Keep automation inside the gate. Preparation can continue, but publishing stays blocked until the actual owner approves the intended final package.
See the worked diagramRELEASE DECISION — fictional worked exampleWORKED EXAMPLE · FICTIONAL PROJECTRELEASE DECISIONNot approvedHOLD PUBLICATIONResolve facts or permissionsApproved exact packageProceed to schedulingKeep decision evidenceThis fictional exercise supplies no real customer approval

Create a publication plan with context

Schedule a reviewed release, preserve its exact assets, and avoid unsupported timing claims.

  1. Choose one channel first. Start the example with one image post so its publication and follow-up can be checked without ambiguity.
  2. Write the local time clearly. The hypothetical slot is Tuesday at ten-thirty, in the business’s time zone; it is not an optimal-time claim.
  3. Freeze assets before scheduling. Verify the destination account, selected image, caption, and time together before confirming the scheduled job.
  4. Store the provider receipt. Record the scheduled job reference, but leave the public URL empty until a native post is verified.
See the worked diagramRELEASE RECORD / SCHEDULED — fictional worked exampleWORKED EXAMPLE · FICTIONAL PROJECTRELEASE RECORD / SCHEDULEDEvidence fieldsProvider jobSaved after schedulingNative public URLUNKNOWN — not yet verifiedStateScheduled, not publishedFictional practice project • no real customer

Verify publication on the actual destination

A scheduler receipt proves a job state; public availability needs separate evidence.

  1. Distinguish the evidence levels. A queued job, a provider success report, and a visible native post are three different observations.
  2. Open the native post. Check that the expected image and caption appear on the intended account, with the intended visibility.
  3. Record a useful receipt. Save the native URL, observation time, and version reference without copying private account details.
  4. Leave unknowns visible. If the page is inaccessible, record verification pending rather than replacing missing evidence with a success label.
See the worked diagramPUBLIC PAGE CANNOT BE CHECKED — fictional worked exampleWORKED EXAMPLE · FICTIONAL PROJECTPUBLIC PAGE CANNOT BE CHECKEDObservedVerification unavailableCause not yet establishedCorrect next statePENDING VERIFICATIONRecheck the native destinationFictional practice project • no real customer

Recover from a failed or uncertain publication

Check before retrying so a timeout does not create duplicate posts.

  1. Treat a timeout as uncertain. A missing response does not prove publication failed; the destination may already contain the intended post.
  2. Search for the intended release. Compare the account, artwork, caption, and recent publication time to identify an existing matching post.
  3. Retry only after resolution. If failure is confirmed and no matching post exists, correct the cause and make one controlled retry.
  4. Keep the history useful. Store the original attempt, corrected issue, and final native evidence as separate entries in the release log.
See the worked diagramRELEASE LOG / RECOVERY — fictional worked exampleWORKED EXAMPLE · FICTIONAL PROJECTRELEASE LOG / RECOVERYThree recordsAttempt 01Timeout; outcome investigatedCorrectionCause resolved before retryNative receiptFinal verified destinationIllustrative recovery path • no real post or account action

Measure useful response without inventing attribution

Separate platform views, website sessions, and relevant inquiries; label hypothetical examples.

  1. Start with unknown values. Set the review window and metric definitions first; an uncollected value must remain unknown, never zero.
  2. Keep views in their own lane. Suppose the platform reports one hundred twenty views; that number is not the count of unique people.
  3. Do not combine unlike counts. Twelve website sessions describe a different measure; without reliable attribution, do not call them twelve customers.
  4. Define a meaningful inquiry. Count one genuine relevant request with a usable next step, excluding spam, tests, and duplicate messages.
See the worked diagramHYPOTHETICAL CHECKPOINT / NOT DTRT RESULTS — fictional worked exampleWORKED EXAMPLE · FICTIONAL PROJECTHYPOTHETICAL CHECKPOINT / NOT DTRT RESULTSPlatform views120Illustrativeplatform totalWebsite sessions12Illustrative sessioncountRelevant inquiries1Illustrativededuplicated requestHypothetical data only • no identities, message text, or revenue

Use the evidence to choose the next revision

Carry one evidence-based question into the next release rather than declaring a winner.

  1. Inspect the path before redesigning. If people see the post but the destination fails, repair that specific route before changing the creative.
  2. Choose one testable change. If the route works but attention is weak, try a clearer menu-first heading while holding the other facts steady.
  3. Compare like with like. Review the same metric at the same post age, while noting audience and distribution differences.
  4. Hand off a repeatable process. A brief, reviewed package, verified receipt, and dated learning note make the next release easier to inspect.
See the worked diagramTHE COMPLETE RELEASE PATH — fictional worked exampleWORKED EXAMPLE · FICTIONAL PROJECTTHE COMPLETE RELEASE PATHPrepareBrief + packageFacts, copy,artworkVerifyApproval + nativereceiptEvidence beforecompletionImproveDated review + onetestLearn withoutoverclaimingReusable workflow • this entire project was a fictional worked example