Project:
https://gmd-assessment.vercel.app/

Github:
https://github.com/micheleborn/gmd-assessment

The Context

This project was built as part of a Growth Marketing Designer assessment — a role that requires end-to-end ownership of landing pages, from design to deployment, with performance measured by conversion rate .

But the brief came with a twist:

• No clear audience
• No defined product positioning
• No brand guidelines
• No funnel stage

So instead of “executing,” I had to define the strategy from scratch.

The Goal

Design and build three landing page variants:

• /control
• /variant-1
• /variant-2

Each with:

• A different conversion hypothesis
• A consistent structure for testing
• Measurable behavioral tracking

Step 1 — Defining the Strategy (Before Design)

Instead of jumping into UI, I started with who this is for.

Target audience (assumed)

• Mid-size DTC brands ($3M–$30M)
• Paid acquisition fatigue (Meta, CPMs rising)
• Distrust in attribution
• Pressure from finance teams

Core emotional state

“I don’t trust my growth anymore.”

That became the foundation of everything.

Step 2 — Hypothesis Design

Each variant explores a different persuasion model:

1. Control — USP Clarity

• Straightforward messaging
• “What it does” framing
• Minimal psychological layering

2. Variant 1 — Authority + Social Proof

• Borrowed credibility
• Proof-driven messaging
• Reduces skepticism

3. Variant 2 — Risk Mitigation (Most interesting)

• Focus on predictability + control
• Addresses emotional anxiety directly
• Designed for decision-makers under pressure

This is not UI variation.
This is psychological positioning testing.

Step 3 — UX & UI Decisions

UX Principles

• Single goal: conversion
• No distractions, no navigation complexity
• Repeated CTA for scanning behavior
• Clear hierarchy (problem → solution → action)

UI Decisions

• Clean, high-contrast typography
• Modular components reused across variants
• Visual consistency to isolate messaging impact

Important:
I intentionally avoided “fancy design”
Because design should not contaminate the experiment

Step 4 — Development (Next.js + Vercel)

Built with:

• Next.js + TypeScript
• Component-based architecture
• Route-based variant system

Routing strategy

• /control
• /variant-1
• /variant-2

Each route:

• Injects different content
• Reuses the same components

This ensures:

• Fast iteration
• Clean experiment structure
• Scalability for future tests

Deployment

• Deployed via Vercel
• Instant previews + production parity
• CI/CD built-in

Step 5 — Analytics (PostHog)

Implemented full tracking:

Events

• variant_viewed
• signed_up
• CTA clicks (with placement tracking)

Data captured

• Variant name
• CTA location (hero, footer, etc.)
• Referral codes

Every interaction is measurable.

Also:

• Ensured event capture before redirect
• Structured for funnel analysis

Step 6 — Experiment Design

This is the part most people skip.

What I controlled:

• Same layout across all variants
• Same CTA wording
• Same visual design

What I changed:

• Messaging strategy only

That’s how you isolate causality

What AI Changed

This project took ~3 days.

Without AI, it would realistically take ~2 weeks.

AI helped with:

• Validating messaging directions
• Exploring persuasion angles
• Speeding up iteration

But:
The strategy decisions were still human

Key Takeaways

• Conversion is psychology first, design second
• Most landing pages fail because they skip strategy
• A/B testing is useless without clear hypotheses
• Speed matters — but only if direction is correct

Final Thought

This wasn’t a design exercise.

• It was:
• Strategy
• Psychology
• Engineering
• Measurement

All in one system.

I actually love the way this turned out – super happy with the results.

Spoiler alert, it’s this one:

https://hansonhotline.com

Mostly after spending way too much time with support trying to resolve an SSL error. After a few conversations that went nowhere, it felt like the right moment to, as usual, take matters into my own busy hands (on about three hours of sleep, naturally).

A few quick stats:

• Build time: ~10 seconds
• Total migration time: ~1.5 hours

Infrastructure steps:

• Attach custom domain
• Push React project to GitHub
• Connect repo to Cloudflare Pages
• Build & deploy (automatic)
• Move DNS to Cloudflare

Where we’re at: Vite + TypeScript + Cloudflare + GitHub

The site is now a simple React build (Vite + TypeScript) deployed through Cloudflare Pages, with GitHub triggering the builds. DNS, SSL, and the CDN are handled by Cloudflare, so there’s no server to manage and deployments are just a git push.

It was also a good reminder that sometimes we already know how to do a lot more than we think — it just takes being forced to deploy something for all those pieces to finally click together.