**PRODUCT REQUIREMENTS DOCUMENT** **Personal Portfolio Website** Godsfavour Okpara Project Manager | Product Manager | Scrum Master Document status: Draft v1.0 — Developer-ready Prepared for: Development team Content note: text in [brackets] is a placeholder. Final professional content (bio, project details, case studies, images, CV) will be supplied separately by the site owner and must be treated as swappable data, not hard-coded copy. # Table of Contents 1. Product Overview 2. Product Vision 3. Objectives 4. Target Users 5. Core User Journey 6. Information Architecture 7. Functional Requirements 8. Non-Functional Requirements 9. Homepage Requirements 10. Project Portfolio System 11. Case Study System 12. Experience System 13. About Page 14. Skills System 15. Certifications 16. Insights / Articles System 17. Recommendations / Testimonials System 18. Booking System 19. Contact Experience 20. CV Functionality 21. Design Direction 22. Design System Requirements 23. Content Architecture 24. UX Requirements (Cross-Cutting) 25. Responsive Requirements 26. Accessibility 27. Performance 28. SEO 29. Analytics 30. Security 31. Confidentiality 32. Technical Architecture 33. Error / Empty States 34. Acceptance Criteria 35. Definition of Done Appendix A — Content Provided Separately by Owner # 1. Product Overview This project delivers a personal portfolio and personal-brand website for Godsfavour Okpara, positioning her as a Project Manager, Product Manager, and Scrum Master who brings structure to ambiguous work, aligns cross-functional teams, and delivers outcomes. The site is not a digital CV. It is a credibility and evidence platform: a place where recruiters, hiring managers, founders, and product/technology leaders can quickly understand who she is, see evidence of delivery, and take action (download CV, view case studies, make contact). This document defines what the developer builds — architecture, structure, components, behaviour, and systems. It does not define final written content, which will be supplied separately and dropped into the structures defined here. # 2. Product Vision A modern, credible, content-driven portfolio platform that clearly communicates professional identity and value within seconds of landing; demonstrates delivery capability through structured project and case-study evidence, not just claims; scales cleanly as new roles, projects, certifications, and articles are added over time, without redesign; and feels intelligent, human, and premium — never templated, never a "developer portfolio" aesthetic, never a résumé pasted into HTML. # 3. Objectives | **#** | **Objective** | **Success Signal** | |---|---|---| | 1 | Establish strong, credible professional presence | Positive qualitative feedback from recruiters/peers | | 2 | Support PM/Product/Scrum job & consulting opportunities | Inbound contact form submissions, CV downloads | | 3 | Demonstrate real delivery evidence via case studies | Case-study view depth / time on page | | 4 | Make CV instantly accessible | CV download conversion from key CTAs | | 5 | Make contact frictionless | Contact form completion rate | | 6 | Support long-term content growth (projects, articles) | Content can be added without a developer | # 4. Target Users Primary personas the experience must be designed around: ### Recruiters Need speed: identity, role, experience, skills, certifications, CV, contact — scannable in under a minute. ### Hiring Managers Need evidence: ownership, problem-solving, delivery, product thinking, stakeholder management, Agile/Scrum capability, technical fluency, outcomes. ### Founders / Business Owners Need relevance: what she solves, what kinds of problems she structures, and a fast path to contact. ### Product / Technology Leaders Need depth: product thinking, prioritisation, requirements discovery, cross-functional collaboration, and technical literacy, evaluated through case-study substance. Design and content structures below must satisfy all four personas without forcing any of them to dig. # 5. Core User Journey **Understand → Explore → Validate → Connect** Land on site ↓ Understand who Godsfavour is (identity + positioning) ↓ Understand what she does and the value she brings ↓ See evidence of her work (Selected Work / Projects) ↓ Explore case studies in depth ↓ Validate via Experience, Skills, Certifications ↓ Download CV or Connect ↓ Contact Design principle: every page must independently make the case. A visitor should be able to arrive on any single page (e.g. a shared case-study link) and still understand her value without navigating the whole site first. # 6. Information Architecture ## 6.1 Sitemap (minimum required) - Home ( / ) - About ( /about ) - Experience ( /experience ) - Projects ( /projects ) - Project / Case Study detail ( /projects/[slug] ) - Skills ( /skills — or integrated section, see §14 ) - Certifications ( /certifications — or integrated section ) - Insights ( /insights ) - Article detail ( /insights/[slug] ) - Recommendations ( integrated section on Homepage/About, or /recommendations if volume warrants a dedicated page — see §17 ) - Booking ( /book, or an embedded booking widget on Contact and/or Homepage — see §18 ) - Contact ( /contact ) - 404 ( /404 ) ## 6.2 Primary Navigation Home · About · Experience · Projects · Insights · Contact, with a persistent "Download CV" action distinct from the nav links (button-styled, not a text link). ## 6.3 Persistent CTAs - Download CV — visible in header on all breakpoints. - Let's Connect / Contact — visible in header or as a floating/sticky action on scroll for long pages (case studies, articles). ## 6.4 Mobile Navigation Collapsible hamburger menu; CV download and Contact remain reachable within one tap (do not bury inside the hamburger only — consider a persistent CTA bar). ## 6.5 Footer Navigation Full sitemap links, professional identity (name/tagline), social/contact links (LinkedIn, email), CV download, copyright. ## 6.6 Internal Linking - Homepage "Selected Work" cards → individual case studies. - Case studies → "Related Projects" and back to Projects listing. - Experience entries → linked major projects where applicable. - Articles → related articles by category/tag. ## 6.7 Breadcrumbs Use on Project detail and Article detail pages: Home / Projects / [Project Name] and Home / Insights / [Article Title]. Not required on top-level pages. # 7. Functional Requirements This section consolidates every functional capability the developer must build, as a single checklist. Each requirement is elaborated in full in the section referenced — this table exists so nothing gets missed during build or QA. | **ID** | **Requirement** | **Detailed in** | |---|---|---| | FR-01 | Homepage presents identity, positioning, capabilities, featured work, and primary conversion CTAs | §9 | | FR-02 | Project listing with filtering, sorting, featured status, and empty state | §10 | | FR-03 | Reusable, section-flexible case-study template per project | §11 | | FR-04 | Experience timeline/card system with linked projects and tools | §12 | | FR-05 | About page with structured, human narrative content blocks | §13 | | FR-06 | Categorised skills system (no misleading proficiency graphics) | §14 | | FR-07 | Certification component with credential verification links | §15 | | FR-08 | Insights/articles system with categories, tags, and related content | §16 | | FR-09 | Recommendations/testimonials system with attribution and sourcing | §17 | | FR-10 | Booking system allowing visitors to schedule a call directly | §18 | | FR-11 | Contact form with validation, spam protection, and full state handling | §19 | | FR-12 | CV download available from five persistent locations, replaceable without redeploy | §20 | | FR-13 | All content (Projects, Experience, Certifications, Articles, Recommendations, Booking config) managed through a structured, decoupled content source | §23 | | FR-14 | 404 page and graceful empty states across every listing/filter | §33 | # 8. Non-Functional Requirements Non-functional requirements define the quality bar the build must meet, independent of any single feature. Each is elaborated in full in the section referenced. | **ID** | **Requirement** | **Detailed in** | |---|---|---| | NFR-01 | Core Web Vitals in "Good" range (LCP, CLS, INP); optimised images and lazy loading | §27 | | NFR-02 | WCAG 2.1 AA accessibility compliance across all pages and components | §26 | | NFR-03 | Fully responsive across mobile, tablet, and desktop breakpoints, no horizontal scroll | §25 | | NFR-04 | Unique per-page SEO metadata, structured data, sitemap, and clean slugs | §28 | | NFR-05 | HTTPS-only, validated/sanitised form input, rate limiting, dependency hygiene | §30 | | NFR-06 | Client confidentiality supported via redactable/anonymisable project content | §31 | | NFR-07 | Event-level analytics on all key actions, abstracted behind a swappable tracking layer | §29 | | NFR-08 | Content and presentation fully decoupled; new content requires no code changes | §23 | # 9. Homepage Requirements The homepage is the primary positioning and conversion page. Structure, top to bottom: ## 9.1 Hero **Purpose: instant identity and positioning.** Contains: - Name - Professional title (e.g. "Project Manager | Product Manager | Scrum Master" — placeholder until finalised) - Core value proposition (1–2 sentence positioning statement — content supplied later) - Primary CTA: View My Work → scrolls to/links to Selected Work or Projects page - Secondary CTA: Download CV → triggers file download - Optional tertiary CTA: Let's Connect or Book a Call → links to Contact / booking flow (see §18) - Professional photo (responsive, with graceful layout if omitted) Behaviour: CTAs must be keyboard-accessible and have distinct visual weight (primary filled, secondary outlined/ghost). Limit the hero to a maximum of three CTAs — if both "Let's Connect" and "Book a Call" are wanted, present both as options on the Contact page (§19) rather than crowding the hero. ## 9.2 Professional Snapshot Short, scannable section (2–4 sentences or 3–4 short statements) explaining what she does. Placeholder content: [Professional Snapshot Content]. ## 9.3 Core Capabilities Visual grid/cards (4 items minimum, expandable): - Project Management - Product Management - Agile / Scrum - Technology & Digital Solutions Each card: icon, title, 1-line descriptor (placeholder text). Component must support adding a 5th+ capability later without layout breakage. ## 9.4 Selected Projects - Displays 3–4 featured projects using the reusable Project Card component (see §10). - "View All Projects" CTA linking to /projects. - Must pull from the same content source as the full Projects page (no duplicate/hardcoded content). ## 9.5 How I Work Visual section (icon-led steps, numbered process, or similar) representing working philosophy/approach. Structure only — steps/copy supplied later. Recommend 3–5 steps max for scannability. ## 9.6 Experience Snapshot Condensed preview (most recent 1–2 roles or a summary statement) with "View Full Experience" CTA to /experience. ## 9.7 Certifications Preview Compact row/grid of certification logos or names (3–5 shown) with "View All Certifications" CTA. ## 9.8 Recommendations Preview A rotating carousel or 2–3 static cards pulled from the Recommendations system (see §17), showing a short excerpt and attribution. "View All Recommendations" CTA if a dedicated page/section exists; otherwise this preview may be the only surface for recommendations. ## 9.9 Final CTA Full-width closing section: clear, professional invitation to connect, offering both "Let's Connect" (contact form) and "Book a Call" (booking flow, see §18) as parallel actions. Should visually signal "end of page, time to act." ## 9.10 Footer See §6.5. # 10. Project Portfolio System **This is a core system. Every project must communicate: Problem → Role → Approach → Solution → Outcome.** ## 10.1 Project Card (reusable component) Fields to support: - Project name - Category (e.g. Product, PM, Agile Transformation — tag-based) - Role (e.g. "Product Manager") - Short description (1–2 sentences) - Date/timeline - Key contribution (1 short line) - Outcome (1 short line, metric if available) - Skills/tools (tag list) - Project image/thumbnail - CTA: "View Case Study" → links to detail page States: default, hover (subtle elevation/scale), focus-visible (keyboard). ## 10.2 Projects Listing Page ( /projects ) - Grid of Project Cards. - Featured projects visually distinguished (e.g. larger card or "Featured" tag) at top. - Filtering by category/tag (client-side filter, no page reload). - Sorting — optional: by date (recommended default) or category. - Empty state — if a filter returns zero results: friendly message + "Clear filters" action (never a blank page). - Pagination or "Load more" if project count grows large (design should not assume a fixed, small number of projects). ## 10.3 Project Navigation On each detail page: Previous/Next project navigation, plus "Back to Projects." ## 10.4 Scalability Requirement Adding a new project must be a content-only operation (new entry in the content source) — no component or template changes required. # 11. Case Study System ## 11.1 Reusable Template — Sections Supported (not all required per project) - Project Overview - Challenge - Objective - My Role - Approach - Requirements/Discovery - Prioritisation - Planning - Stakeholder Alignment - Execution/Delivery - Solution - Collaboration - Challenges - Outcome/Impact - Tools & Methods - Key Takeaway ## 11.2 Ownership Clarity Every case study must visually/structurally distinguish "What I owned" from "What the wider team delivered" — e.g. a dedicated "My Contribution" callout or consistent labelling convention, not left to prose alone. ## 11.3 Content System Requirements - Sections must be addable, removable, and reorderable per project (i.e. driven by structured content, not a fixed hardcoded page template). - Must support: rich text, images, screenshots, diagrams, verified metrics/stats blocks, external links, embedded media where relevant. - Must render gracefully when optional sections are absent (no empty headers or broken layout). ## 11.4 Navigation Within Case Studies - In-page section navigation (sticky sidebar or top anchor nav) for long case studies. - "Related Projects" block at the end. - Previous/Next and "Back to Projects." # 12. Experience System ## 12.1 Reusable Experience Entry — Fields - Organisation - Job title - Location - Start date / End date (or "Present") - Context/overview - Responsibilities - Achievements - Major projects (optionally linked to Project entries) - Tools/technologies (tags) ## 12.2 Content Principle Prioritise ownership and outcomes over exhaustive responsibility lists. Achievements should be visually emphasised over routine duties. ## 12.3 Recommended Presentation Hybrid timeline/card system: a vertical timeline for chronological scanning, with each role expandable into a structured card (achievements, projects, tools). This balances recruiter scanning speed with the depth hiring managers/product leaders need, better than a pure timeline (too shallow) or a pure card list (loses chronology at a glance). # 13. About Page ## 13.1 Content Blocks (structure only; copy supplied later) - Who I am - What I do - What motivates my work - How I approach projects/products - Problems I enjoy solving - How I work with teams - Professional direction - Optional: personal/professional interests ## 13.2 UX Requirements - Should read as a single cohesive narrative page, not a form-like list of fields. - Support for a supporting image (professional photo) alongside text, responsive stacking on mobile. - Optional pull-quote or highlight component for a key personal statement. # 14. Skills System ## 14.1 Structure Categorised, not a flat keyword cloud: - Project Management - Product Management - Agile / Scrum - Technology / Digital Products - Tools ## 14.2 Presentation Rules - Skills displayed as tags/labels or short structured lists per category — no percentage bars or "90% proficiency" graphics (misleading, avoid). - Component must support adding/removing skills and categories without redesign. # 15. Certifications ## 15.1 Reusable Certification Component — Fields - Certification name - Issuing organisation - Date/year - Credential ID (where available) - Credential URL (where available, links out) - Certification/issuer logo image (where available) ## 15.2 Content Rule No fabricated or placeholder credential data should ever render as if real — placeholders must be visually and textually obvious (e.g. [Certification Name]) until real data is supplied. # 16. Insights / Articles System ## 16.1 Content Model Per Article - Title - Slug - Category - Publication date - Reading time (calculated or manual) - Cover image - Content (rich text) - Tags - Related articles (auto or manual selection) - Author info (defaults to Godsfavour; structured for future guest content if ever needed) - Sharing (social share links — LinkedIn priority given audience) ## 16.2 Listing Page ( /insights ) - Grid/list of article cards (cover image, title, category, date, reading time, excerpt). - Filter by category/tag. - Empty state for zero results. ## 16.3 Scalability New articles must be publishable without developer intervention — see §23.2 (Content Architecture) for the recommended CMS approach. # 17. Recommendations / Testimonials System Third-party endorsement is high-value evidence for every persona in §4, particularly hiring managers and founders who want validation beyond her own account of her work. This system presents short, attributed recommendations from managers, colleagues, clients, or stakeholders. ## 17.1 Reusable Recommendation Card — Fields - Recommender name - Recommender title/role - Recommender organisation - Relationship to Godsfavour (e.g. "Direct manager", "Cross-functional collaborator", "Client") - Recommendation text/quote - Recommender photo (optional) - Source link (optional — e.g. the original LinkedIn recommendation, where permission allows linking out) - Date - Featured status (boolean, for homepage preview selection) ## 17.2 Placement - Homepage: "Recommendations Preview" carousel/cards (see §9.8). - Optionally: a dedicated Recommendations page/section if volume grows beyond what a homepage preview can showcase, or recommendations are woven into relevant Experience entries and Case studies as supporting quotes. ## 17.3 Content and Sourcing Rules - No fabricated or composite recommendations — every entry must be a genuine statement from a named, real individual with their permission to publish. - Where a recommendation originates from a platform (e.g. LinkedIn), attribute the source rather than presenting it as if written for this site. - Component must render correctly with 1 recommendation or with many — do not assume a fixed count. ## 17.4 Empty State If no recommendations are available yet, the Homepage preview section (§9.8) should not render an empty/broken block — hide the section entirely until at least one recommendation exists, rather than showing placeholder testimonials. # 18. Booking System Founders, hiring managers, and recruiters often want a fast path to a conversation, not just a form. A booking system lets a visitor schedule time directly, removing the back-and-forth of email scheduling. ## 18.1 Recommended Approach Integrate an established third-party scheduling tool (e.g. Calendly, SavvyCal, or similar) rather than building custom scheduling logic. Rationale: calendar sync, timezone conversion, reminder emails, and double-booking prevention are solved problems in these tools — building them bespoke adds significant effort and risk for no differentiation the visitor would notice. The site embeds or links to the scheduling tool; it does not reimplement it. ## 18.2 Placement - "Book a Call" CTA on the Contact page (§19), presented alongside the contact form as a parallel option, not a replacement for it. - Optional secondary placement: Homepage Final CTA (§9.9) and/or Hero (§9.1) tertiary CTA. - Optional dedicated route ( /book ) if the booking experience needs its own page rather than an embed within Contact. ## 18.3 Functional Requirements - Embed the scheduling widget directly on-page (iframe/embed script) so the visitor does not have to leave the site to see availability. - Support one or more defined meeting types (e.g. "Intro Call", "Consulting Call" — placeholder labels, final types supplied later), each mapped to a duration/purpose in the scheduling tool. - Timezone handling is delegated to the scheduling tool (it should detect the visitor's timezone automatically) — no custom timezone logic required on this site. - Booking confirmation, reminders, and calendar invites are handled entirely by the scheduling tool — the site's job is to present the embed and get out of the way. ## 18.4 Error / Fallback State If the embedded widget fails to load (blocked script, network issue), show a fallback message with a direct link to the scheduling tool's hosted booking page and a direct email address as a last resort — never a blank space where the widget should be. ## 18.5 Content Architecture Booking configuration should be a single content entry — not hardcoded into the page — so the scheduling link or provider can change without a code deployment. See §23.1 for the field list. # 19. Contact Experience ## 19.1 Fields Required: Name, Email, Subject, Message Optional: Company, Role/Opportunity type, LinkedIn URL ## 19.2 States to Design and Build | **State** | **Requirement** | |---|---| | Empty | Clear labels/placeholders, no pre-filled assumptions | | Validation | Inline, on-blur or on-submit; clear field-level error messages | | Loading | Submit button shows loading state, disabled to prevent double-submit | | Success | “Message sent successfully. Thanks for reaching out.” — replace form or show confirmation panel | | Error | “Something went wrong while sending your message. Please try again or contact me directly.” — include a fallback direct email link | ## 19.3 Spam Protection Honeypot field and/or CAPTCHA (e.g. reCAPTCHA v3 invisible) plus basic server-side rate limiting. ## 19.4 Accessibility Properly labelled form fields (