Close
CyberKshetra
Designing one event system for three kinds of competition
Role
Sole Product Designer — information architecture, flows, interaction, UI
Team
1 designer (me),
1 business analyst, 3 front-end +
2 back-end engineers,
1 stakeholder
Timeline
3 months for the initial system (Assessment + Linear); ~3 months for Drill and the flow re-architecture, iterated through sprints
Tools
Figma, FigJam, paper wireframing
00
CyberKshetra is a cybersecurity education and resilience platform that lets institutions run hands-on training — structured courses, live labs, and real-world attack simulations. It was built greenfield, with no prior product to inherit from.
This case study is about one part of it: the event system — the tool Admins and Managers use to create cybersecurity competitions. It looks like a single "create an event" feature. Underneath, it had to hold three competitions that barely resemble each other.
The Problem
01
An "event" in CyberKshetra isn't one thing. It's three structurally different kinds of competition wearing one name:
A journey
Linear
A sequence of tasks / Stages where the participant works through, either in a fixed order (Progressive) or freely (Free Flow).
Where the Task can be either a set of Questionnaires or a Labs such as Scenarios or CVEs
A test
Assessment
A single controlled task, where the design problem is fairness: identical questions for everyone (Classic) or a defined percentage shared across participants (Arcade).
A live match
Drill
A live Red-vs-Blue exercise built on top of a full network scenario, where participants are split into opposing teams.
These don't just differ in settings. They differ in shape — in pacing, in what "fair" means, in what "winning" looks like. A journey, a test, and an adversarial match have almost nothing in common in how they feel to run.
That created the core tension of the project:
Build one coherent system, or three separate tools?
One rigid template forces all three into the same mold — and each ends up feeling wrong. Three disconnected tools bloat the platform and make every event feel like a different product. The real work was finding the line between them: what stays constant so the system feels like one thing, and what's allowed to vary so each competition stays true to its own shape.
Who This Is For
02
I used a rough mental model of three creators to pressure-test the flow:
Persona 01
Process-oriented, non-security user
Understands process, not security. Could create an event successfully on the second attempt, once the structure clicked.
Persona 02
Security faculty or content-team member
Already fluent in how events work. First attempt, no friction.
Persona 03
Technical user
First attempt, comfortably.
That spread mattered. If the flow only worked for the technical user, it had failed. The target was a creator who understands events but isn't a security engineer — so the design had to carry its own structure clearly enough that a process-literate person could self-serve. Where someone landed on that spectrum predicted how hard the flow felt, and that became my yardstick.
The Messy Middle: When Drill Broke the Flow
03
The first version was simpler than what shipped — and it worked, until it didn't.
This illustrates the event type selection before the drill, featuring various modes tailored for different events. You can expand or collapse details for clarity.
For two event types, this held together. Then Drill was introduced — and it broke the pattern.
Drill couldn't fit the first page's assumptions. A Drill needs teams — Attacker, Defender, and others — created and assigned as part of setting it up. Bolting that onto the existing structure meant the first page now carried: event details + type selection + team creation + privacy. One screen doing four unrelated jobs.
The result was exactly the failure the project was supposed to avoid: cognitive overload on the first step. A creator opening the flow to make a Drill hit a wall of unrelated decisions before they'd even oriented. The system had bent the new type to fit the old shape — the "rigid template" failure mode, live.
That was the trigger for the redesign. Not a polish pass — a re-architecture. And the diagnosis was specific: the first page was overloaded because steps weren't each responsible for one thing. That diagnosis became the principle for the fix.
The Decisions
04
DECISION 01
One step, one purpose
I split the overloaded flow into four steps, each with a single responsibility:
Details
Name, description, tags, Achievement. Identical for all three types.
Event Selection
Choose Assessment, Linear, or Drill, and its sub-options.
Setup
Configure the event based on the type chosen.
Privacy & Publish
Set access and schedule.
The point wasn't "more steps." It was that no single step could be flooded again the way the first page had been. Giving each step one job is what let the system absorb a type as heavy as Drill without collapsing — and it meant adding a fourth type later wouldn't break the structure either.
DECISION 02
Event Selection earns its own page
Splitting type selection out of Details wasn't cosmetic. For Assessment and linear the type we choose is not very extensive but For Drill, choosing the type is the moment you start building teams — Attacker, Defender, and others. That's far too much to hang off the Details page. Giving selection its own step gave that work room to exist, and made the type choice the clear hinge the rest of the flow turns on.
I decided to create a dedicated page for our event because we currently have Assessment, Linear, and Drill events, but we plan to expand to other types like KOFT (King Of The Hills), Escape Room, and CTF (Capture The Flag). After discussing with stakeholders, I realized that having a specific page for events would simplify access and allow users to easily create events tailored to their future needs.
DECISION 03
The Flow’s ending adapts to the type
This is the decision I'm most proud of, because it's where the "shared backbone, intentional variation" thesis becomes concrete.
I moved privacy from the middle of the flow to the end — but more interesting is what the end becomes, which depends on the type:
When the event mode is set to linear or Assessment, the Privacy and Schedule page is essential. This is where we decide whether to keep the event type as a team or for individual users based on our needs. In contrast, with the Drill Type, we don't define users; instead, we categorise the team into Attackers, Defenders, Moderators, and Viewers. This categorisation must happen before we enter the setup phase because accessibility and visibility depend on it.
Without defining the team, we cannot edit or save the setup page. This significantly impacts how the event type we choose affects the preview and publish pages later in the event creation process. Below is a wireframe illustrating my thought process.
The reasoning: access is a publishing decision, and a publishing decision should come after the thing exists. Asking "who can see this?" before a creator has built the event is asking them to decide about something that isn't there yet. Build first, set access last. And because Drill defines its participants during setup, the flow is smart enough not to ask twice — the same step, shaped by what the type already knows.
This also paid off technically. Instead of one page mutating through tangled conditional logic, the engineers could define cleaner routes — one step genuinely influencing the next. The design got simpler to use and simpler to build at the same time.
DECISION 04
A stepper, so creators never lose the thread
The flow is long, branching, and Event type-dependent — exactly the kind of flow where people lose track of where they are.
At first, I considered keeping the UI the same by adding the event mode as a similar linear box. However, when I opened the div, it only expanded to show options for selecting the event mode, which ended up reducing our usable space by 30%. This space was meant to visually separate elements, but it didn’t allow for any interaction unless users clicked to open the div. This realization led me to decide on using a stepper instead, which provides a clearer and more interactive experience.
The persistent stepper (Details → Event Mode → Set Up → Privacy & Schedule) keeps the whole shape visible at all times, so a creator always knows where they are and what's left. This is the shared backbone made literal: no matter which of the three types you pick, the same orientation rail holds.
DECISION 05
Visibility and Accessibility — two controls, not one
Inside a Drill, nodes can't simply be on or off for everyone. The security team defined the requirement: a node might need to be visible to a team but only interactable by some — and those are two different things. I designed the model that made that authorable:
Two separate controls, set per node, per team (Attacker / Defender / others) — instead of one global visible/invisible switch. This granularity is what lets a creator author the information asymmetry that makes a Red-vs-Blue exercise real:
Visibility allows a selected team to view their assigned nodes. Accessibility ensures that team members who can see these nodes also have the ability to interact with them, depending on the selected team members.
The two sides must not see the same board. The domain requirement was the security team's; the two-control interaction model that made it usable was my design.
The Solution
05
Walking the flow as a creator experiences it each screen carrying the decision behind it.
SOLUTION 01
The backbone
The stepper.
Every step in the flow sits under the same persistent rail. Whatever type a creator is building, this is the constant — the orientation that never changes. It's the most literal expression of the shared backbone: one system, always legible.
SOLUTION 02
Event Selection as the hinge
Choosing the type is its own step.
Choosing the type is its own step because the type decides everything downstream. Here Drill is selected, and the consequence is immediate: the creator drags teams into Attacker, Defender, Moderator, and Viewers. This is why selection couldn't live on the Details page — for Drill, picking the type is the start of building the match. One screen, one job.
Later on when the event is Expanded to different types such as KOTF (King Of The Hills), CTF (Capture The Flag), Escape room, everything about the event can be customised and Edited in this event Mode selection page
SOLUTION 03
Setup adapts to the type
Same skeleton, different organs.
The setup step wears the shape of the chosen type. Assessment and Linear expose a Briefing + Questionnaire/Task structure organized in stages; Drill exposes Briefing + Topology + Task, because a Drill is built on a live network scenario. Same skeleton — briefing, tasks, resources, advanced settings — different organs where the format demands it. This is "variation only where it earns its place," visible on the screen.
SOLUTION 04
Authoring asymmetry
Visibility and Accessibility.
This is the heart of Drill. On the scenario's topology, the creator sets — per node, per team —
who can see it (Visibility)
and who can interact with it (Accessibility).
These are two distinct controls because the security team's requirement was that they're two distinct things. This is the interface where a creator authors the information asymmetry that a Red-vs-Blue exercise depends on.
SOLUTION 05
The flow's adaptive ending
Privacy & Schedule.
For Linear and Assessment, this step assigns access to teams or users. For Drill, the participants were already defined during Setup — so this step collapses to scheduling. The end of the flow knows what the type already told it, and doesn't ask twice.
the LOOP
What the creator authored VS what the player experiences
This is the payoff, and the reason the visibility model matters. Two screens, side by side:
On the left, the creator defines who sees what. On the right, a participant lives inside exactly that decision: locked to the Attacker role, seeing only their scoped view of the network, aware an attack is underway but not handed the full picture. The asymmetry the creator authored, node by node, is the asymmetry the player feels in real time.
That's the line the whole system was built to draw — and it closes here, from a creator's checkbox to a defender's live experience.
Outcome
06
The event system shipped and is live on the platform. It was validated qualitatively with the users best positioned to judge it: internal teams and cybersecurity practitioners who had used the pre-redesign flow and could compare directly.
Their feedback centered on two things the redesign was specifically built to fix:
Navigation felt simpler.
The flow read as more logical to move through than the original — consistent with the goal of giving each step a single job.
It was learnable without hand-holding.
Creators reported that once they understood how setup worked, they could self-serve and figure out the rest on their own — the stepper and the build-first sequencing doing their intended work of keeping creators oriented through a long, branching, type-dependent flow.
The honest read: the things I changed produced the effects I designed them to produce, reported by people who had felt the old version's friction firsthand.
What I'd Do Differently
07
The validation has a real limit, and it's worth naming plainly: it was done with technical users who already understood the flows. That's a favorable audience. It tells me the redesign improved things for people fluent in the domain — but it doesn't yet tell me whether a process-oriented, non-security creator (the user this flow was ultimately meant to serve) can navigate it cold.
So the next step I'd take is guerrilla testing the prototype with creators who don't already know the flow — watching where they hesitate, misread a step, or get surprised. The most specific thing I'd want to learn: does Drill's adaptive ending — the final step collapsing to scheduling-only — help by removing a redundant decision, or confuse by disappearing a step people expected to see? I have a hypothesis, not an answer, and that's exactly the kind of question unbiased testing exists to settle.
That gap between "validated with experts" and "validated with the intended creator" is the honest boundary of what I know today — and closing it is where I'd take this next.