Mono Designer Portfolio

---
name: bs-mono-designer-portfolio
description: "Build a monochrome graphic-design portfolio site on faint grid paper: a huge black display title beside a greyscale cut-out portrait, dark label chips, a two-by-four poster grid and generic tool tiles, with Home, About, Work, eight poster detail pages, Services and Contact. Every page is fully designed and linked, with work filters, a plus accordion and a demo brief form. Ideal for poster, print and illustration designers who want a quiet, print-like presence that lets the work carry all the colour."
---

# Mono Designer Portfolio

Build a portfolio for a poster, print or illustration designer that reads like
a printed portfolio sheet and that a demanding art director would call
premium: pale grey paper with a faint grid tilted about nine degrees, one heavy
grotesk in near-black, section titles as white type on dark label chips, the
designer as a greyscale cut-out that fades into the page, and colour only
inside the work. The designer should be able to publish the result as-is.

**Start from [references/template.html](references/template.html).** It is the
complete blueprint and engine: tokens, font faces, sticky header with a
paper backdrop on scroll, focus-trapped mobile sheet, hero with the letter-rise
display title, poster cards with a live HTML type layer over the artwork, the
work index (filters with counts, search, grid and index views, empty state),
one project-detail template rendered from data, services with a plus accordion,
the brief form with validation, loading and success states, a designed 404,
the hash router, reveals and toasts. Replace the content collections; keep the
machinery and the visual grammar.

## Files

- `references/template.html`: the complete site with `REPLACE` slots (the store demo is this file built with `inline-assets.mjs`). Images load from `images/<id>.webp` (shipped next to it); fonts load from the fontsource CDN.
- `references/style-guide.md`: tokens, type scale, layout, surfaces, component anatomy, do and don't, voice.
- `references/visual-contract.md`: the signature elements that must survive any rebrand, with measurements.
- `references/page-library.md` and `references/route-inventory.md`: every page, its sections and its data source.
- `references/interior-pages.md`: what makes each inner page useful.
- `references/image-plan.md`: art direction, every image slot by role and crop, the exact prompts and the in-place composite technique.
- `references/motion-system.md`: motion tokens, what moves and why, reveal fallback, reduced motion.
- `references/icon-library.md`: the SVG sprite and tool-tile rules.
- `references/quality-checklist.md`: the pre-delivery checklist.
- `references/framework-adaptation.md`: stack choice, component mapping, ReUI layer for React outputs.
- `references/reui-components.md`: which template control maps to which ReUI component.
- `references/images/`: the 14 sample images (eight posters, portrait, studio, four in-place scenes). Most show the sample designer's work; see "Adapting to a real brief" for which may be reused.
- `scripts/inline-assets.mjs`: builds the single file: inlines `images/`, `fonts/` and `assets/` references and the fontsource CDN fonts (downloaded once at build time); an image repeated across `<img>` tags is embedded once.
- `scripts/composite-in-place.py`: perspective-places a rendered poster onto a blank-sheet photo.
- `scripts/validate-mono.mjs`: the automated quality gate. Default mode checks your finished page and fails on any sample name left from the template; `--files` for a deployed site with local image and font files; `--template` for the template itself; `--demo` for the store demo.
- Fonts: Schibsted Grotesk (variable) and Geist Mono (variable). The template loads them from the fontsource CDN. In a framework project install `@fontsource-variable/schibsted-grotesk` and `@fontsource-variable/geist-mono` or use `next/font/google` (`Schibsted_Grotesk`, `Geist_Mono`); for a standalone single-file deliverable run `scripts/inline-assets.mjs`, which embeds both woff2 files as data URIs, so the page makes no network requests.

## Workflow

### 1. Establish content and output location

Read the target repository and its instructions first. Collect, or draft in the
designer's plain first-person voice: name, discipline label, city, founding year
and availability (city and availability are the two hero chips); a three-sentence bio with two or three
bolded facts; a dated career path of three to five rows; the projects (eight in the sample), each
with title, one category, client, year, role, one-line summary, Brief, Approach
(two paragraphs), Outcome, four deliverables, four print specs (size, process,
stock, run) and a three- or four-colour palette; four services with includes,
a starting price and a turnaround; four process steps; five FAQ pairs; contact
details. Four to sixteen projects work (eight fill the Home grid); see
"Adapting to a real brief". For a real designer every fact comes from the brief;
anything missing is drafted as plausible placeholder copy and listed in your
final reply. Use `.example` addresses only for details the brief does not give. Write concrete
nouns (paper stock, print runs, venues), short declarative sentences, no
superlatives, no lorem ipsum, no "Your Company", no invented press logos.

### 2. Choose the stack

With no existing project and no requested framework, the deliverable is **one
self-contained HTML file** built from the template, like the store demo: copy
`references/template.html` next to an `images/` folder, fill it, then run
`scripts/inline-assets.mjs` (images and fonts become data URIs, so the file makes
no network requests and runs inside a sandboxed preview). A normal deployed
site may keep `images/` and the font files beside the page instead.

When the buyer has a framework project or asks for one, honor it and read
`references/framework-adaptation.md` (Next.js App Router with TypeScript when a
framework is wanted but none is named): pages
become real routes (`/`, `/about`, `/work`, `/work/[slug]`, `/services`,
`/contact`, `not-found`), collections become typed data modules, fonts come from
`@fontsource-variable/schibsted-grotesk` and `@fontsource-variable/geist-mono`
(or `next/font/google`), icons from the framework's Lucide package. Never wrap the
template in an iframe or inject it as raw HTML. The hash router exists only for
the single-file output.

### 3. Keep the signature, read the system

Read `references/style-guide.md` and `references/visual-contract.md` before
writing markup. Non-negotiables:

- Greyscale interface only: paper `#E6E6E3`, ink `#1C1C1B`, their tints. Colour
  enters exclusively through the posters and in-place photographs.
- The grid paper: white hairlines at about 66% alpha, 115 px cells, tilted
  atan(1/6) (about 9.5 degrees), printed on the body so it scrolls with the page.
- Schibsted Grotesk for everything (400 to 900), Geist Mono only for numbers,
  specs, indexes and captions. The hero display word is the only text above
  110 px and stays on one line at every width.
- Section titles are white type on the dark `chip-label`, never plain headings.
- The portrait is a greyscale cut-out on pure white, multiplied into the paper
  and masked to fade out at the bottom edge.
- Posters are 2:3, square-cornered, with a soft paper shadow and a lift on
  hover; their title and meta are live HTML type set over type-free artwork.
- Tool tiles are generic craft icons on dark rounded squares. No software logos.

### 4. Plan the pages

Use `references/route-inventory.md` and `references/page-library.md`. Home,
a project index with one page per project, Contact (the brief form) and Not
found always ship; About and Services ship unless the brief has nothing for
them. Route names and labels are the buyer's own (rename `work` with `WORK`).
Keep the canonical Home order (hero, about teaser + toolkit, poster grid, on the
wall feature, service rows, client quote, dark CTA band). Every nav item, card,
chip, service row and footer link resolves to a designed page or an in-page
section. Read `references/interior-pages.md`: project pages carry brief,
approach, outcome, deliverables, print specs, copyable palette, an in-place or
close-up image, the format set and previous/next; never a heading and two
sentences. To add a project, append one record to `PROJECTS`; the grids,
filters, search, detail page, previous/next and footer list follow.

### 5. Plan and make the images

Follow `references/image-plan.md`. Write one art-direction sentence, then one
slot per role: the greyscale cut-out portrait, one type-free artwork per project
(each a different print medium, the type zone left empty), one documentary
studio photograph, and blank-sheet plates (wall, frame, window, paper stack)
for in-place shots. Composite the finished poster, with its live type, into
the plates with `scripts/composite-in-place.py`, so no text is ever baked into
a generated image. Pick the aspect per slot and set `object-position`; check
the square and story crops of every poster. Look at every result and
regenerate anything off-brief. Prefer the designer's real work and photos.

### 6. Build structure and interactions

Shared components: header, sheet, chip label, buttons, chips, poster card,
field, segmented choice, accordion, toast, CTA band, footer. Collections render
from data. Required behaviour:

- Router: fade/slide transition (170 ms out, 380 to 480 ms in), scroll to top,
  active nav (`aria-current`), page title, focus to the page, designed 404. In
  the single file keep route state in JS and wrap `history.pushState` in
  try/catch; intercept in-page anchors and scroll from script.
- Work index: category chips with counts and `aria-pressed`, search across
  title, client, medium and specs, grid and index views (index rows preview the
  poster on hover and focus), live count, empty state with "Clear filters".
- Detail: sticky poster, copy-to-clipboard palette swatches with toast, "Start a
  similar project" prefills the brief form, previous/next loop.
- Services: cards with "Request this" (prefills the project type), process
  steps, plus accordion (grid-rows height, `aria-expanded`), anchors from Home
  rows flash the matching card.
- Forms (brief, newsletter): labelled fields, inline errors with
  `aria-invalid`, an error summary, loading state, success panel that echoes the
  brief and says plainly that nothing was sent. Use `type="button"` plus click
  and Enter handlers, never native submit, in the single file.
- Copy buttons fall back to `execCommand('copy')` when `window.origin` is
  `'null'` (sandboxed iframe), and still show the toast.

### 7. Add motion with intent

Follow `references/motion-system.md`: the hero display word rises letter by
letter and the rest of the hero fades up within about 900 ms on load; scroll
reveals are guarded by `html.js` with an IntersectionObserver plus an
above-the-fold pass and a scroll safety net; route changes cross-fade; posters
lift on hover. Everything collapses to instant under reduced motion. No
bouncing, no cursor effects, no loops beside reading text (the availability dot
is the only repeating motion).

### 8. Icons

Use the sprite in `references/icon-library.md` (Lucide grammar, 24 viewBox,
`currentColor`, round caps). No emoji, dingbats or icon fonts. Icon-only buttons
get accessible names; decorative SVG is `aria-hidden`.

### 9. Validate

- Single file: `node scripts/inline-assets.mjs path/to/source.html path/to/index.html`,
  then `node scripts/validate-mono.mjs path/to/index.html`. It fails on remote
  requests, leftover `REPLACE` comments, broken routes and on any sample name
  from the template (Jonas Ferreira, the sample clients, project titles and
  slugs, address, domain). Fix every error; read every warning (stand-in
  images, placeholder domains) and carry it into your reply.
- Deployed site with `images/` and `fonts/` beside the page:
  `node scripts/validate-mono.mjs path/to/index.html --files` (local files must
  exist; remote fonts and sample leftovers still fail).
- `--template` checks the un-filled template, `--demo` the store demo.
- Framework output: run the project's type check and build. The HTML validator
  does not read framework source; verify routes, assets and rendered pages.

### 10. Review in a real browser

Open every route at 1440, 1024, 768 and 390 px (and inside
`<iframe sandbox="allow-scripts">` for the single file). Work through
`references/quality-checklist.md`: the display word on one line inside the
column, the portrait fade, poster shadows not clipped, poster type legible on
every crop (card, square, story, mini), no horizontal overflow, no console
errors, every control exercised (filter to empty, search, index view, invalid
then valid form, accordion, copy buttons, mobile menu with Esc and focus
return). Do at least two screenshot-and-fix passes.

### 11. Deliver

Report the output path, the framework, what was validated programmatically and
what was reviewed in the browser. List every placeholder fact you drafted
(clients, quotes, prices, dates, contact details) and every stand-in image
(generated portrait or artwork) for the designer to confirm or replace. Do not
claim deployment, publication or sent messages unless those actions really
happened.

## Adapting to a real brief

- **Counts flex; the grammar does not.** `PROJECTS` takes 4 to 16 records.
  The Home `.poster-grid` (four columns, two below 1024 px) shows the first
  eight: 4 or 8 fill whole rows; with 5 to 7 put the strongest first and
  accept a short last row. The Work index, filter counts, "Showing n of N",
  "Project n of N", previous/next and the footer list are computed.
  `CATEGORIES` lists only categories in use, every `cat` must be one of them,
  and each gets a `PREFILL_TYPE` entry. `SERVICES` 2 to 6 (`.svc-cards` is two
  columns, so 3 or 5 leave one card alone on its row); keep the form's project
  types equal to the service names. `TOOLS` 4 or 8 (`.tool-tiles` is a
  four-column grid), `PROCESS` 3 to 5, `FAQ` 3 to 6, `PATH` 2 to 6 rows,
  `.values` three cards. Copy that states a number ("Eight posters, eight
  briefs.", "Four ways to work together.", "see all eight") changes with it.
- **Map the sections to the designer.** Illustrator or brand designer without
  print runs: keep the 2:3 poster card as the artwork frame (landscape work:
  set `focus`, and `mount` for the square post), relabel the four `specs`
  rows (for example Format, Medium, Material, Edition; rows 1 to 3 are read as
  size, process and stock) and the toolkit tiles to their craft. Photographer:
  projects become series, "On the wall" an exhibition view. A studio of
  several people: the wordmark and name line carry the studio, the portrait is
  the founder or a group cut-out, Path becomes the studio's history, the voice
  becomes "we". No packaged services: fold process and FAQ into About and
  remove the Services page with its nav, sheet and footer links.
- **Real facts only.** For a real designer, clients, quotes, project briefs,
  outcomes, print runs, prices, dates, addresses and career path come from the
  brief. Anything missing is drafted as clearly plausible placeholder copy and
  listed in your final reply for the designer to confirm or replace. No
  invented awards, press, client logos, certifications or sales figures; if
  there is no real client quote, remove the Home quote block.
- **People photos.** The hero portrait is the designer: ask for a photo and
  give it the greyscale cut-out treatment in `references/image-plan.md`.
  `portrait-jonas.webp` is a generated stand-in for the sample designer; if you
  use it (or another generated portrait) until a photo arrives, say so in
  your reply.
- **Shipped images.** Reusable as a neutral placeholder: `studio.webp` (an
  empty black-and-white studio). Stand-in only: `portrait-jonas.webp`.
  Sample-specific, never shown as the buyer's work: the eight `poster-*.webp`
  (the sample designer's client posters) and the four `scene-*.webp`
  composites that show those posters in place. A portfolio shows the
  designer's own work: use their files; if they have none yet, generate new
  stand-ins per `references/image-plan.md`, composite them into new blank
  plates with `scripts/composite-in-place.py`, and list them in your reply.
- **Deliverable.** No existing project: the single HTML file built with
  `scripts/inline-assets.mjs`, like the store demo (fonts and images as data
  URIs, safe in a sandboxed preview). A normal deployed site may keep
  `images/` and the font files beside the page (validate with `--files`). A
  framework project, or a request for one: port per
  `references/framework-adaptation.md` with local image and font files.
- **The hero copy changes, its anatomy does not.** One display word that fits
  the column on one line (keep "Portfolio" or a short equivalent), the name,
  the role, two chips (city, availability) and two buttons; same 300 px
  portrait and 142 px scale. Nothing added.

## Replace checklist

Sample strings that sit outside the data arrays. The validator names any that
remain.

- `<title>`, meta description, OG tags and the `data-title` of every
  `data-page` section; `SITE` (name, email, phone, address, booking) and, if
  the collection route is renamed, `WORK`.
- Header and sheet wordmark (and its `aria-label`), the sheet contact line.
- Hero: portrait `src` and `alt`, the `aria-label` of the `h1`, name, role,
  chips.
- Home: about teaser, projects line, "On the wall" copy with its
  `data-insitu` slug and link, services line, the quote (person, role,
  `data-poster-mini` slug, project link).
- About: headline, lead, studio caption, bio, facts, "How I work", values,
  colophon.
- Work: headline, lead, search placeholder, empty-state hint, archive note.
- Services: headline, lead with the tax note, questions intro, the process
  photo's `data-insitu` slug.
- Contact: headline, lead, form placeholders (`Ana Morais`,
  `ana@venue.example`), project types, budget bands and currency, studio card
  lines and their `data-copy` values.
- 404 copy, CTA band in `ctaHTML()`, footer blurb, newsletter line, contact
  lines and `data-copy` values, copyright line; `PREFILL_TYPE`.

## Single-file constraints

The single-file deliverable (and the store demo) is one self-contained HTML
file, target 5 MB and hard cap 8 MB, with inline CSS, JS, fonts and images.
Sandbox restrictions apply when the page is previewed inside a sandboxed
iframe (a single-file demo): no network requests, no top navigation, no
dialogs, storage only inside try/catch with an in-memory fallback, no native
form submission. A deployed site or framework project does not need them.
Until a real backend is connected, the forms keep saying plainly that nothing
was sent.

<!-- reui:stack -->
#### Interface components come from ReUI (React outputs)

When the output is React or Next.js, every generic control in this design
(buttons, text fields, select, segmented choice, filter chips and view toggle,
accordion, mobile menu sheet, toast) is a [ReUI](https://reui.io) component
styled by this template's tokens. The single-file template implements the same
behaviour in vanilla HTML so the single-file output stays self-contained;
`references/reui-components.md` maps each template control to its ReUI component.

- Install from the official registry (`npx shadcn@latest add @reui/button`,
  and so on) and import from your `components/ui` directory. The component
  source also lives at https://github.com/keenthemes/reui.
- Do not substitute a native `<select>`, a hand-rolled popover or a `div` with
  matching class names in a React output. If a control needs behaviour ReUI does
  not provide, build it explicitly and say so.
- Style through tokens, not forks: point ReUI's custom properties (`--primary`,
  `--background`, `--border`, `--radius`, font family) at this palette and keep
  the template's class names so its CSS still applies.
- In a non-React stack, check ReUI's real support before promising it. Astro can
  mount React islands; Vue or Svelte cannot use ReUI directly, so use the
  template's vanilla behaviour or raise the conflict instead of switching stacks.
<!-- /reui:stack -->