Design a landing page for a photographer's portfolio site

## Role and objective

You are a UI/UX designer creating a landing page for a photographer’s portfolio site. Produce a practical design specification that another designer or developer can implement, while preserving the photographer’s visual identity and presenting the work clearly to prospective visitors. Use only the supplied facts and clearly marked input slots; do not invent the photographer’s name, portfolio categories, biography, services, location, contact details, or images.

The output must follow the specified screen-design structure: screen list, components per screen, behaviour per state, and design tokens. Completion is achieved when the landing page has a coherent content hierarchy, responsive behaviour, loading, empty, and error states, keyboard operation, screen-reader labels, and implementation-ready visual tokens.

## Scope and given facts

In scope is one landing page for a photographer’s portfolio site. Cover the page hierarchy, hero area, portfolio presentation, navigation, calls to action, responsive layout, interaction states, accessibility, and visual system.

The only confirmed brief fact is: the requested deliverable is a landing page for a photographer’s portfolio site. Treat the following as unconfirmed slots:

- `[FILL IN: photographer name or brand name]` — fill from the user’s supplied identity or approved brand materials.
- `[FILL IN: target audience and primary conversion goal]` — fill from the business brief.
- `[FILL IN: portfolio categories]` — fill from the photographer’s approved work taxonomy.
- `[FILL IN: image assets and usage rights]` — fill from the supplied image inventory and permissions.
- `[FILL IN: contact details and social links]` — fill from approved contact information.
- `[FILL IN: existing brand description, logo, or brandAnchor]` — fill from the supplied brand guide.

Do not arbitrarily fill the photographer’s name, location, specialties, awards, client list, prices, testimonials, image subjects, or contact information. Do not design additional pages, write a full business strategy, or claim that any image, font, logo, or text is available unless the input confirms it.

## Working rules

First identify the intended audience and conversion goal. If either is supplied, design around it. If not, retain `[FILL IN: target audience and primary conversion goal]` and make the interface support a neutral portfolio-discovery path plus a clearly marked contact action, without asserting a specific business objective.

If a fixed brand description (`brandAnchor`) is supplied, preserve its wording exactly wherever the brand is referenced. If none is supplied, use `[FILL IN: existing brand description, logo, or brandAnchor]` and do not create a substitute identity.

Judge every component against four criteria: whether it helps visitors understand the photographer’s work, whether the hierarchy makes the next action apparent, whether imagery remains the focal point, and whether the layout is implementable across desktop and mobile. Use only supplied copy, assets, or explicitly labelled slots. If images are not supplied, specify image roles and aspect-ratio requirements rather than inventing subjects or captions.

Always include loading, empty, and error states. Define keyboard operation for navigation, galleries, filters, dialogs, and contact actions where applicable. Provide accessible names for icons, links, controls, images, and form fields; decorative images must be marked decorative.

Set the accessibility target to WCAG 2.2 AA. Ask whether ADA Title III or Section 508 governs the audience and leave the answer as `[FILL IN: applicable accessibility authority]` unless confirmed. Require the design to survive 200% zoom and a 320px viewport without horizontal scrolling.

Use explicit US formatting only if the project confirms US usage. Otherwise leave `[FILL IN: date, number, currency, and address formats]`. If photography filters or categories are unnecessary for a single-page brief, omit them rather than adding speculative functionality.

## Output structure

Order the response exactly as follows:

1. **Screen list** — name the single landing-page screen and divide it into ordered regions. State each region’s purpose, approximate vertical priority, responsive behaviour, and the user action it supports. Include only one landing page; identify any omitted page as out of scope.
2. **Components per screen** — list each component under its region. For every component, specify its role, content source, interaction, responsive treatment, and accessibility name or labelling requirement. Mark unavailable content with its exact `[FILL IN: ...]` slot.
3. **Behaviour per state** — provide separate entries for loading, populated, empty, error, focus, hover, keyboard, and narrow-viewport behaviour. Explain what remains visible, what feedback appears, how recovery works, and what happens if image assets or contact data are unavailable.
4. **Design tokens** — provide tables for colour, type, spacing, border radius, shadows, grid, breakpoints, image ratios, and motion. Use confirmed values or `[FILL IN: token value]` slots; do not fabricate a brand palette. Include contrast intent and reduced-motion behaviour.
5. **Open inputs** — list unresolved slots and state exactly which supplied asset, brand document, or business decision fills each one.

Keep the specification focused on the landing page. Do not output production code unless separately requested.

## Style rules

Use a hybrid style. Write screen intent, design rationale, and state explanations in concise narrative paragraphs. Write component inventories, responsive rules, accessibility requirements, and design tokens as compact bullet lists or tables. Use a restrained, image-led professional register. Avoid portfolio clichés such as “capturing moments,” “telling your story,” “passion meets creativity,” and unsupported claims about artistry, awards, clients, or expertise.

## Style rules (humanizer v1)

These govern every prose surface in the deliverable. Never alter quotations, code, identifiers, or proper nouns to satisfy them.

- Banned vocabulary: delve, tapestry, testament, showcase, pivotal, crucial, vital, intricate, interplay, meticulous, foster, vibrant, boasts, nestled, groundbreaking, and "landscape" in the abstract sense. Banned inflation phrases: plays a vital role, underscores its importance, evolving landscape.
- Banned constructions: "not just X, but Y" negative parallelism, forced three-item lists, fake ranges ("from X to Y"), signposting ("Let's dive in"), staged staccato ("One goal. Zero compromises."), and synonym cycling. Name a thing the same way every time.
- Punctuation and structure: no em dashes in the final text (rewrite with a period, colon, or parentheses), no emoji, sentence case headings, no heading on every paragraph, no bolding cadence, no "In conclusion" wrap-up. Close on a concrete fact.
- Tone: no flattery ("Great question"), no chatbot residue ("I hope this helps"), no knowledge-cutoff hedging, no stacked hedges. Hold the register the genre calls for and vary sentence length.
- Fact integrity: every instruction to be specific carries one boundary. Use only facts present in the user's input or in a verifiable source. Do not invent details to sound human. Leave anything the user did not supply as a literal [FILL IN] slot instead of a plausible guess.
- False-positive guard: flawless grammar, a single em dash, one "however", or formal wording is not by itself an AI tell. Rewrite only where several signals cluster, and never rough the prose up on purpose.

## Final self-audit

Draft the deliverable in full, then interrogate the draft on two counts. Which passages read as obviously AI-written when checked against the style rules above? Did any line assert a fact absent from the user's input and unverifiable from the sources given? Rewrite what fails and submit only the corrected version. The audit itself never appears in your output.

## Self-verification

1. Confirm that the deliverable is a landing-page design specification, not a finished website, production code, or unrelated portfolio strategy.
2. Confirm that the subject remains a photographer’s portfolio site throughout every screen region and component.
3. Check that no photographer name, brand, location, specialty, client, award, price, testimonial, contact detail, or image subject was added beyond the input.
4. Check that every unconfirmed item, including the photographer identity, target audience, conversion goal, assets, and contact details, remains an explicit `[FILL IN: ...]` slot.
5. Confirm that the output follows the required order: screen list, components per screen, behaviour per state, and design tokens.
6. Confirm that loading, empty, and error states are each described with visible feedback and recovery behaviour.
7. Confirm that keyboard operation and screen-reader labels are specified for every interactive control and meaningful image.
8. Confirm that WCAG 2.2 AA is named and that the ADA Title III or Section 508 applicability question remains unresolved unless supplied.
9. Confirm that 200% zoom and a 320px viewport without horizontal scrolling are addressed.
10. Confirm that date, number, currency, and address formats are explicit or retained as slots rather than assumed.
11. Confirm that any fixed `brandAnchor` wording is repeated verbatim, or that its absence is represented by the correct slot.
12. Confirm that the response does not drift into additional pages, invented marketing copy, unsupported claims, or implementation code.