docs: establish approved Phase 1 design + Phase 2 spec as project foundation
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
cesnimda
@@ -0,0 +1,91 @@
|
||||
# DESIGN_RESEARCH.md
|
||||
Portfolio Redesign — Phase 1 Research
|
||||
Connor Babbington · cesnimda.co.uk · July 2026
|
||||
|
||||
---
|
||||
|
||||
## 1. Audit of the existing site
|
||||
|
||||
**Current state:** WordPress + Avada (Fusion Builder) single-page site. Sections: Hero → About → Proficiencies → Experience → Projects → CV downloads → Contact form.
|
||||
|
||||
### What works
|
||||
- The content skeleton is correct: summary, skills, experience, projects, CV, contact — everything a recruiter needs exists somewhere.
|
||||
- Clear availability statement ("open to remote, hybrid, on-site") in the first viewport.
|
||||
- Both CV languages are downloadable from the hero.
|
||||
|
||||
### What fails against the goal ("decide to interview me")
|
||||
| Problem | Evidence | Impact |
|
||||
|---|---|---|
|
||||
| **Generic template look** | Avada theme, stock section headings ("About.", "Let's Talk.") | A hiring manager evaluating a *software engineer* sees a page-builder site — it signals "assembled", not "engineered". The single strongest negative signal on the current site. |
|
||||
| **No proof, only claims** | Skills are bare word-lists; experience is one paragraph; projects have no screenshots, no links, no architecture, no outcomes | Recruiters can't verify; engineers can't assess depth. Nothing differentiates from 10,000 similar CVs. |
|
||||
| **Projects undersold** | Job Tracker gets 2 sentences; InboxIntel absent entirely | These two projects are the *strongest* seniority evidence available (multi-service architecture, OAuth, AI integration, Docker, testing, security hardening) and they're invisible. |
|
||||
| **English only** | `lang="en-GB"`, no Norwegian content | Candidate lives in Tønsberg targeting the Norwegian market; a Norwegian hiring manager gets zero accommodation. Bokmål content is also a trust and effort signal ("aktiv språkutvikling" made visible). |
|
||||
| **Heavy, slow stack** | WP + Avada + W3TC minified bundles, lazyload shims | Poor Core Web Vitals undercut the "production-level thinking" message. The site itself should be a work sample. |
|
||||
| **No dark mode, no motion design, no personality** | Static template sections | Feels dated next to any modern product site. |
|
||||
| **Weak SEO/meta** | Empty `og:title`, description is a raw text dump of the hero | Sloppy details on the most detail-oriented artifact a developer publishes. |
|
||||
|
||||
**Conclusion:** the redesign is not a reskin — the site must *become the work sample*: fast, precise, bilingual, with projects presented as engineering case studies.
|
||||
|
||||
---
|
||||
|
||||
## 2. What makes engineer portfolios convincing (pattern research)
|
||||
|
||||
Synthesised from high-performing engineer portfolios (e.g. the genre exemplified by Brittany Chiang, Lee Robinson, Josh Comeau, Rauno Freiberg) and product marketing sites (Stripe, Linear, Vercel, Notion, Framer):
|
||||
|
||||
### Convincing signals
|
||||
1. **Specificity beats adjectives.** "Reduced manual spreadsheet workflows for a county council" beats "passionate problem-solver". Numbers, stack names, and constraints read as experience.
|
||||
2. **Case studies, not thumbnails.** Portfolios that convert treat projects like product launches: problem → approach → architecture → decisions/trade-offs → outcome → screenshots. Engineers hiring engineers read the *trade-offs* section first.
|
||||
3. **The site itself is evidence.** Fast load, keyboard access, tasteful motion, working dark mode, correct typography — hiring managers notice these subconsciously; senior ones notice consciously.
|
||||
4. **Restraint reads as seniority.** Junior portfolios over-animate. The Linear/Stripe lesson: one or two signature moves, executed perfectly, on a quiet base.
|
||||
5. **Low-friction verification.** CV download, LinkedIn, e-mail, code links reachable within one interaction from anywhere on the page.
|
||||
6. **A human face.** A real photo near the top measurably increases trust and recall; recruiters match the site to the LinkedIn profile.
|
||||
|
||||
### What makes visitors leave
|
||||
- Walls of unscannable text (recruiters scan, engineers skim then deep-read).
|
||||
- "Skills: HTML, CSS, JavaScript…" laundry lists with no context or proficiency framing.
|
||||
- Broken/missing project links, placeholder content, lorem-tier copy.
|
||||
- Slow first paint; janky scroll-hijacking; autoplaying anything.
|
||||
- No way to answer "can this person do *my* job?" within ~30 seconds.
|
||||
|
||||
### SaaS landing-page techniques worth borrowing (not copying)
|
||||
| Site | Technique to adapt |
|
||||
|---|---|
|
||||
| **Stripe** | Dense-but-calm information design; gradient used as a single identity moment, not everywhere; impeccable code-adjacent typography. |
|
||||
| **Linear** | Dark-first palette; short declarative sentences; motion only on state change; keyboard-first affordances. |
|
||||
| **Vercel** | Monochrome + one accent; triangle-precision spacing; "proof strip" (logos/metrics) directly under the hero. |
|
||||
| **Notion** | Friendly humanity inside a rigid grid; illustration used sparingly to soften. |
|
||||
| **Framer** | Scroll-linked reveals that never block reading; hero that demonstrates the product (here: the site demonstrates the engineer). |
|
||||
|
||||
---
|
||||
|
||||
## 3. Recruiter & hiring-manager evidence base
|
||||
|
||||
(Expanded in RECRUITER_BEHAVIOUR_ANALYSIS.md.)
|
||||
|
||||
- **Time budget:** eye-tracking studies of recruiters (Ladders, 2018) put initial CV scan at **~7.4 seconds**. A portfolio gets slightly more — roughly 20–50 seconds before a stay/leave decision — but the first viewport carries the decision.
|
||||
- **Scan pattern:** F-pattern / layered scanning (Nielsen Norman Group): name → title → location/availability → most recent role → skills. Layout must place these on the F.
|
||||
- **What they screen for:** role fit keywords, seniority, location/work-permit, availability, red flags (gaps, vagueness). The hero must answer: *who, what level, what stack, where, available?*
|
||||
- **Two-audience problem:** recruiters (non-technical, 30s, checklist-driven) and engineering managers/CTOs (technical, 3–10 min, depth-driven) visit the same URL. The IA must serve a **fast lane** (scannable hero + skills + CV button) and a **deep lane** (case studies, architecture, decisions) without either blocking the other.
|
||||
- **Norway-specific:** Norwegian hiring culture values understatement, concrete competence claims (jf. *janteloven* — avoid grandiosity), and language effort. "Norsk A2/B1, i aktiv utvikling" stated plainly is a positive signal, not a weakness to hide. Work-permit clarity ("gyldig oppholdstillatelse") removes the #1 recruiter objection for foreign candidates.
|
||||
|
||||
---
|
||||
|
||||
## 4. Accessibility baseline (non-negotiable, also a seniority signal)
|
||||
|
||||
- WCAG 2.2 AA: contrast ≥ 4.5:1 body text (≥ 3:1 large text/UI), visible focus states, target size ≥ 24px.
|
||||
- Full keyboard operability including the language switch and theme toggle.
|
||||
- `prefers-reduced-motion` honoured by *every* animation (motion system must define reduced variants, not just "off").
|
||||
- Semantic landmark structure; skip-link; alt text strategy for project screenshots.
|
||||
- Language correctness: `lang` per locale, `hreflang` alternates — this doubles as SEO.
|
||||
|
||||
---
|
||||
|
||||
## 5. Strategic conclusions → design brief
|
||||
|
||||
1. **Reposition the site as a product.** Name the artefact: it is "Connor Babbington — systems developer" presented with the craft of a SaaS launch page.
|
||||
2. **Projects become the centre of gravity.** Two full case studies (JobTrack, InboxIntel) + an infrastructure/homelab capability page. Each with architecture diagram, screenshots, decisions, and honest "what I'd improve".
|
||||
3. **Two-lane IA.** 30-second lane: hero → proof strip → skills → CV. 10-minute lane: case studies → experience → about.
|
||||
4. **Bilingual as a feature, not a toggle afterthought.** Norwegian content is written (not machine-mirrored), the switch is visible in the header, and URLs are language-scoped.
|
||||
5. **Honest seniority framing.** The CV says "mid-level, 8 years". The site should not claim "senior" in a title; it should *demonstrate* senior judgement (trade-off writing, production thinking, security notes) and use the framing "systems developer, 8+ years". Evidence over adjectives — this is also the safest posture for the Norwegian market.
|
||||
6. **Performance is part of the design.** The visual system is deliberately light: system-adjacent type stacks, no hero video, SVG-first graphics, motion via transform/opacity only.
|
||||
7. **The design direction is defined in DESIGN_SYSTEM.md as "Kontrollrom / Quiet Console"** — a Nordic-restrained, dark-first engineering aesthetic with a single aurora-teal accent and monospace metadata as its identity move. Unique, ownable, and cheap to render.
|
||||
@@ -0,0 +1,62 @@
|
||||
# RECRUITER_BEHAVIOUR_ANALYSIS.md
|
||||
How recruiters and hiring managers actually behave on candidate sites — and the design responses.
|
||||
|
||||
---
|
||||
|
||||
## 1. The decision funnel
|
||||
|
||||
```
|
||||
Application / LinkedIn / referral
|
||||
│ (click, if the link looks worth it)
|
||||
▼
|
||||
First viewport ······· ~5–10 s → stay or bounce
|
||||
▼
|
||||
Scan pass ············ ~20–45 s → "worth shortlisting?"
|
||||
▼
|
||||
Depth pass (technical) ~3–10 min → "worth interviewing?"
|
||||
▼
|
||||
CV download / e-mail / forward to hiring manager
|
||||
```
|
||||
|
||||
Each stage has different owners: the scan pass is usually a recruiter; the depth pass an engineering manager. **The same page must pass both.**
|
||||
|
||||
## 2. Evidence & observed patterns
|
||||
|
||||
1. **~7.4 seconds** median initial CV scan (Ladders eye-tracking, 2018). Web pages get marginally more, but the fixation order is stable: **name → title → location → recent employer → dates → skills**. Design response: those six items are literally the hero and proof strip, in that order.
|
||||
2. **F-pattern scanning** (NN/g): two horizontal sweeps near the top, then a vertical skim down the left edge. Design response: left-align key nouns; front-load sentences; section labels in the left rail on desktop; never bury critical facts mid-paragraph or right-aligned.
|
||||
3. **Layer-cake scanning:** on well-structured pages, scanners read *headings only*. Design response: headings must carry the argument alone. Test: read only the H2/H3s — do they say "experienced .NET/full-stack developer in Norway with production evidence, available now"? Ship only if yes.
|
||||
4. **Checklist screening:** recruiters screen *out* before they screen in. Top objections for this candidate profile: (a) work permit / right to work in Norway, (b) language, (c) seniority mismatch, (d) unverifiable claims. Design response: kill all four above the fold — permit ✓, "English native / Norsk B1" ✓, "8+ yrs" ✓, links to real running systems ✓.
|
||||
5. **Mobile share is significant** for first visits from LinkedIn (often 40–60%). Design response: mobile hero carries identical decision-facts; CV download works on phone (and the CV itself is ATS-parseable — see CONTENT_STRATEGY §6).
|
||||
6. **Trust markers ranked** (approximate weighting for a mid/senior dev profile):
|
||||
- Real employer names + durations ●●●
|
||||
- Screenshots of real, running software ●●●
|
||||
- Face photo matching LinkedIn ●●
|
||||
- Code/architecture detail ●● (hiring managers)
|
||||
- Domain + professional e-mail ●
|
||||
- Testimonials ○ (low value unless verifiable — omit rather than fake)
|
||||
7. **Exit triggers:** template look, broken links, "under construction", walls of text, unlabeled skill bars ("JavaScript 80%" — meaningless, reads junior), autoplay, scroll hijack, pop-ups.
|
||||
|
||||
## 3. The two-lane rule (governing IA principle)
|
||||
|
||||
- **Fast lane (P1/P3):** hero → proof strip → skills matrix → CV/contact. Complete in ≤ 45 s without a single click. Every fact scannable, nothing interactive required.
|
||||
- **Deep lane (P2/P4):** project case studies and experience detail, one click away, each readable in 3–5 minutes with skimmable structure (headings carry the argument; diagrams before prose).
|
||||
- Lanes must not interleave: no case-study prose on the homepage beyond a 2-line teaser; no marketing fluff inside case studies.
|
||||
|
||||
## 4. Norway-market specifics
|
||||
|
||||
- **Understatement wins.** "Senior rockstar ninja" framing actively harms with Norwegian evaluators. Use concrete competence statements: "Åtte års erfaring med systemutvikling i britisk offentlig sektor."
|
||||
- **Public sector experience is an asset** — Warwickshire County Council maps mentally to kommune/fylkeskommune IT. Frame it that way in Norwegian copy.
|
||||
- **Language effort is a first-class signal.** A natively-written Bokmål site says more than "Norwegian: B1" ever can. Never machine-mirror; write shorter, plainer Norwegian rather than translated English sentence structures.
|
||||
- **Practicalities beat charisma:** permit, location (Tønsberg — commutable to Oslo south corridor, Horten, Sandefjord tech), remote readiness, start availability.
|
||||
|
||||
## 5. Measurable success criteria for the design (Phase 1 acceptance)
|
||||
|
||||
| # | Criterion | Test |
|
||||
|---|---|---|
|
||||
| 1 | Identity, role, stack, location, permit, availability all visible in first desktop viewport (1440×900) and first two mobile screens | Mockup review |
|
||||
| 2 | Headings alone tell the hire story | Read H-tags only |
|
||||
| 3 | CV (correct language) reachable in ≤ 1 interaction from any scroll position | Mockup review |
|
||||
| 4 | A technical reader can find an architecture diagram in ≤ 2 clicks | Journey walkthrough |
|
||||
| 5 | Language switch discoverable in ≤ 5 s, state obvious | Mockup review |
|
||||
| 6 | Nothing moves without user intent except one hero identity moment (≤ 800 ms, reduced-motion safe) | Motion spec |
|
||||
| 7 | All text ≥ 4.5:1 contrast in both themes | Colour system audit |
|
||||
@@ -0,0 +1,55 @@
|
||||
# USER_PERSONAS.md
|
||||
Four personas drive every layout and content decision. Each has a *time budget*, a *question they must answer*, and a *conversion action*.
|
||||
|
||||
---
|
||||
|
||||
## P1 — "Silje", Tech Recruiter (agency or in-house), Oslo/Vestfold
|
||||
- **Context:** Screening 40+ profiles today. Found the site via LinkedIn or an application link. Likely on desktop, possibly mobile between meetings. Norwegian native; reads English fine but a Norwegian option signals local commitment.
|
||||
- **Time budget:** 20–45 seconds.
|
||||
- **Technical depth:** Low. Matches keywords to a job spec.
|
||||
- **Must answer:** Right title? Right stack keywords (C#, .NET, React, Docker)? Located where? Work permit? Available? Language level? CV downloadable?
|
||||
- **Conversion action:** Download CV (correct language) or copy e-mail/LinkedIn into ATS.
|
||||
- **Design implications:** Hero states role, stack, location, permit and availability *in text* (not images). CV buttons persistent (hero + sticky nav + footer). Norwegian toggle prominent. Phone-friendly one-thumb layout.
|
||||
- **Failure mode:** Any ambiguity about location/permit → skip candidate.
|
||||
|
||||
## P2 — "Martin", Engineering Manager, product company (Oslo/remote-EU)
|
||||
- **Context:** Recruiter shortlisted Connor; Martin has 5 minutes between meetings to decide interview/no-interview. Desktop, probably dark-mode IDE person.
|
||||
- **Time budget:** 3–7 minutes.
|
||||
- **Technical depth:** High. Reads architecture, judges trade-offs, opens dev tools out of habit.
|
||||
- **Must answer:** Can he build and *operate* real systems? Does he test? Does he think about security and maintenance? Will he communicate well with stakeholders?
|
||||
- **Conversion action:** Skim one case study end-to-end → recommend interview; possibly click through to code.
|
||||
- **Design implications:** Case studies with architecture diagrams, decision/trade-off sections, testing & security notes, honest "known limitations". Site performance and a11y are silent evidence. Metadata in monospace, correct semantics — he *will* view source.
|
||||
- **Failure mode:** Claims without proof; a slow template site ("if the portfolio is Avada, what will the codebase be?").
|
||||
|
||||
## P3 — "Anne", CTO / Head of IT at a Norwegian SME or kommune-adjacent supplier
|
||||
- **Context:** Small team, hires rarely, values dependability over rockstar energy. Found via application. Reads Bokmål by preference.
|
||||
- **Time budget:** 2–5 minutes, often on the Norwegian version.
|
||||
- **Technical depth:** Medium-high, but evaluates *risk*: will this person maintain legacy systems, talk to users, stay?
|
||||
- **Must answer:** Public-sector experience? Boring-technology competence (SQL, .NET, servers)? Stability and communication? Settled in Norway?
|
||||
- **Conversion action:** Read About + Experience → forward to colleague → invite to interview.
|
||||
- **Design implications:** Warwickshire County Council experience framed as *public-sector systems work* (highly relevant in NO). Understated tone (janteloven-compatible). Norwegian copy natively written, not translated-sounding. "Bosatt i Tønsberg, gyldig oppholdstillatelse" visible.
|
||||
- **Failure mode:** Grandiose self-labels, hype language, English-only.
|
||||
|
||||
## P4 — "Priya", Senior Engineer doing interview-loop prep (secondary persona)
|
||||
- **Context:** Interview is booked; she's preparing questions from his projects. Deep-reads one case study.
|
||||
- **Time budget:** 10+ minutes.
|
||||
- **Must answer:** What exactly did he build? Where are the interesting decisions to probe?
|
||||
- **Conversion action:** Arrives at interview with informed, favourable questions.
|
||||
- **Design implications:** Case studies must be accurate and honest — everything on the page is fair game in an interview. "What I'd do differently" sections turn probing questions into prepared wins.
|
||||
|
||||
---
|
||||
|
||||
## Persona → priority matrix
|
||||
|
||||
| Section | P1 Recruiter | P2 Eng Manager | P3 CTO (NO) | P4 Engineer |
|
||||
|---|---|---|---|---|
|
||||
| Hero (role/stack/location/permit) | ●●● | ●● | ●●● | ● |
|
||||
| Skills matrix | ●●● | ●● | ●● | ● |
|
||||
| CV download | ●●● | ● | ●● | ● |
|
||||
| Case studies | ● | ●●● | ●● | ●●● |
|
||||
| Experience timeline | ●● | ●● | ●●● | ● |
|
||||
| About (human) | ● | ● | ●●● | ● |
|
||||
| Contact | ●●● | ●● | ●●● | ● |
|
||||
| Norwegian locale | ●● | ○ | ●●● | ○ |
|
||||
|
||||
**Reading:** The homepage top half serves P1/P3; the middle and project pages serve P2/P4. Nothing P2 needs may push P1's answers below the fold.
|
||||
Reference in New Issue
Block a user