This week

Build with purpose, test as you go

Last week, critique helped you identify what to improve and establish a final project plan. This week, use that plan to make the most important design and functional decisions real. Work in short cycles: build a small part, preview it, test it, and revise it before moving on.

Learning outcomes

By the end of this lesson, you should be able to:

• Translate a project brief and critique notes into a practical production checklist.
• Build and refine a consistent interface using reusable styles and components.
• Test layouts at desktop, tablet, and mobile widths.
• Check links, images, forms or controls, and interactive behaviors.
• Use browser developer tools and a repeatable process to locate basic errors.
• Apply core accessibility checks, including keyboard use, visible focus, readable contrast, and meaningful image text alternatives.
• Prepare project files and content for a reliable presentation or deployment.

Production workflow

Build in manageable passes

1. Pass 1 — Structure: make sure the main sections, page hierarchy, navigation, and content are in place.
2. Pass 2 — Visual system: apply typography, color, spacing, image treatment, and reusable patterns consistently.
3. Pass 3 — Responsive layout: adjust the design for smaller screens and prevent horizontal overflow.
4. Pass 4 — Interaction: test buttons, menus, links, toggles, forms, and any JavaScript behavior.
5. Pass 5 — Accessibility: check keyboard navigation, focus states, headings, labels, contrast, and image alternatives.
6. Pass 6 — Quality assurance: check broken links, missing assets, spelling, console errors, and the final presentation.

Work from the critique

Use your three priority revisions

Return to the three revision goals you selected during Week 13. Keep them visible while you work. For each one, write a small action that can be completed and checked.

These are examples. Use the findings from your own critique rather than copying these tasks if they do not fit your project.

Responsive testing

Check more than one screen size

A responsive design is not simply a smaller desktop page. Content may need to stack, spacing may need to change, and navigation or controls must remain usable.

In your browser’s developer tools, enable device emulation or resize the browser window. Test the page at several widths, not only at one preset device size.

.project-layout {
  display: grid;
  grid-template-columns: 2fr 1fr;
  gap: 2rem;
}

@media (max-width: 700px) {
  .project-layout {
    grid-template-columns: 1fr;
  }
}

How to read this CSS

• .project-layout selects an HTML element with the class project-layout.
• display: grid; turns that element into a grid layout.
• grid-template-columns: 2fr 1fr; creates two columns. The first gets twice the available space of the second.
• gap: 2rem; adds space between the columns.
• @media (max-width: 700px) applies the rules inside it when the viewport is 700 pixels wide or narrower.
• Inside the media query, grid-template-columns: 1fr; changes the layout to one column, so the content stacks.

JavaScript, one step at a time

Test one interaction from beginning to end

For JavaScript, do not start by trying to understand an entire script at once. Identify one interaction and trace what happens when a person uses it. Use the pattern find → listen → respond.

This example makes a button switch a message between hidden and visible. It is a simple example of a control that responds to user input.

<button id="toggle-message"
  type="button">
  Show project note
</button>

<p id="project-message" hidden>
  Remember to test this page on a small screen.
</p>

const button = document.querySelector("#toggle-message");
const message = document.querySelector("#project-message");

button.addEventListener("click", function () {
  message.hidden = !message.hidden;
});

Line-by-line explanation

1. const button = ... gives the button a name in the script. The name button is a variable: a label that stores a reference to something.
2. document means the current web page.
3. querySelector("#toggle-message") searches for an element whose ID is toggle-message. The # means “look for an ID.” The spelling must match the HTML exactly.
4. The next const finds the paragraph and stores its reference in the name message.
5. addEventListener("click", ...) asks the browser to listen for a click on the button. An event is an action or occurrence, such as a click.
6. function () { ... } holds the instructions to run when the click occurs. The braces mark the beginning and end of those instructions.
7. message.hidden checks whether the message is currently hidden. The value is either true or false.
8. The exclamation mark ! means “not” in this expression. It reverses the Boolean value: !true becomes false, and !false becomes true.
9. message.hidden = !message.hidden; assigns the opposite of the current value. If the message is hidden, the click makes it visible. If it is visible, the click hides it again.
10. The semicolon ends the statement. The quotation marks around "click" indicate a text string, while true and false are Boolean values and do not need quotation marks.

Accessibility reminder: use a real <button> for an action. A real button can be operated with a keyboard and provides built-in behavior that a plain <div> does not.

Quality assurance

Run a final project check

Do not rely on memory. Use a checklist and test the project as if you were a first-time visitor.

• All required pages or sections are present and in a logical order.
• Navigation links and calls to action lead to the correct destinations.
• Images load correctly and have appropriate alternative text when needed.
• Text is readable, headings are organized, and color contrast is sufficient.
• Interactive controls work with a mouse and keyboard.
• Keyboard focus is visible and moves in a sensible order.
• Layouts work at desktop, tablet, and mobile widths without unintended horizontal scrolling.
• No obvious placeholder text, broken images, or unfinished content remains.
• The browser Console has been checked for errors.
• Project files are named clearly and the correct final version is saved.

Deployment and presentation

Make it ready for someone else to use

Deployment depends on the platform you are using. A project hosted through a service, published through a website builder, or presented locally may have different steps. Follow the process appropriate to your project, and make sure the final version can be accessed for critique.

1. Save and organize: keep the final files together and use clear names for pages, stylesheets, scripts, and image assets.
2. Check paths: verify that image, CSS, JavaScript, and page links point to the correct locations.
3. Preview the final version: do a complete walkthrough after your last edits, not just before them.
4. Publish or prepare access: confirm that your instructor and classmates can open the project or that you can demonstrate it reliably.
5. Prepare a short walkthrough: explain the project goal, audience, key design decisions, one meaningful interaction, and one revision made in response to critique.

In-class studio

Production sprint and peer test

1. Plan — 5 minutes: choose the most important task from your Week 13 revision list.
2. Build — 25 minutes: implement that change, then work through the next most important task if time allows.
3. Responsive check — 10 minutes: test desktop, tablet, and mobile layouts.
4. Peer test — 10 minutes: ask a classmate to complete one task without explaining how the interface works.
5. Fix — 10 minutes: address one issue observed during the peer test.
6. QA and wrap-up — 10 minutes: run through the checklist and record what remains.

Submit before leaving class

• A working version of your final project or prototype.
• A completed checklist for responsive behavior and core functionality.
• One piece of feedback from a peer test and the change you made in response.
• A short list of remaining tasks, ordered by priority.
• A link or clear access method for the final critique.

Reflection

Before the final critique

• Which revision improved the user experience the most?
• What did you discover by testing at different screen sizes?
• What did a peer do or misunderstand that you did not expect?
• What is the biggest remaining risk, and how will you address it?
• What design decision are you prepared to explain during the final critique?