Files
ResumeSite/docs/design/01-research/USER_PERSONAS.md
T
2026-07-03 21:07:25 +02:00

56 lines
4.4 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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:** 2045 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:** 37 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:** 25 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.