Unified system to manage four cybersecurity competitions: Linear, Assessment, Drill, CTF , KOTH, Escape room
INTRODUCTION
01
THE PROJECT
THE ROLE
Sole Product Designer Collaborating with 1 BA, 5 Engineers, 4-5 Cyber Security analyst and Stakeholders
IMPACT
Organised an event called Classified Campus Event CTF at IIT Delhi
120 Players took part in the challenge
Discovery
02
In CyberKshetra, an “Event” meant formats that is different from one another
LINEAR
A sequence of tasks. A journey. For both Teams and Solo
ASSESSMENT
One task. A test. For both Teams and Solo
DRILL
Live Red vs. Blue on a real network. A match. between Teams
CTF
KOTH
UPCOMING
ESCAPE ROOM
UPCOMING
These formats have entirely different pacing, rules, and definitions of “winning”.
PROBLEM
03
3 Major problem we noticed on the present design.
The original 3-step flow (Details -> Setup -> Publish)
worked perfectly for two types of events. Linear and Assessment
Then, Drill and CTF arrived with 2 more coming soon. But Drill requires complex teams to be built during the setup phase,
the first page was suddenly forced to carry
event details, type selection, team creation, and privacy settings.
This forced one screen to do four completely unrelated jobs, resulting in massive cognitive overload at step one.
THE HARD QUESTION
04
We faced a structural dilemma:
One rigid template Forces all formats into a mold where they all feel wrong.
Separate tools per format Causes massive platform bloat.
THE GOAL
04
WHAT I TRIED FIRST
04
We Explored options on how we should proceed while keeping the event structure same for all the event type. With real layout and paper wireframes
I used paper wireframes and crazy 8 to visualize my flow ideas.
We tried squeezing the new type into the old structure. It produced the exact cognitive overload mentioned above.
The Problem: This led to the real diagnosis-the flow was failing because the steps weren’t restricted to a single responsibility. Rather than it was all config dumped into one page
We initially tried keeping the v1 layout and adding an expandable div. It failed because it ate 30% of usable space and did nothing until clicked.
The Problem: This failure led to the persistent stepper, achieving the same orientation job in a fraction of the space.
THE SOLUTION I CAME UP
04
Details + stepper
The constant. The stepper never changes, keeping the creator oriented regardless of what they are building.
Event Mode selection
The hinge. Type selection earns its own step because it decides everything downstream.
Drill team assignment
Selection becomes construction. For Drill, picking the type is the very start of building the match.
Setup with Topology tab
Same skeleton, different organs. Drill dynamically exposes a live network Topology tab.
Visibility / Accessibility panel
Authoring asymmetry.
Per node, per team: the creator dictates who can see it Vs who can interact with it. This is how a creator builds the asymmetry a Red-vs-Blue environment depends on.
Player view
The player view is another case study of its own.
But the payoff. Locked role, scoped view. The player is aware of the attack but is never handed the full picture.
THE IMPACT
04
Hosted a live CTF at IIT Delhi on 15 August. It featured open registration with [X] participants competing, and ran without incident. This was not an internal improvement; it was a real external commitment the system had to hold up for.
CTF was added later as a fourth type and slotted perfectly into the existing four steps without restructuring. Each new type is now substantially cheaper to add.
Replaced conditional logic on a single page with clean routing, making the system vastly cheaper to build.
increase in [Metric 1: e.g., task completion rate]
improvement in [Metric 2: e.g., setup time for complex events]