The Museum

Step 1: Set up the project

Open a terminal and navigate to your development directory:

cd ~/dev

Start Claude Code:

claude

Paste the setup prompt:

Create the folder ~/dev/web-dev/p7. Download the project materials from https://learnbydirectingai.dev/materials/webdev/p7/materials.zip and extract them into that folder. Read CLAUDE.md -- it's the project governance file. Open VS Code in the project directory. Install the Claude Code extension and the Live Server extension if they aren't already installed.

Once Claude finishes, your workspace is ready. The CLAUDE.md file is the project governance file -- but this time, it's a reference exemplar, not the one you'll use. Later, you'll write your own.

Step 2: Read the meeting transcript

Open materials/first-contact.md.

This is a transcript from your initial meeting with Ivan Babic, the museum director, and Ana Kovacevic, the head of education. Ivan is formal and direct. He gets to the point and expects you to do the same.

The museum website is from 2016. It doesn't work on mobile. An accessibility audit found it fails on almost every WCAG criterion. A school group from Zagreb included a student who uses a screen reader -- she couldn't access any of the collection pages. The teacher called afterwards. Ivan calls it embarrassing. For Ana, who runs education programs, it was worse than embarrassing.

Ivan wants three things: a website that's fully accessible, a members section where 400 supporters can log in for exclusive content, and fast loading for tourists on phones.

Ana adds a fourth: the collection should be browsable online -- search by type, era, category -- for researchers and tourists who want to see what the museum holds before they visit.

Notice what the transcript doesn't tell you. Ivan mentions the collection but doesn't say where the data lives. He mentions members but doesn't mention data privacy regulations. He mentions the site needs to be fast but doesn't describe the image archive. These gaps are yours to discover.

Step 3: Talk to Ivan

Open the chat with Ivan. The meeting transcript gives you the broad problem, but not enough to plan the architecture.

You need to understand:

• Where does the collection data live? Ivan hasn't mentioned the database behind the current website. Ask about the source of artifact information.
• What are the images like? He wants the collection to be "browsable and beautiful." But how large are the original files? What formats? Who manages them?
• What happens when a member registers? He wants a login system. What personal data will the museum collect? Are there regulatory requirements?

Ask about these gaps. Ivan will answer precisely when you ask the right questions, but he won't volunteer information you didn't ask for. He's a primary client -- discovery is your job.

Pay attention to what you learn. The collection data, the image sizes, and any regulatory constraints will shape your architecture decisions in the next unit.

Step 4: Review the accessibility audit

Open materials/accessibility-audit.md.

This is the report from the external accessibility consultancy. The current site fails 14 of 18 WCAG 2.1 Level AA criteria. The failures are structural: missing alt text on 89% of images, no heading hierarchy, color contrast at 2.1:1 on the navigation (WCAG requires 4.5:1), no keyboard navigation support, no skip links, no ARIA landmarks, and forms without programmatic labels.

The consultancy recommends a full rebuild. Retrofitting would cost more than starting fresh because the problems are in the HTML structure, not just the styling.

The European Accessibility Act creates legal obligations for public institutions. "We didn't have time" is not a defense. Accessibility is a design input for this project, not something to add at the end.

Step 5: Identify the audiences

Four groups need the same website:

Tourists check the site on phones in Dubrovnik's old town, deciding whether to visit. They need fast page loads and clear information about hours, location, and what's on display. If the site takes too long, they walk to the next museum.

Researchers browse the collection from desktops -- searching by category, era, or type, reading artifact descriptions, examining images. They need search and filtering that works, not a scrollable list of 150 items.

Members log in to access exclusive content: lecture recordings, high-resolution collection images, research archive PDFs. They need a secure login and a dashboard that works smoothly.

Visitors using assistive technology -- screen readers, keyboard navigation, voice control -- need the site to work for them. The school group from Zagreb proved the current site doesn't.

These four audiences have competing technical requirements. A tourist on a phone needs the page pre-built and served instantly. A researcher searching the collection needs the page built fresh on each request because the results depend on their query. A member behind a login needs interactive content that loads in the browser. These aren't just different user needs -- they require different approaches to how pages are built and served.

You don't need to understand the technical solution yet. But recognizing that one approach won't work for all four audiences is the architectural insight that shapes everything you'll build.