Case Study
Guidelines
Every new project page uses the same template.
Any page added to the My Apps, Projects, or Blog sections must be built from Case Study Template. It is the canonical layout for the portfolio: the only shape pages take, the only component vocabulary they use, and the source of every typographic and color decision a reader sees.
Why one template
A single template guarantees four things across the portfolio: visual consistency (every page reads as one site), accessibility (contrast and reading rules baked in), maintainability (one stylesheet change reaches every case study), and speed (drafting a new case study is a writing exercise, not a design exercise).
Where new pages live.
Section maps to folder. Choose the right one based on whose product
it is — your own work goes to work/applications/, client/agency work goes to
work/case-studies/, writing goes to
blog/.
/work/applications/<slug>.html
Products you designed AND built. Examples already in the portfolio:
work/applications/skysavage.html, work/applications/lovetokens.html,
work/applications/colibrigc.html. Breadcrumb starts with
Work › and the sidebar's "Work" item is marked active.
/work/case-studies/<slug>.html
Client, agency, or in-house work where you owned the design but not
the codebase. Examples: work/case-studies/numerade.html,
work/case-studies/visva.html. Breadcrumb starts with
Projects ›; sidebar's "Projects" item is marked active.
/blog/<slug>.html
Long-form writing — process essays, design-system breakdowns, opinion pieces. Breadcrumb starts with Blog ›; sidebar's "Blog" item is marked active.
/portfolio-assets/projects/<ProjectName>/
Every project gets its own asset folder. Use PascalCase for the
folder name and reference assets relative to the page's depth —
../portfolio-assets/projects/<ProjectName>/<file>
from a one-level page (blog/),
../../portfolio-assets/projects/<ProjectName>/<file>
from a two-level page (work/applications/, work/case-studies/).
From template to published page in six steps.
-
Copy
Design-System/new-project-template.htmlinto the target section folder (/work/applications/,/work/case-studies/, or/blog/) and rename it to<slug>.html. Slug is lowercase, kebab-case, matches the URL. -
Add the sidebar. The template ships without one.
Copy
<aside class="sidebar">from any existing case study (e.g.work/applications/skysavage.html) and flip the.activeflag to the nav item that matches your section. -
Update the top bar. Both the Back button's
hrefand the breadcrumb link should point at../index.html#<section>from a one-level page, or../../index.html#<section>from a two-level page likework/applications/(apps / projects / blog). The breadcrumb's current page text becomes the project's display name. -
Drop assets into
/portfolio-assets/projects/<ProjectName>/. Replace everyimage-placeholderblock in the template with a real<img>or remove the section entirely if you don't have the visual. Optimize to ≤ 500 KB per image before committing. - Swap the placeholders. Walk through the template section by section and replace every "Project Name", "headline metric", and placeholder paragraph with real content. Delete optional sections you don't need.
-
Link from the home page. Add a Preview Card to the
relevant section grid in
index.htmlpointing at the new page. Use the existing card markup as the template — same component, same proportions.
What every case study must contain.
Required sections form the spine — they're how a recruiter or hiring manager reads the page. Optional sections are levers for depth on individual projects. Reorder freely, but don't drop a required section.
Reuse, don't reinvent.
Pages are assembled from a fixed component vocabulary. If a layout
you need isn't in the list below, add it to the design system first
(in project.css or components.css) — then
use it. Don't ship one-off inline styles.
Layout primitives — project.css
.project-page · .project-page.full-width ·
.project-topbar · .cs-overview ·
.cs-overview-head · .cs-overview-image ·
.project-hero · .project-image ·
.project-image-portrait · .project-section ·
.project-meta-grid · .project-cta-row ·
.project-footer
Image layouts — project.css
.layout-two-up (before/after) ·
.layout-three-up (concept comparison) ·
.layout-asymmetric (large + small) ·
.image-text-split (50/50 prose + image) ·
.image-with-caption · .image-placeholder
Highlight blocks — project.css
.project-callout (pull-quote, white italic on Taupe) ·
.decision-block (pale-peach insight callout) ·
.testimonial-block (user quote with attribution) ·
.stat-block-large (one hero stat) ·
.feature-list + .feature-item (01/02/03 list) ·
.credits-list
Stats — reuses home.css
.overview-stats + .stat + .stat-value
+ .stat-label for hero headline stats and Outcomes;
.app-metric-val + .app-metric-label for
smaller inline metric pairs.
Buttons & status — components.css
.btn.btn-solid.btn-sm or .btn-md for primary
actions (App Store, Visit, View on App Store);
.btn.btn-outline.btn-taupe.btn-sm for Read More and Back;
.status-badge for NDA / Deprecated / In progress.
Contrast and color rules.
The portfolio meets WCAG AA for everything and AAA for body text. The shortcut: use Black for all prose, reserve Taupe for non-prose (labels, rails, button outlines, icon strokes). Full matrix lives in Colors §03.
Body text = Black
--text-primary (#000000) on White, Sand, or Peach
backgrounds achieves AAA (≥ 7:1). Apply for every paragraph,
feature body, decision text, and stat label. No exceptions.
Taupe is for non-prose only
--c-taupe on white passes AA at 4.82:1 — enough for
small labels, eyebrow text, and breadcrumbs. Taupe on Sand or
Peach fails AA for body text and must NOT be used there. Reserve
Taupe for: section labels (eyebrow), button outline borders,
breadcrumb links, divider rails, and timeline dots.
Image alt text is required
Every <img> needs an alt attribute that
describes the content meaningfully — not "image" or "screenshot".
Decorative-only placeholder blocks (e.g. the colored
.image-placeholder in the template) can use
aria-hidden="true" instead.
Every stat needs a label
A bare number is unreadable to screen readers and unmemorable to
scanners. Every .stat-value ships with a
.stat-label that names the metric, the time window,
or the comparison baseline (e.g. "MAU · 60k → 165k in 6 mo").
Conventions that keep the repo navigable.
HTML files — kebab-case, lowercase
work/applications/skysavage.html,
work/case-studies/numerade.html,
work/applications/colibrigc.html. URL-friendly, easy to type,
consistent across the codebase.
Asset folders — PascalCase
portfolio-assets/projects/SkySavage/,
.../Numerade/, .../VISVA/,
.../LoveTokens/. Matches the product's branding casing
for legibility in the file tree.
Asset file names — descriptive, kebab-ish
<Project>-AppIcon.png,
<Project>-MainPage-Preview.png,
<Project>-Xcode.png. Project prefix first so files
sort together in image previews.
Image weight budget — ≤ 500 KB per file
Re-export to WebP or JPEG at ~1600 px wide before committing. The portfolio has already learned this the hard way — see SkySavage's 14 MB hero image, which is too heavy for any real visitor.
Copy Design-System/new-project-template.html as the starting point for every new project page. Don't start from a blank file or from an existing case study — the template is the source of truth.
Layouts and highlight blocks come from project.css and components.css. Don't introduce one-off inline styles for spacing, color, or layout — extend the system instead.
Topbar, hero, headline stats, meta grid, the product, the challenge, outcomes, stack, reflection, CTA, footer. Always present, in roughly that order. Optional sections can be added or dropped per project.
All body, heading, and stat text uses Black for AAA contrast on every background in the palette. Taupe is reserved for labels, rails, button outlines, and dividers. See Colors for the matrix.
A new case study isn't shipped until it has a Preview Card on index.html in the matching section grid (My Apps / Projects / Blog), with the Read More link pointing at the new page.
The project footer's Next → button links to the next case study in the same section so readers can move horizontally through the work without bouncing back to the home page. Set both the project name and the href.
Now go build a case study.
Open the template, copy it into the right folder, follow the workflow, and ship. The system handles the rest.
Open the Template