Designing a set up phase where creators can create topology by drag and drop Nodes and Configure this.
INTRODUCTION
01
THE PROJECT
Created a clear workspace for configuring live cybersecurity on OpenStack.
My Role
Product Designer (Phases 1 & 3), collaborating with 2 BAs, 4-5 network engineers, and 4 developers.
STATUS AND TIMELINE
~9 months from discovery to shipping.
THE IMPACT
Launched a config system that removed ‘error hunt’ for Scenario Builders, using one UI for six node types.
PROBLEM
02
Node types need specific inputs. A Router needs a name, IP, MAC, and interfaces; a Network needs a gateway and DHCP.
Get one input wrong, and the entire cyber-range environment fails to stand up.
Should we create six separate forms, causing user relearning, or one rigid template that doesn’t fit well?
CONSTRAIN
03
Cybersecurity analysts set fields and validation rules based on cyber-range platforms. Complexity could not be changed.
Since I couldn’t remove the complexity, the only lever left was the experience—how inputs are grouped, how nodes maintain familiarity, and how mistakes surface.
Analysts and BAs defined what the system must do; I owned how a human actually does it.
TRADE OFFS
04
The validation model turned bad nodes red. Builders saw red and knew the error, but didn’t know what was wrong. They had to open the node and hunt for the mistake.
I actively chose not to rely on standard inline error text. On a dense topology canvas, scattered errors become visual noise. A builder doesn’t need to hunt through a map; they need a checklist.
THE SOLUTION
04
SCREEN 01
A clean canvas where builders can drag nodes, connect topologies, and trigger system-wide validation when ready.
SCREEN 02
I designed a single structural skeleton applied across Networks, Routers, Servers, and End devices. Only the specific input fields swap out. The builder learns the layout logic once and applies it everywhere.
SCREEN 03
I replaced the ‘red node’ hunt with a single, grouped sidebar list of every error and its specific reason (e.g., Router 1 — IP address error; Network — missing gateway). Clicking the error navigates the user directly to the broken field.
SCREEN 04
Implemented required-field cues, character limits, and format hints to catch edge cases before the user hits validate.
SCREEN 05
A dedicated step to review the topology, upload documentation, attach questionnaires, and finalize the scenario.
THE SOLUTION
04
This architecture was tested in a real deployment. It was reused in the CTF module for a live competition at IIT Delhi, supporting 150 students.
The system was shaped by testing. The error panel emerged from observing a Scenario Builder struggle with the validation model.
reduction in scenario configuration time
decrease in failed OpenStack environment spin-ups
Validation was done with expert Scenario Builders. I need to test this flow with newcomers to see if the ‘learn one node, know them all’ design intent holds for first-time users.