Skip to content

Latest commit

 

History

History
147 lines (95 loc) · 8.83 KB

File metadata and controls

147 lines (95 loc) · 8.83 KB

Homepage Content Plan

Strategic Framing

Hugo Hsi is a junior full-stack engineer with a design degree — a rare combination at this level. Most early-career developers either come from CS programs or bootcamps and struggle with UI craft. Hugo's Graphic Design background means he can own features end-to-end: from understanding a design file to shipping production code. That's the core positioning.

The homepage has one job: get the recruiter to click into a project. Everything on the page exists to build enough credibility and interest to make that click happen. The page should be scannable in under 10 seconds.

Target audience: Engineering hiring managers and technical recruiters reviewing Hugo's application. They already have his resume — the portfolio is supplementary proof.


Information Hierarchy (Top to Bottom)

1. Hero — Identity + Positioning (above the fold)

Purpose: In 3 seconds, the recruiter should know who Hugo is, what he does, and what makes him different.

Content:

  • Name: Hugo Hsi
  • Tagline (one line): Full-stack developer with a designer's eye.
  • Brief intro (2-3 sentences max): Concise paragraph that establishes: design degree background, transitioned to engineering, has shipped real client work at Praxis Loop, builds with React/Next.js, TypeScript, and Node.js. This is not a bio — it's a value proposition.
  • Primary CTA: "View my work" — scrolls or links to the featured projects section
  • Secondary CTA: "Download resume" — PDF download
  • Social links: GitHub, LinkedIn — small, non-distracting, in the hero or a persistent nav

What NOT to include here: No long backstory. No "I'm passionate about..." filler. No photo unless it's strong and professional. No skills list — that comes later.


2. Featured Projects — The Main Event (first scroll)

Purpose: This is the most important section on the page. Recruiters want to see what you've built, not what you say you can do. Show 3 projects that demonstrate range and real-world impact.

Content per project card:

  • Project name
  • One-line description (what it is, not how it was built)
  • Context tag: e.g., "Client Work at Praxis Loop" or "Personal Project" — this immediately signals real-world experience vs. hobby work
  • Featured image / screenshot — visual proof the thing exists and looks good
  • Tech tags (2-4 max per project) — e.g., "Next.js, Prismic, TypeScript"
  • Link to full case study page — not the live site, the case study. The case study is where you tell the story; the homepage card is just the hook.

The 3 projects:

  1. National Medal of Honor Museum — CMS migration from WordPress to Prismic. Context: client work at Praxis Loop. This project carries the most credibility (recognizable institution, real migration complexity).
  2. 1st Avenue Advisors — Client-facing pages, Figma-to-code implementation, working forms. Context: client work at Praxis Loop. Demonstrates the design-to-code pipeline and frontend precision.
  3. [Third project — TBD] — Ideally a personal or open-source project that shows backend depth or full-stack ownership (not just frontend). This rounds out the picture: he can do client work AND builds things on his own.

Layout note: Cards should be visual-first. Large screenshots, minimal text. The design degree should be evident in how the projects are presented, not just described.


3. Brief Credibility Bar — Experience + Education (one section, not two)

Purpose: Quickly validate that Hugo has real-world experience and a relevant education. This is NOT a full resume — it's a credibility snapshot.

Content:

  • One role: Full-Stack Developer at Praxis Loop — brief description (2 sentences max): shipped client websites, led CMS migrations, translated design files to production code. Include approximate dates.
  • Education: BFA in Graphic Design from [Institution]. One line. No coursework list.
  • The bridge sentence: Something that ties design + engineering together. e.g., "My design training means I don't just build what's specced — I understand why it's specced that way." (Rough idea, not final copy.)

What NOT to include: Don't turn this into a resume duplicate. No bullet points of responsibilities. No list of every technology. The recruiter has the resume — this section reinforces the narrative, not repeats it.


4. Tech Stack — Proof of Competence (compact)

Purpose: A scannable reference for "does this person know the tools we use?" Recruiters and hiring managers ctrl+F for specific technologies. Make this easy to scan.

Content:

  • Organized by category, presented compactly (not a sprawling grid of 30 logos):
    • Frontend: React, Next.js, Svelte, Tailwind CSS
    • Backend: Node.js, TypeScript
    • Data: PostgreSQL, MongoDB
    • Tools: Git, Figma (Figma is a differentiator — most devs don't list it)
  • No self-ratings. No "React: 4/5 stars." These are meaningless and can only hurt you.
  • No "familiar with" tier. Only list things you'd be comfortable discussing in an interview.

Optional — learning/exploring: A subtle mention of Go and Rust as things you're actively learning. Signals growth mindset without overstating current ability. Keep it clearly separated from core stack (e.g., "Currently exploring: Go, Rust").


5. Additional Work — The Lab (optional, lower priority)

Purpose: Show that Hugo builds things outside of work. This is where the smaller experiments, learning projects, and hobby work live. Signals curiosity and initiative without pretending these are portfolio-grade.

Content:

  • Section title: Something like "Lab" or "Experiments" — NOT "Other Projects" (that makes them sound like rejects)
  • 3-6 small items, each with:
    • Name
    • One-sentence description
    • Tech used
    • Link (GitHub or live)
  • Presented more compactly than featured projects — small cards, a list, or a grid. Meant to be browsed, not studied.

What goes here: Language experiments (Go/Rust learning projects), small tools, weekend builds, anything interesting that doesn't warrant a full case study.


6. Contact / Footer — Close the Loop

Purpose: Make it dead simple to reach Hugo. No contact forms (recruiters won't use them). Direct links only.

Content:

  • Email address (plaintext, clickable mailto link)
  • LinkedIn link
  • GitHub link
  • Location: NYC area, open to remote
  • Availability status: Available for full-time roles — explicit and unambiguous

What NOT to include: No contact form. No "let's collaborate" language (not freelancing). No "feel free to reach out" hedging. Be direct: "I'm looking for full-time engineering roles. Here's how to reach me."


What Should NOT Be on the Homepage

  • No blog section — plan for it in site architecture, but don't put an empty section on the homepage
  • No testimonials — at junior level with limited work history, this can feel forced
  • No long-form "About Me" — save that for a dedicated /about page if needed
  • No services offered / rates — not freelancing
  • No "hire me" desperation language — tone should be confident and professional, like someone presenting work they're proud of
  • No generic stock illustrations or decorative filler — every visual should be a real screenshot or serve a clear purpose

Tone Guidelines

  • Professional but not corporate. Write like a real person, not a LinkedIn bio.
  • Confident but not arrogant. "I built this" not "I'm the best at this."
  • Concise. Every sentence should earn its place. If a sentence doesn't help the recruiter make a decision, cut it.
  • Show, don't tell. "Migrated a museum's website from WordPress to Prismic CMS" beats "experienced with CMS platforms and content migration."
  • No filler phrases: "passionate about," "detail-oriented," "team player," "leveraging cutting-edge technologies." These are noise.

Open Questions to Resolve Before Implementation

  1. Third project: What will it be? Ideally something with more backend depth (API design, database work, authentication) to round out the full-stack narrative. Worth deciding before building the page.
  2. Professional photo: Include one in the hero, or skip it? Only include if it's high quality.
  3. AI experience: Hugo has strong AI tooling experience. Worth mentioning on the homepage? Increasingly relevant, but needs careful framing — "uses AI effectively as part of his workflow" is a strength; it should not read as "AI writes my code." Consider a subtle mention in the intro or within project descriptions where AI tools were part of the process.
  4. Case study pages: The homepage cards should link to detailed case study pages. The depth of those pages (problem, approach, solution, outcome) is where Hugo can really differentiate. Plan those separately.