Present a digital product

Outcome

You will prepare and deliver a 5–7 minute presentation of a digital product. You will show one complete user route, explain two technical decisions, connect quality claims to test evidence, state known limits, and recover if the live demonstration is unavailable.

Why this matters

A product presentation helps other people understand what you built, why selected decisions matter, and which results the evidence supports. A clear presentation is a guided inspection of the product, not a performance of confidence or a list of every task you completed.

What you will practice

Plan a presentation for a named audience, purpose, and time limit.
Select one product route that demonstrates a complete user outcome.
Explain technical decisions with focused source or interface evidence.
Report tests and known limits without overstating product quality.
Prepare readable visual material and describe visual information aloud.
Rehearse a live demonstration and use a prepared recovery route when needed.

What is new and what is reused

New: Presentation route, audience purpose, spoken claim, evidence view, demonstration state, time budget, transition, recovery route, and question boundary.
Reused: Working website, README, test report, screenshots, semantic HTML, reusable CSS, responsive layout, image preparation, validation, manual tests, and known limitations.

Starting point

Before you start

Your completed quality-profile project and private repository with index.html, styles.css, images, test-report.md, and README.md.
A current browser and VS Code.
A timer that you can see or hear without interrupting the presentation.
A folder where you can save current fallback screenshots or a short recording.

Current state: The project contains a working product and written evidence, but the material does not yet form one timed route for an audience.
First action: Create presentation-plan.md in the project root and write the audience, purpose, required duration, and one-sentence product result.
First checkpoint: presentation-plan.md identifies who will listen, what they need to understand, the 5–7 minute boundary, and the product result that the presentation will demonstrate.
Help trigger: Use the recovery note or ask for help if the product route is longer than two minutes, a claim has no supporting evidence, source text is unreadable from presentation distance, or the live demonstration cannot return to a known starting state.

Required result

You have completed the lesson when the presentation:

lasts from 5–7 minutes before questions;
identifies the product, intended user, and task in the opening;
demonstrates one complete user route in the running product or prepared fallback;
explains two technical decisions and the visible effect of each decision;
uses focused, readable evidence instead of scrolling through whole source files;
reports tested conditions, at least one specific quality result, and known limitations;
does not claim complete accessibility, production readiness, security, performance, or browser support without matching evidence;
describes important visual changes aloud and does not depend on color alone;
has a tested recovery route for product, browser, display, or network failure;
ends with the current result and one useful next change; and
leaves project files, personal data, unrelated tabs, and notifications outside the visible presentation route; and
records the final presentation plan and fallback files in the clean, pushed quality-profile repository.

Presentation route

Move from product purpose to visible evidence

The route is a sequence, not a list of every file or edit. Select evidence that helps the audience understand the product and evaluate the stated result.

Define the audience and purpose

Use this audience unless your presentation has a different named audience:

A teacher and other web-development students who need to understand the product result and evaluate how the implementation supports it.

Write these lines in presentation-plan.md:

# Product presentation plan

- Audience: Teacher and web-development students
- Purpose: Show the current product result and the evidence behind selected decisions
- Duration: 5–7 minutes, followed by questions
- Product: Responsive profile website
- Intended user: A visitor reviewing a junior developer's skills and selected work
- User outcome: The visitor can understand the profile, review projects, and find the contact route

Replace the example facts with your project. The audience and purpose control which details belong in the route.

Decide what stays outside the presentation

The route does not need:

a history of every edit;
every HTML element or CSS declaration;
the full test report;
every unsuccessful attempt;
personal information about you or another person; or
a claim about work that is not in the current project.

Keep the source files and report available for questions, but select only evidence that supports the main route.

Build a five-part route

Create one section for each part in presentation-plan.md:

## 1. Purpose

## 2. Product route

## 3. Technical decisions

## 4. Test evidence and known limits

## 5. Current result and next change

Use this time budget:

Part	Target time	Main question
Purpose	30–45 seconds	What is this, who is it for, and what can they do?
Product route	90–120 seconds	What complete user outcome works?
Two decisions	90–120 seconds	Which implementation choices support the result?
Evidence and limits	60–90 seconds	What did you test, and what remains outside the claim?
Close	30–45 seconds	What is the current result and next useful change?

The range leaves a small transition margin inside the 5–7 minute limit.

Checkpoint: The route has a purpose and time budget

What now works: The plan has one audience, one product outcome, five route parts, and a realistic time target for each part.
Files changed: presentation-plan.md
What remains: Choose product, source, and test evidence for each spoken claim.
Next action: Write the exact starting state and actions for one complete product route.
If it does not work: If the plan exceeds seven minutes before rehearsal, remove background history and secondary features. Keep one complete user outcome and two decisions.

Prepare one complete product route

A product route has a start state, actions, and a visible result. Select a route that matters to the intended user.

Example route:

Start at the top of the profile page at a wide viewport.
State what the page communicates in the first visible section.
Use the navigation to move to the project section.
Open or focus one project entry and identify the information hierarchy.
Move to the contact section.
Return through browser history if the route changes location.
Resize to the prepared narrow width and show that the same required content remains available.

Record the route as actions, not as a script of every word:

## 2. Product route

Start state:
- Browser at the top of `index.html`
- Wide viewport with 100% zoom
- No developer tools open

Actions and evidence:
1. Identify the profile purpose in the hero content.
2. Use the Projects link and show the section heading plus one complete card.
3. Use the keyboard to move through visible links and show the focus indicator.
4. Change to the prepared narrow viewport and show the navigation and project card.
5. Return to the wide starting state.

End result:
- The audience has seen one content route, keyboard focus, and the narrow layout.

Stabilize the demonstration state

Before each rehearsal and delivery:

close unrelated tabs and applications;
disable visible notifications when you control the device;
open the exact product file or local URL;
set the starting viewport and zoom;
place the browser at the first page position;
prepare source excerpts in separate named tabs;
keep private files and browser history out of the route; and
confirm that every local image and link resolves.

Connect decisions to visible effects

For each technical decision, prepare three parts:

Decision: What did you choose?
Reason: Which product need does it address?
Evidence: What focused view shows the implementation or effect?

Decision: Use header, nav, main, section headings, and footer for the major regions.

Reason: The elements identify the role and hierarchy of content instead of using visual containers alone.

Evidence: Show the relevant outline from index.html, then show the matching visible regions. Keep the excerpt short enough to read at presentation distance.

Decision: Use one .project-card class for repeated project entries.

Reason: One shared rule set keeps spacing and borders consistent and gives later changes one controlled location.

Evidence: Show two visible cards, then show the focused selector and one matching HTML class.

Decision: Provide 480-pixel and 960-pixel WebP sources through srcset.

Reason: The browser can select a suitable source for the rendered size and pixel density.

Evidence: Show the image in wide and narrow layouts, then show only the img element with src, srcset, sizes, dimensions, and alternative text.

Use your own project decisions. Do not select a decision because its code looks advanced. Select it because the audience can connect it to a visible or structural product effect.

Make source evidence readable

Increase editor text to a readable size before the presentation.
Show about 5–12 relevant lines, not the whole file.
Place the relevant lines near the top of the editor.
Close sidebars and panels that reduce the source area.
Explain the selector, element, or attribute before moving the pointer.
Use a pointer or highlight in addition to spoken position and color.
Keep a static screenshot of each essential excerpt as a fallback.

Checkpoint: Every selected decision has evidence

What now works: Two technical decisions each have a product reason, a focused source or interface view, and a visible or structural effect.
Files changed: presentation-plan.md, index.html, styles.css
What remains: Prepare test evidence, limits, the close, and recovery material.
Next action: Select one verification result, one repair or retest, and the known limits that bound the presentation claims.
If it does not work: If a source view takes more than 20 seconds to locate or explain, save a focused excerpt and record the exact file and line context in the plan.

Present quality as evidence and boundaries

Use test-report.md as the source. Select evidence that helps the audience evaluate the product.

Include:

the browser and conditions used;
one specific result tied to the demonstrated route;
one issue that you repaired and retested, when available;
related regression checks after the repair; and
known limits or work outside the test scope.

## 4. Test evidence and known limits

- Tested in Firefox 141 on Windows 11.
- Required content remained available at about 320 CSS pixels and 200% zoom.
- All visible links were reachable with the keyboard and had a visible focus state.
- After repairing an overflowing project title, the same narrow-layout test passed.
- Regression checks confirmed that wide cards and focus outlines still passed.
- Current limits: one-browser test scope and no assistive-technology user testing.

Replace the example versions, conditions, and results with your evidence. Do not announce an accepted limitation as a passed test.

Use accurate quality language

Avoid	Prefer when the evidence matches
“The website is fully accessible.”	“The preliminary keyboard, heading, image-text, narrow-layout, and zoom checks passed in the tested browser.”
“It works on every device.”	“Required content remained available at the tested wide and 320-pixel conditions.”
“The code is perfect.”	“The final HTML validation messages and VS Code CSS diagnostics were resolved or classified in the test report.”
“The image is optimized.”	“The displayed WebP sources are 480 and 960 pixels wide and remain below the documented file-size limits.”

Prepare a close

The close answers two questions:

What can the current product now do?
What is the next useful change, and why does it come next?

Example:

The current profile gives a visitor a responsive route from the introduction to selected projects and contact information. The documented keyboard, narrow-layout, zoom, image, and validation checks pass in the tested browser. The next useful change is a structured user test with two readers because the current evidence describes technical behavior but not whether new visitors understand the content hierarchy.

Keep the close consistent with the stated limits. Do not introduce a new feature during the last sentence.

Prepare recovery routes

A recovery route protects the explanation when a tool or environment fails. It does not need to reproduce every live interaction.

Create a presentation-fallback/ folder with current, non-private material:

one screenshot of the starting state;
one screenshot of the completed product route;
one screenshot of the narrow layout;
focused images of the two source excerpts; and
a screenshot or excerpt of the selected test evidence.

Add this table to the plan:

Failure	First response	Prepared route
Product does not load	Check the documented local path once	Use current product screenshots
Browser route resets	Return to the named starting state	Explain the same route from screenshots
Source tab is missing	Do not search through unrelated files	Use the focused source excerpt
Display is unreadable	Increase zoom once	Use the prepared large-text evidence view
Network is unavailable	Skip external links	Use local project and local fallback files

Test the fallback with the network disconnected from the route. Keep all required material local.

Rehearse, record evidence, and revise

Complete two different rehearsals.

Rehearsal 1: content and timing

Start from the prepared product state.
Deliver the complete route without stopping the timer.
Record the duration of each part and the total duration.
Mark every point where you search, repeat, lose the route, or use an unsupported claim.
Cut secondary detail before you increase speaking speed.
Repeat the parts that changed and confirm that the full plan still fits 5–7 minutes.

Rehearsal 2: technical and recovery

Reset the product, browser, editor, viewport, and zoom to the documented starting state.
Deliver the route with the same windows and transitions planned for the presentation.
Intentionally make the live product unavailable at one point.
Move to the prepared fallback without opening private or unrelated material.
Continue the explanation and complete the close.
Record unreadable evidence, broken paths, slow transitions, and missing descriptions.
Repair the route and retest the affected transition.

After each rehearsal, record:

## Rehearsal record

- Date and environment:
- Total duration:
- Parts outside their target range:
- First unclear transition:
- Unsupported or broad claim:
- Unreadable visual evidence:
- Recovery route tested:
- Change made:
- Retest result:

Checkpoint: The complete route and fallback have rehearsal evidence

What now works: The presentation fits 5–7 minutes, essential views are readable, transitions start from known states, and a deliberate live-demo failure can move to the fallback route.
Files changed: presentation-plan.md, presentation-fallback/
What remains: Complete the accessibility, privacy, accuracy, and delivery checks.
Next action: Run the self-check from the final starting state, then keep the files unchanged until delivery.
If it does not work: If the route remains too long, remove one secondary example or source detail. Keep the complete user route, two decisions, evidence boundary, and close.

During the presentation

Start the timer and use your first prepared sentence.
Keep the product route in the planned order.
Pause after changing a page, viewport, or source view so the audience can locate it.
Describe meaningful visual information aloud, including focus, layout, and state changes.
State what an excerpt proves before explaining its syntax.
If a route fails, use the prepared fallback after one focused check.
If you do not know an answer, state the boundary and identify where you would verify it.
Keep questions separate from the timed route unless the presentation format requires interruptions.

Presentation quality does not depend on eye contact, standing still, speaking without notes, or hiding a need for a pause. Use notes, seating, a timer, water, and a stable window layout when they help you deliver accurate information.

Assistance

Assistance 1 — Choose the next preparation action

Create presentation-plan.md, write the six context lines, and add the five route headings. Then complete one heading before you prepare another view.

Assistance 2 — Reduce a route that is too long

Keep one sentence for purpose, one complete product route, two decisions, one quality result, known limits, and one next change. Move file history, extra features, and detailed syntax to possible question material.

Assistance 3 — Connect a claim to evidence

Write the claim in one sentence. Under it, name the exact interface state, source excerpt, or test case that supports it. If no evidence supports the claim, narrow or remove it.

Assistance 4 — Recover when the live demonstration fails

State: “The live route is not available, so I will use the current fallback images.” Open the prepared start and result images, explain the same user route, then continue to the two decision excerpts and test evidence.

Assistance 5 — Use a complete speaking frameExample solution

Use five transitions: “This product helps…”, “I will show the route from…to…”, “The first implementation decision is…because…”, “The test evidence supports…and the current limit is…”, and “The current result is…and the next useful change is…”. Replace every blank with project evidence and keep the route inside the planned duration.

Self-check

Complete these checks against the required result.

Confirm that the opening names the product, intended user, task, and current result within 45 seconds.
Run the planned user route from its documented starting state and confirm that it reaches one complete visible outcome.
Show each of the two decision views at presentation size. Confirm that the relevant source or interface evidence is readable without searching.
Compare each quality claim with test-report.md and remove or narrow any claim that the recorded evidence does not support.
State the browser and test conditions, a specific result, and known limits as separate facts.
Describe important focus, layout, and state changes aloud and confirm that the explanation does not depend on color alone.
Search every visible tab, path, screenshot, and notification area for private or unrelated information. Remove any result.
Trigger one planned failure and confirm that the local fallback preserves the same explanation and evidence boundary.
Deliver the complete route with a timer. Confirm that it lasts 5–7 minutes before questions.
End with the current product result and one next change that follows from the stated evidence or limit.
Run git status and confirm that only the completed presentation plan and fallback files remain before the presentation commit.

Record the presentation checkpoint

After both rehearsals, the recovery test, and the self-check pass, run from quality-profile:

git status
git diff
git add presentation-plan.md presentation-fallback
git diff --staged --stat
git commit -m "Prepare quality profile presentation"
git push

Confirm that the staged files contain no private or unrelated presentation material. Reload the private GitHub repository and confirm that the presentation commit is the newest commit on main.

Optional extensions

Next step or safe stopping point

You now have a tested product, reader-focused documentation, a timed presentation route, a local recovery route, and a pushed project history. Keep the final starting state and fallback files together. Use this method for the final project: build the required result, record its working phases, verify it, document it, and present only the claims that your evidence supports.