Website Concept Architect

Pre-code concept design for personal sites, portfolios, and landing pages. This skill produces direction, not markup. The deliverable is a small set of distinct concept docs the user picks from; the chosen one feeds ui-ux-architect for implementation.

When to use

User is starting a new website and wants to decide what it is before writing code. Not for redesigns of working sites unless the brief is "rethink from scratch". Not for component-level UI decisions — those belong to ui-ux-architect.

1. Operating principle — walk, don't dump

Run the six stages interactively, one at a time. After each stage, present the menu, pause, wait for the user's pick, then advance. Never collapse multiple stages into a single question. Never skip stages even if the user volunteers info — surface what they said as a pre-selected default and confirm.

The point of the walk is to force decisions the user would otherwise defer. Skipping a stage means a vague concept doc later.

2. The six stages

3. Stage 1 — Purpose

Present these archetypes. User picks 1-2 (combinable, e.g. portfolio + writing hub):

• Portfolio / showcase — work artifacts are the point; projects are the spine of the IA.
• Writing hub — essays / blog / notes are the spine; everything else is navigation.
• Professional calling card — single-page or near-single-page; recruiters / clients land, learn, contact.
• Digital garden — evergreen interlinked notes; structure is the network, not chronology.
• Project launcher — a specific product or project is the hero; "about me" is a footnote.
• Experimental playground — site is itself a creative artifact; convention is the enemy.

If user picks 2 incompatible archetypes (e.g. experimental playground + professional calling card), flag it and ask which wins on the homepage — the loser becomes a subsection.

4. Stage 2 — Audience

Picks shape how much explanation things need and what voice fits.

• Recruiters / clients — fast skim, credentials-first, low jargon, contact obvious.
• Fellow devs / peers — assumes shared vocab, tolerates density, code samples land.
• Friends / community — informal, personality-forward, in-jokes OK.
• Future-you / archive — built for searching your own past, density over polish.
• The open web — generic visitor, must self-explain, SEO matters.

Multi-audience is normal. If they pick 3+, ask which one the homepage is optimized for — the rest get accommodated on subpages.

5. Stage 3 — Content inventory

Present this menu. User checks what they want; offer to add custom items.

Standard sections:

• About / bio
• Now page (what you're focused on right now)
• Projects index
• Individual project case studies
• Essays / blog / writing
• Notes / digital garden / wiki
• Reading list / bookshelf
• Uses page (tools, hardware, setup)
• Resume / CV (or link to PDF)
• Contact (email, social, form)
• Newsletter signup
• RSS / Atom feed
• Changelog (site or life updates)
• Photo gallery
• Talks / podcasts / appearances
• Guestbook / webring (retro-web aesthetic)

For each picked section, ask one follow-up: does this exist yet? Sections without content get marked [deferred] in the concept doc so the user doesn't ship empty pages.

6. Stage 4 — Tone & personality

Pick 2-3 adjectives. These anchor stage 5's visual suggestions and stage 6's copy voice.

Present as opposing pairs so picks force tradeoffs:

• minimal ↔ dense
• playful ↔ serious
• warm ↔ clinical
• raw ↔ polished
• intimate ↔ public
• experimental ↔ conventional
• fast / scannable ↔ contemplative / long-form
• confident ↔ self-deprecating

A user who picks minimal + playful + warm gets very different suggestions than dense + serious + clinical. Record the picks verbatim — they go into the concept doc as the brief.

7. Stage 5 — Visual direction

Eight archetypes. Rank the top 3 by fit based on stages 1-4, but show the full list so the user can override.

Show the ranking with one-sentence rationale per pick, e.g. "Terminal/CLI fits because you picked dev audience + minimal + raw." User picks one; if they override the ranking, ask why and record it (the override often reveals a constraint not surfaced earlier).

8. Stage 6 — Synthesis

Produce 2-3 distinct concept directions, not one. Even if the user is decided, alternatives expose what they're trading off.

Concept doc shape

For each direction, write a markdown doc with these sections:

# Concept: <name>

## One-line pitch
<the site in 15 words or fewer>

## Brief
- Purpose: <stage 1 picks>
- Audience: <stage 2 picks, primary first>
- Tone: <stage 3 adjectives>
- Visual archetype: <stage 5 pick>

## Information architecture
<tree of pages/sections, max 2 levels deep>

## Homepage strategy
<what the homepage does in 2-3 sentences — first impression, primary action, what the visitor leaves knowing>

## Sample copy voice
<2-3 sentences in the chosen voice — about section opener, or homepage tagline + subhead>

## What this concept sacrifices
<honest list of what's deprioritized vs. the other concepts — every concept trades something>

## Ascii homepage wireframe
<see §9>

The three directions should differ on a real axis, not be cosmetic variants:

• Concept A = the obvious read of the user's picks
• Concept B = optimizes harder for the primary audience (often more minimal)
• Concept C = a deliberate stretch — what if the experimental dial went one click further?

If two of the three end up nearly identical, drop one and explain why.

9. ASCII homepage wireframe

One per concept. Keep it 80 cols wide, label regions in [BRACKETS]. Show hierarchy with box-drawing or simple dashes.

Example for a terminal/CLI portfolio:

+------------------------------------------------------------------------------+
| ~ ramon.dev                                              [now] [writing] [/] |
+------------------------------------------------------------------------------+
|