Close
A CASE STUDY OF CYBERKSHETRA / scenario
Product DesignER
01 - Overview
A scenario is live infrastructure, not content
A scenario in CyberKshetra is a live, provisioned network environment that learners attack and defend inside - not content, but real infrastructure: networks, routers, servers, and end devices, each with its own configuration, standing up on OpenStack behind the scenes.
Someone has to build that environment. This case study is about the part of the builder where a creator configures each node on the network - and how I designed that configuration to be legible and low-error, given that the underlying complexity couldn't be removed.
02 - The problem
When you can't simplify the task, design the experience around it
Configuring a scenario isn't filling in a form. It's defining a working network, node by node, where every node type needs different technically exact inputs:
And the inputs aren't forgiving. These fields are dictated by how real networks function - get one wrong, and the environment fails to stand up. The requirements came straight from cybersecurity analysts who'd modeled them on how professional cyber-range platforms work; they weren't negotiable, and they weren't simplifiable.
So this wasn't a "make it simpler" problem. The complexity was real, required, and fixed. Which is exactly what made it a design problem worth solving:
The fields can't be cut - so the only lever is the experience around them.
"When you can't reduce what a task demands, the design question becomes how a person moves through it how the inputs are grouped, how each node's form stays familiar despite asking for different things, how mistakes surface in a way someone can actually act on, and how the edge cases nobody wrote down still get handled. The realism stays; the friction is what I could design away."
That lever - designing the experience around an irreducible technical core - is what the rest of this case study is about.
03 - Who this is foR
The people who build scenarios are Scenario Builders - a dedicated role on the platform for exactly this work. They're technical enough to understand what a network needs, but the builder still had to carry its own structure clearly: configuring a dozen nodes, each with different required fields, is a lot to hold in your head, and the design's job was to keep that load manageable and the mistakes recoverable.
That framing mattered because of how the work was divided.
04 - How the work was divide
Specialist-led; interface design was mine
ROLE CYBERSECURITY ANALYSIS
Defined how scenarios and nodes must behave - which fields each node requires, how inputs interact, what makes a configuration valid. They modeled this on how professional cyber-range platforms work. This was domain truth, and it was theirs.
This was a deeply collaborative, specialist-led build, and being precise about who owned what is part of the story:
ROLE BA
translated that into raw requirements and handed them to me - field lists, interaction rules, "we want a form."
MY ROLE
designed the interface from that raw material. There was no UI proposed - just requirements. Every layout, interaction, error state, and the structure tying it together was mine, including edge cases the requirements never mentioned but that a real builder would hit.
That's the honest boundary they defined what the system must do; I designed how a person actually does it. It's the most accurate description of design work on a technical product - and the gap between "here are the required fields" and "here is a system someone can actually configure a network in" is precisely where the design lives.
05 - The messy middle
What the raw requirements didn't solve
The requirements told me what each node needed. They didn't tell me how to make configuring twenty of them survivable. Two problems showed up that no spec addressed - and solving them is the design contribution.
Problem 1
Every node is different, but they can't feel like different tools.
A Network form, a Server form, and an end-device form ask for genuinely different things. The naive result is three (or six) unrelated forms - every node a small relearning cost, the builder never settling into a rhythm. But the opposite risk was just as real: forcing genuinely different inputs into one rigid shape would mean each node's form fits badly.
Problem 2
When validation failed, builders knew where but not what.
The original validation model - defined by the BA and engineers - worked like this: you fill in your nodes, click Validate, and any node with a problem turns red. Functional, but I watched it fall short during testing. A builder would see a node go red, know something was wrong there - and have no way to know what. Red said "wrong, here." It didn't say "wrong, how." So they'd open the node and hunt.
Those two problems
"consistency across difference, and errors you can't act on - are what my design actually had to solve. The next section is how."
06 - The decisions
Each screen pinned to
a decision - never a tour
Two design decisions did the real work. Both came from the same instinct: when you can't reduce the complexity, you make it legible.
DECISION 1
One consistent pattern across every node type
Different nodes need different inputs - but I designed them as one system, not a family of unrelated forms. Every node-configuration modal shares the same structure: same layout logic, same field grouping, same placement of name, description, icon, and the technical inputs below. What changes is only what the node genuinely requires - a Network exposes address/gateway/DHCP/used-IPs; a Server exposes assets and flavor; an end device its own set.
This was deliberate systems thinking, not convenience. A Scenario Builder configures many nodes in a sitting; if each one looked and behaved differently, every node would carry a small relearning cost. By holding the structure constant and letting only the fields vary, the builder learns the pattern once and applies it everywhere. Different purpose, different icon, same skeleton - because they're parts of one system, not different items.
"Notably, I didn't engineer that parallel - both surfaces, built on the same design system and the same bias toward simple flows, converged on the same structure. That's what a healthy design system is supposed to produce: consistency you don't have to force.
It's the same principle underneath the event system on this platform: a shared backbone, with variation only where the content demands it."
DECISION 2
A consolidated error panel - born from watching builders get stuck
This is the decision I'd most want to be judged on, because it came from an observation, not an assumption.
The validation model itself wasn't mine - the BA and engineers had defined it: fill in the nodes, click Validate, and any node with a problem turns red. During validation testing, I watched where that broke down. A builder would see a node glow red, understand that something there was wrong - and have no way to know what. The red state communicated location and nothing else. So they'd open the node and dig through its fields looking for the offending one.
The gap was specific: builders knew where an error was, but not what it was.
So I introduced a consolidated error panel - a single place that lists every validation error and the reason behind it, grouped per node ("Router 1 - 6 errors," and what each one is). Instead of decoding red icons one node at a time, a builder gets one readable audit of everything wrong and why, and can work straight down the list.
I chose aggregation over inline annotation on purpose. On a dense topology, errors scattered across nodes and edges become visual noise you have to hunt through; a consolidated, reasoned list turns "something's wrong somewhere" into "here is exactly what to fix, in order." It pairs with the existing Validate action - you build, you check when ready, and when you check, you get an answer you can act on rather than a map of red dots.
07 - The solution
Walking the configuration as a Scenario Builder experiences it
Each screen carrying the decision behind it.
The consistent node-config pattern.
Each node opens the same kind of modal with the same structure; only the fields differ by node type. This is the consistency decision made visible — learn one, know them all.
Validation surfaced as a readable audit.
When a builder validates, errors don't just light up nodes — they resolve into a grouped, reasoned list. This is the "where and what" decision: location on the canvas, explanation in the panel.
Constraints at the point of entry.
Edge cases the requirements didn't mention, caught where they happen — so a builder doesn't discover them only at validation time.
Phase 3 Review & Submit Page
Review & Submit. The final phase, where a scenario is finalised: edit details, add tasks and questionnaire, review the topology, upload supporting docs, and submit. This phase is similar is later on introduced to the event with the same workflow and same design with different Functionality while keeping the structure the same.
Those two problems
"consistency across difference, and errors you can't act on - are what my design actually had to solve. The next section is how."
08 - Outcome
Validated with the people who'd live in these forms
The node-configuration system shipped as part of the platform and was validated with the actual Scenario Builders - the role that does this work day to day. That's the right audience: not a proxy, but the people who'd live in these forms.
The validation testing is also where the most important design improvement came from - the consolidated error panel was a direct response to watching a Scenario Builder hit the "where but not what" wall. So the system didn't just pass testing; testing actively shaped it. The error-panel decision exists because of what that session surfaced, which is the loop a designer wants: observe a real user, respond to the specific failure, fold it back in.
09 - What I'd do differently
Validated with Experts only;
not yet stress-tested with newcomers
The honest limit: validation happened with Scenario Builders who are already technical and fluent in how networks and the platform work. That tells me the system holds up for its core user - but it doesn't yet tell me where a less experienced builder, or someone new to the role, would stumble.
So the next step I'd take is guerrilla-testing the configuration flow with builders who don't already know it - watching for where the consistency helps, where the error panel genuinely unblocks someone versus where they still get stuck, and which edge cases I didn't anticipate.
That gap - validated with expert builders, not yet stress-tested with new ones - is the honest boundary of what I know today, and it's where I'd take this next.
10 - What I owned
To be precise about contribution on a collaborative, specialist-led build
Mine
Defined by others
Node behaviour and validation requirements and the underlying validation mechanic.
Second designer
Owned the Phase 2 build.
Designed from raw requirements with no proposed UI, across a ~9-month effort involving networking engineers and OpenStack infrastructure - which is to say, a real technical product, designed in close partnership with the people who defined its domain.