Stride 2026 — Designing an Esports Event Experience from Zero

A full UX case study on designing and building the Stride 2026 event website for TAWS and PKGB at the University of Warwick. From brief to launch in one sprint.

[[Timeline:Single Sprint|Deliverable:Event Website|Org:TAWS × PKGB|Venue:University of Warwick]]

The brief was clear in outcome and unclear in scope. Two student organisations had co-produced a competitive gaming afternoon and needed a single landing page live before tickets went on sale. I had a PDF of the event details, a deadline, and a design system already in place. The rest was execution.

The Event & Context

What is Stride?

Stride is a competitive gaming afternoon run jointly by TAWS (The Algorithmic Warwick Society) and PKGB (Puzzle and Games Board). The 2026 edition was their first with a fully produced digital presence — before this, event logistics lived in Discord announcements and Google Docs.

The six brackets

Competitive events require pre-registration via Google Form. Casual events are walk-in. Conflating these two would have flooded organisers with invalid entries.

Defining the Design Brief

Audience segments

The page had to serve three distinct users simultaneously — not sequentially.

<!-- HTML card: /html --> <div class="cs-insight-row"> <div class="cs-insight-icon">🎮</div> <div> <div class="cs-insight-title">Competitive Players</div> <div class="cs-insight-body">Need bracket format, ruleset, registration link, and prize structure. Logistics over social proof.</div> </div> </div> <div class="cs-insight-row"> <div class="cs-insight-icon">🎯</div> <div> <div class="cs-insight-title">Casual Attendees</div> <div class="cs-insight-body">Need to understand the vibe, confirm the date and cost, and feel confident buying a ticket.</div> </div> </div> <div class="cs-insight-row"> <div class="cs-insight-icon">📋</div> <div> <div class="cs-insight-title">Organisers (day-of)</div> <div class="cs-insight-body">The site doubles as a logistics document on the day — bracket times, PayPal links, and room info need to be one tap away.</div> </div> </div>

The most useful design decision wasn't visual — it was information architecture. Competitive and casual tracks needed a clear visual hierarchy, not equal weight.

— Mussie Habte

Hard constraints

Every decision was made inside these fixed limits:

1. Single-file HTML — no build system, live on any server immediately
2. One PDF source — no stakeholder interviews, no discovery phase
3. External flows only — PayPal and Google Forms, no custom registration
4. Right-first-time — the event was weeks away, no revision cycle

Key Design Decisions

Visual system

The page inherited the Made By Mussie design system: Syne for display headings, DM Sans for body, and #FF4D1C on pure dark. An esports event run by two university societies benefits from looking like it was designed with a system — not assembled from a template.

<!-- HTML card: /html --> <div class="cs-img-placeholder" style="min-height:220px"> <div class="cs-img-placeholder-icon">HERO SECTION</div> <div class="cs-img-placeholder-label">Full-viewport dark hero · event name in 88px Syne 800 · accent glow · scroll indicator</div> </div>

Tiering competitive vs casual

Six cards, each with a title, format, ruleset, prize, and CTA — but with a two-tier priority split. The solution: competitive brackets (TETR.IO, Chess, Brawlhalla, Puzzle Hunt) got card-style treatment with explicit register buttons. Casual tracks were listed inline with walk-in clarity, no button.

<!-- HTML card: /html --> <div class="cs-two-col"> <div> <h3>Competitive tracks</h3> <ul> <li>Card layout with accent top border</li> <li>Explicit "Register" CTA button</li> <li>Format and ruleset visible</li> <li>Prizepool deep link to Matcherino</li> </ul> </div> <div> <h3>Casual tracks</h3> <ul> <li>Inline list — no card treatment</li> <li>Walk-in label, no CTA button</li> <li>Reduced visual weight intentionally</li> <li>Still visible — not hidden</li> </ul> </div> </div>

Build & Technical Choices

Why single-file HTML

The brief had no hosting requirements and an implicit expectation that it should just work. A self-contained HTML file fulfils that completely — GitHub Pages, Netlify drop, a university web server, or opened from a desktop. Zero dependencies, zero breakage risk.

<!-- Ghost callout card: /callout -->

✦ The Matcherino prizepool integration is a direct deep link, not an embed. Embedding a live third-party widget introduces a single point of failure with no fallback. The link approach is faster to load and more resilient — which matters on campus WiFi.

Schedule section

The event ran afternoon to evening. I rendered it as a vertical timeline — each time block as a row with a left accent line and a badge indicating type (Setup / Competition / Break / Prize Ceremony). This section is most likely to be referenced on mobile on the day itself.

<!-- HTML card: /html --> <div class="cs-img-placeholder" style="min-height:180px"> <div class="cs-img-placeholder-icon">SCHEDULE TIMELINE</div> <div class="cs-img-placeholder-label">Vertical timeline · left accent rail · colour-coded block types · time in Syne 800</div> </div>

UX Lessons

What this surfaces about event UX

<!-- HTML card: /html --> <div class="cs-insight-row"> <div class="cs-insight-icon">⏱️</div> <div> <div class="cs-insight-title">Temporal urgency changes hierarchy</div> <div class="cs-insight-body">Event pages have a different reading flow than portfolios. Users arrive with a question: can I come, when is it, what do I do? The hero has to answer all three before the fold.</div> </div> </div> <div class="cs-insight-row"> <div class="cs-insight-icon">🔗</div> <div> <div class="cs-insight-title">External flow breaks should be visible</div> <div class="cs-insight-body">Every link that exits the site (PayPal, Google Forms) got an ↗ indicator and a short parenthetical note. Small detail, large trust signal.</div> </div> </div> <div class="cs-insight-row"> <div class="cs-insight-icon">📱</div> <div> <div class="cs-insight-title">Event pages live on mobile on the day</div> <div class="cs-insight-body">Post-launch the page becomes a logistics document. Every section needed to be immediately readable at arm's length on a 375px screen.</div> </div> </div>

Constraints aren't obstacles to good design — they're the conditions under which most real design actually happens.

— Mussie Habte

Outcomes & What's Next

<!– HTML card: /html --> <div class="cs-three-col"> <div class="cs-metric-card"> <div class="cs-metric-val">1</div> <div class="cs-metric-label">Sprint to Ship</div> </div> <div class="cs-metric-card"> <div class="cs-metric-val">6</div> <div class="cs-metric-label">Brackets Covered</div> </div> <div class="cs-metric-card"> <div class="cs-metric-val">0</div> <div class="cs-metric-label">Broken Links on Launch</div> </div> </div>

The site launched with all event data populated: six bracket cards with rulesets and registration links, a live ticket pricing section, the Matcherino prizepool integration, venue details, the full event schedule, and a FAQ block.

If I had more time

1. Live bracket status — a JSON-driven state organisers could update without touching HTML
2. Check-in integration — link ticket purchase to a Google Sheets backend for door management
3. Post-event state — a results page with bracket outcomes and photo gallery
4. Progressive disclosure — accordion components for long ruleset text on bracket cards

<!-- Ghost callout card: /callout -->

✦ A single-day sprint with a clear brief, a pre-existing design system, and disciplined scope management produces more useful output than an open-ended engagement with no constraints. Stride 2026 shipped complete, on time, and worked on the day.