# Website Concept Architect > Walk the user through designing a website concept before any code — purpose, audience, content inventory, tone, visual archetype, structure — and output 2-3 distinct concept directions plus an ASCII homepage wireframe. Use when planning a new personal site, portfolio, or marketing page upstream of implementation. Hands off to ui-ux-architect / frontend-design. - Skill: `ralvarezdev/website-concept-architect` (Agent Skill) - Install (CLI): `npx skillmds@latest add ralvarezdev/website-concept-architect` - Raw SKILL.md: https://api.skillmd.com/api/skills/ralvarezdev/website-concept-architect/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Marketing & Growth - Author: ralvarezdev (https://skillmd.com/u/ralvarezdev) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/ralvarezdev/website-concept-architect --- # 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](../ui-ux-architect/SKILL.md) 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 | # | Stage | Purpose | Output | |---|-------|---------|--------| | 1 | Purpose | What is the site *for*? | 1-2 picks from archetype list | | 2 | Audience | Who reads it? | 1-2 picks, drives tone & density | | 3 | Content inventory | What lives on it? | Checked menu of sections | | 4 | Tone & personality | How does it feel? | 2-3 adjectives from curated list | | 5 | Visual direction | What does it look like? | 1 archetype (ranked suggestions, full list shown) | | 6 | Synthesis | Concept docs | 2-3 distinct concept directions + ASCII wireframe | ## 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. | Archetype | Feel | Fits when stages 1-4 say... | Reference sites | |-----------|------|------------------------------|------------------| | **Terminal / CLI** | monospace, sparse, command-line | dev audience, minimal, raw, archive | sive.rs, wiki.nikiv.dev, ratfactor.com | | **Editorial / Swiss** | strong type, grid, generous whitespace | polished, serious, professional calling card | rauno.me, paco.me, linear.app | | **Brutalist** | raw HTML, default styles, no chrome | experimental, raw, intimate, dev audience | brutalist-web.design, motherfuckingwebsite.com | | **Zine / maximalist** | collage, mixed fonts, layered textures | playful, experimental, community audience | cassie.codes, lynnandtonic.com | | **Minimalist portfolio** | single column, big images, lots of whitespace | portfolio, polished, recruiters/clients | many designer portfolios | | **Notebook / garden** | wiki-like, dense interlinks, evergreen | digital garden, archive audience, dense | gwern.net, andymatuschak.org | | **Magazine / story** | long-scroll narrative, art-directed, hero imagery | project launcher, contemplative, open web | pitchfork.com long-reads, the verge features | | **Database / index** | filterable table, almost a UI | dense, archive, lots of artifacts | are.na profiles, derek sivers' /now directory | 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: ```markdown # Concept: ## One-line pitch ## Brief - Purpose: - Audience: - Tone: - Visual archetype: ## Information architecture ## Homepage strategy ## Sample copy voice <2-3 sentences in the chosen voice — about section opener, or homepage tagline + subhead> ## What this concept sacrifices ## Ascii homepage wireframe ``` 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] [/] | +------------------------------------------------------------------------------+ | | | ramon alvarez | | go developer · tooling · personal CLIs | | | | > currently building rsk, a skill management CLI for claude code | | | | --- recent ---------------------------------------------------------- | | 2026-05-18 shipped: ralvaskills v0.3 | | 2026-05-02 essay: why I bundle skills as one repo | | 2026-04-21 project: rsk cli infrastructure | | | | --- projects -------------------------------------------------------- | | ralvaskills personal AI skills toolkit [→] | | rsk cli for managing skills [→] | | | +------------------------------------------------------------------------------+ | email · github · rss | +------------------------------------------------------------------------------+ ``` Wireframes are about **proportion and hierarchy**, not pixel layout. No colors, no fonts, no icons beyond ASCII. If a section needs explanation, add a one-line note *below* the wireframe, not inside it. ## 10. Anti-patterns - **Skipping stages because "the user already said".** Surface their input as a default and confirm; don't assume. Half the value is forcing the user to look at what they didn't say. - **One concept doc instead of 2-3.** Alternatives are how the user understands what they're choosing. Single-concept output is a failed run. - **Visual archetype before tone is locked.** Stage order matters — visual is downstream of purpose/audience/tone, not parallel. - **Filling in content for `[deferred]` sections.** If the user hasn't written the essays, don't invent topic lists — the concept doc commits to *structure*, not *content*. - **Wireframes with implementation details.** No "use shadcn Card here" — that's ui-ux-architect's job. Wireframes show what goes where. - **Generic suggestions.** "A clean modern portfolio" is not a concept. Every concept doc must commit to specific picks on every axis. ## 11. Hand-off Once the user picks one of the 2-3 concepts, the concept doc is the brief for: - [ui-ux-architect](../ui-ux-architect/SKILL.md) — for tokens, components, accessibility, the four required states. - Built-in `frontend-design` skill — for the actual code if going production-grade. The concept doc should be saved to the project repo (e.g. `docs/concept.md`) so it survives as the design rationale. ## 12. Cross-skill ties - [ui-ux-architect](../ui-ux-architect/SKILL.md) — implementation-level standards; this skill feeds it the brief. - [demo-presentation-architect](../../personal/demo-presentation-architect/SKILL.md) — similar interactive walk-through structure, different domain. - [demo-script-architect](../../personal/demo-script-architect/SKILL.md) — narrative principles (audience-first, progressive reveal) apply to homepage copy too.