Devlympics

Making security feel like a sport

Devlympics is Secure Code Warrior’s annual global coding competition — 50,000+ developers, North America and APAC. I owned the full UX lifecycle: landing page, registration, competition interface, results.

The core SCW platform is compliance-driven training: structured, enterprise, mandatory. Devlympics had to be high-energy, voluntary, competitive. The same design language could not serve both — and the existing experience had grown organically into a compromise that served neither.

The result was inconsistent UI patterns, unclear competition state (Am I registered? When does this start? Where do I rank?), and a registration flow that lost people before they reached a single challenge.

The audience was deeply technical, with zero tolerance for friction. If the UX failed them they wouldn’t file a complaint. They’d stop participating — and tell their colleagues.

What research told me about developers

Discovery sessions with stakeholders across North America and APAC, then interviews with six past participants at varying skill levels.

• Registration confusion — participants often weren’t sure they’d successfully registered until the event started
• Competition state ambiguity — no “lobby” existed between registration and go-live, so users refreshed, repeatedly
• Leaderboard legibility — rankings were accurate and impossible to scan under time pressure
• Skill-level anxiety — beginners dropped off when challenges felt inaccessible; no scaffolding, no visible entry point
• Mobile gaps — 30%+ competed on mobile, where the experience degraded badly below tablet width

The fourth finding is the one that shaped the most design. Competition mechanics reliably motivate the top 10% and quietly demoralize everyone else — a leaderboard is a scoreboard for people who are already winning. Most of the work was making progress legible to someone who was never going to place.

Structure before polish

I settled the architecture first: hero and registration CTA, an overview that answers what is this and why should I care, the tournament grid, and a progress scorecard. Only then did the visual design happen.

Fixing the registration confusion

I mapped registration as a decision flow rather than a screen sequence, which is what surfaced the actual problem: there was no confirmation state. Users completed the form and got nothing back that told them it had worked.

The redesign added explicit confirmation, a follow-up email ten days out, and a clear path from confirmation into profile completion and practice missions — so the gap between “I registered” and “the event starts” had something in it.

The lobby — the thing that didn’t exist

The most valuable addition to the whole project is one box on this diagram: “Ready to join state.”

Before this, there was nothing between registering and the tournament going live. Participants sat on a page that told them nothing and refreshed it. Adding a genuine lobby — a state that acknowledges you’re in, tells you what happens next, and lets you pick a language and difficulty before the clock starts — eliminated the anxious refresh loop entirely.

It cost almost nothing to build. It was the single biggest improvement to the pre-event experience.

Making state and progress impossible to miss

Every tournament card answers, without being asked: am I in this one? (READY TO JOIN / JOINED / IN PROGRESS / COMPLETED), how hard is it? (points, language count), and how far have I got? (a progress bar, always visible).

That progress bar is the answer to the skill-level anxiety finding. A developer who will never touch the leaderboard can still see themselves moving. Progress and rank are different motivations, and the original design only served one of them.

Difficulty and points on the face of each card also let participants self-select an entry point rather than bouncing off whichever challenge happened to be first.

Components, not screens

The patterns built here didn’t stay in Devlympics. The card components, state badges, and progress indicators went back into the SCW design system for platform-wide reuse — which, given where my career went next, turned out to be the most durable thing I did on this project.

Impact

• 50,000+ developers on the platform, across North America and APAC
• WCAG 2.1 AA maintained throughout
• Design system components contributed back for platform-wide reuse

What I’d do differently

The fixed event date compressed the iteration cycle, and I let it. I’d run moderated usability tests with actual developers on the challenge navigation before launch. This audience is technical enough that small friction compounds fast under competitive pressure — and I shipped navigation I hadn’t tested with them.

I’d also have pushed earlier for quantitative funnel data on registration drop-off. The qualitative signal was clear; the numbers would have made the prioritization argument much harder to wave away.