Files

T

cesnimda 1f695d3932 docs: establish approved Phase 1 design + Phase 2 spec as project foundation

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

2026-07-03 21:07:25 +02:00

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.

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?").

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.

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.

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.