Design a landing page for a photographer's portfolio site

## Role and objective

You are a UX/UI designer creating a landing-page specification for a photographer's portfolio site. Produce an implementation-ready design brief for the people who will design, build, or review the page. The page must present the photographer's work clearly and guide visitors toward a defined action without inventing portfolio content, identity, positioning, or business details.

Output the specification in the structure required below, covering screens, components, states, accessibility, responsive behaviour, and design tokens. Completion means that another designer or developer can understand the page hierarchy, visual system, interactions, and missing inputs without guessing any unconfirmed fact.

## Scope and given facts

In scope:

- One landing page for a photographer's portfolio site.
- Presentation of photographic work, supporting information, and a visitor action.
- Responsive layout, interaction states, accessibility requirements, and design tokens.
- A clear distinction between confirmed requirements and items requiring input.

Confirmed facts:

- The deliverable is a landing page.
- The site belongs to a photographer.
- The site functions as a portfolio site.
- No photographer name, photography genre, audience, location, portfolio assets, brand identity, conversion goal, CMS, framework, or launch constraints were provided.

Use these slots where needed:

- `[FILL IN: photographer identity, specialization, and portfolio positioning]` — fill with the approved name, photographic focus, and positioning.
- `[FILL IN: target audience and primary conversion goal]` — fill with the intended visitors and the main action they should take.
- `[FILL IN: available images, copy, logo, fonts, and brand colours]` — fill with the assets and brand materials supplied for the page.
- `[FILL IN: technical stack and supported browsers]` — fill with the implementation environment.

Do not arbitrarily fill the photographer's identity, specialty, image subjects, location, testimonials, client names, pricing, availability, or calls to action.

## Working rules

Use the confirmed facts as the design basis. Treat every other project detail as unconfirmed until supplied. Judge each design choice by whether it improves portfolio discovery, preserves the visual prominence of the photography, supports the primary conversion goal, and remains usable across screen sizes.

Apply the following branches:

1. If a specialization is supplied, use it to shape imagery, navigation labels, copy hierarchy, and visual emphasis. If it is not supplied, use neutral labels such as “Selected work” only where necessary and mark the specialization as `[FILL IN: photography specialization]`.
2. If a conversion goal is supplied, make it the dominant call to action. If it is not supplied, show a clearly marked `[FILL IN: primary call to action]` rather than choosing “Book,” “Contact,” or another action.
3. If portfolio images are supplied, describe how those actual assets are arranged and prioritised. If they are not supplied, specify image roles, aspect-ratio requirements, cropping rules, and accessible text without inventing subjects or captions.
4. If a brand system is supplied, preserve its confirmed colours, typography, and logo treatment. If not, propose tokens as provisional design decisions and label them `[PROVISIONAL]`, not as established brand facts.

Meet the shared UI rules: retain any supplied `brandAnchor`; cover loading, empty, and error states; specify keyboard operation and screen-reader labels. Set the accessibility target to WCAG 2.2 AA and ask whether ADA Title III or Section 508 governs the audience. Require the layout to work at 200% zoom and at a 320px viewport without horizontal scrolling. Explicitly define date, number, currency, and address formats if those fields appear; otherwise state that they are not used.

## Output structure

Produce the specification in exactly this order:

1. **Screen list** — List the landing-page screen and any explicitly required overlays, menus, or destination states. State the purpose of each and allocate approximately 10% of the response to this section.
2. **Components per screen** — For each screen, specify the header, navigation, hero, portfolio/gallery area, supporting content, calls to action, footer, and any supplied or missing assets. Describe hierarchy, content roles, responsive layout, and image treatment. Allocate approximately 35%.
3. **Behaviour per state** — Define loading, populated, empty, error, hover, focus, keyboard, mobile-navigation, and reduced-motion behaviour where relevant. Include visible error messages, recovery actions, focus order, screen-reader labels, and interaction rules. Allocate approximately 30%.
4. **Design tokens** — Specify colour, type, spacing, grid, breakpoints, border, elevation, motion, image ratios, and interaction states. Mark unconfirmed proposals `[PROVISIONAL]` and leave project-dependent values as slots. Allocate approximately 25%.

Include a compact **Open inputs** list at the end of the relevant component or token sections, not as a new top-level section. For every unresolved item, state exactly what information must be supplied.

Use the following project-dependent slots where required:

- `[FILL IN: photographer identity, specialization, and portfolio positioning]`
- `[FILL IN: target audience and primary conversion goal]`
- `[FILL IN: available images, copy, logo, fonts, and brand colours]`
- `[FILL IN: technical stack and supported browsers]`
- `[FILL IN: governing accessibility regime, if applicable]`

## Style rules

Use a hybrid style. Use concise, itemized lists and tables for screen inventories, component specifications, states, tokens, dimensions, and acceptance details. Use short narrative paragraphs only to explain the page's visual concept, content hierarchy, and rationale. Keep the register professional and design-specific. Avoid photography clichés such as “capture the moment,” “tell your story,” “where art meets emotion,” “breathtaking imagery,” and “bringing memories to life” unless supplied as approved copy.

## 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 specification for a photographer's portfolio site, not completed website copy, code, or unrelated marketing material.
2. Confirm that the output uses exactly the required UI structure: screen list, components per screen, behaviour per state, and design tokens.
3. Confirm that loading, empty, and error states are covered with usable feedback and recovery behaviour.
4. Confirm that keyboard operation, focus order, screen-reader labels, WCAG 2.2 AA, 200% zoom, and the 320px viewport are addressed.
5. Confirm that the primary call to action is taken from `[FILL IN: target audience and primary conversion goal]` or remains an explicit slot; it must not be invented.
6. Confirm that the photographer's identity, specialization, image subjects, location, clients, testimonials, pricing, and availability were not added beyond the input.
7. Confirm that `[FILL IN: available images, copy, logo, fonts, and brand colours]` was not filled with arbitrary assets or brand decisions.
8. Confirm that any proposed visual tokens are marked `[PROVISIONAL]` when the user supplied no brand system.
9. Confirm that no date, number, currency, or address format is implied unless the page actually uses that field and its format is specified.
10. Confirm that the design remains within the requested landing-page scope and does not drift into a full multi-page site, backend specification, or implementation claim.
11. Confirm that the response follows the hybrid style: itemized technical sections and brief narrative rationale only where useful.
12. Confirm that every unresolved project dependency is represented by a precise slot explaining what must fill it.