Participants in a live cyber crisis exercise couldn't tell if the exercise was running, paused, or over. Facilitators were narrating the UI instead of running the scenario. I redesigned the entire TTX experience — from the state model up — across Web, iOS, and Android.
Faster
Participant orientation — facilitators reported faster onboarding for first-time and late-joining participants
Drop
Support overhead — noticeable reduction in "What should I do now?" questions during live exercises
$3.25M+
ARR contribution — AI-assisted TTX Player became a key driver in the CYGNVS mobile offering
Reusable
Platform pattern — state-aware navigation formalised as a reusable interaction pattern for future features
Role
Lead Product Designer
Product
CYGNVS TTX — Cyber crisis tabletop platform
Scope
TTX Room · Inject system · Navigation · State model
Team
PM · Security · Engineering · Mobile · Platform
01
Participants in a live cyber crisis exercise couldn't tell if the exercise was running, paused, or over. Facilitators were narrating the UI instead of running the scenario. I redesigned the entire TTX experience — from the state model up — across Web, iOS, and Android.
02
A tabletop exercise (TTX) is a structured rehearsal for a cyberattack. Leadership, legal, comms, and IT teams play through a realistic scenario under pressure — so they know their roles before a real incident hits. CYGNVS ran these exercises for enterprise clients. The platform had four surfaces: the TTX Room, an Inject list, Comments, and Messages. The problem was systemic across all of them.
The core failure
Research with facilitators, SOC leads, and exercise participants surfaced three patterns — all with the same root cause: state was invisible.
What made this hard to solve:
State lived in the backend only
Exercise state was tracked server-side but never surfaced in the UI. There was no visual contract between what the system knew and what the participant saw.
Cross-platform parity didn't exist
Web and mobile showed the same exercise differently. A facilitator explaining the flow on web couldn't transfer that to a mobile participant without re-explaining.
Injects had no sequence or status
The inject list showed all injects at once with no clear ordering, active state, or indication of what was "live" vs upcoming vs already actioned.
24/7 operation, no downtime tolerance
CYGNVS ran live client exercises continuously. The redesign had to ship incrementally — no big-bang cutover, no disruption to running exercises.
03
The instinct was to redesign the navigation. I pushed back — you can't design the right navigation without first defining what states the system can be in. I mapped the exercise lifecycle as an explicit state machine and made that the shared contract for design, engineering, and product.
Discover
Map exercise behaviour across roles, entry points, and platforms
Model
Define the 3-state lifecycle, transitions, triggers, and what each state unlocks
Prototype
Design TTX Room, inject system, and navigation tied to state across Web + Android + iOS
Validate
Test in pilot exercises; measure orientation time and facilitator load
Each decision was deliberate — not just "what looks good" but "what constraint does this solve and what does it cost."
Make exercise state explicit with a persistent chip + bottom sheet
Participants need to know state without asking anyone
Tradeoff accepted
The chip and bottom sheet cost vertical space on a small mobile screen. Accepted this to eliminate all ambiguity — a smaller content area is better than a confused participant.
Impact
Participants self-oriented from the state chip within seconds of joining. Facilitators stopped narrating "we're about to start" or "the exercise is live."
Bottom sheet carries the primary orientation message per state
One persistent place that answers "what should I do right now?"
Tradeoff accepted
The bottom sheet is always visible, which reduces content area. Tested with a dismissable version — participants dismissed it and then asked "what should I do?" thirty seconds later. Non-dismissable won.
Impact
"Exercise not started — no action needed" and "Exercise in progress — start responding to injects →" gave every participant the same instruction at the same time.
Navigation adapts to exercise state — items appear and disappear
Don't show destinations that don't apply to the current state
Tradeoff accepted
Dynamic navigation required tight coupling between backend state events and the UI layer. Worked closely with engineering to ensure state changes propagated to nav without performance regressions.
Impact
Messages tab disappears when the exercise completes — participants aren't presented with channels that serve no purpose after the scenario ends. Nav reflects reality.
Inject list shows sequence number, not just inject title
Progress through the exercise should be visible at a glance
Tradeoff accepted
Sequential numbering (7/9) works for linearly structured exercises. For branching exercises, this framing is less clear. Scoped to linear TTX flows for v1.
Impact
Participants could tell how far through the scenario they were without asking the facilitator. Late joiners understood context immediately from the progress fraction.
Active inject highlighted — not buried in the list
The most important inject right now should require zero scanning
Tradeoff accepted
Visual differentiation of the active inject (blue border, filled circle) creates a denser-looking list. Tested alternatives — separate tabs, auto-scroll, modal overlay. Inline differentiation with clear status won for simplicity.
Impact
"In Progress" with a "View →" CTA gave participants one clear next action without requiring them to scan the whole list to find where they were.
State patterns standardised across Android and iOS
Facilitators explain the experience once, not twice
Tradeoff accepted
Standardised state chips and bottom sheets across platforms means some native Android conventions (e.g. Material snackbars) were set aside in favour of a shared mental model.
Impact
Leadership participants moving between their laptop and phone saw the same state chips, the same language, and the same bottom sheet copy. One mental model for the whole exercise.
Operating rhythm
04
Data from product analytics, SOC operational reports, facilitator debriefs, and pilot exercise observations. Qualitative signals from internal dogfooding and live client exercises.
| Metric | Before | After | Change |
|---|---|---|---|
| Participant orientation time at exercise start | Required facilitator narration: “We’re starting now” | State chip + bottom sheet — self-oriented without facilitator | ↓ sig. |
| Late joiner onboarding | Needed 1:1 explanation to understand current exercise state | State chip visible immediately on join; bottom sheet gives current instruction | ↓ sig. |
| Facilitator drag (time spent narrating product) | Significant — facilitators answering "where should I be?" throughout | Noticeably reduced — UI answered orientation questions | ↓ sig. |
| Analyst satisfaction with triage workflows | 3.0 / 5 | 3.6 / 5 | ↑ 18% |
| Median time-to-triage critical alerts | 25–30 minutes | 17 minutes | ↓ 32% |
| Cross-platform consistency (facilitator training time) | Separate explanation needed for Web vs Android users | Single explanation — same state chips + bottom sheet copy across platforms | ↓ sig. |
TTX Room — before vs after (mobile)Left panel: old experience — no state chip, no bottom sheet, full inject list unordered. Right panel: redesign — state chip top-left, bottom sheet with contextual instruction, inject list with sequence numbers and active state highlighted.
I no longer have to narrate where we are in the exercise — the UI does that for me.
TTX Facilitator — post-pilot debrief
It's much easier to see what's live and what's just context.
Exercise Participant — pilot session
State cues feel consistent whether I'm on my laptop or my phone.
Leadership team member — cross-platform review
05
Starting with the state model rather than the screen was the right call — and the hardest sell. "We're redesigning navigation" is a familiar brief. "We need to define the exercise state machine before we touch any UI" takes more convincing. But that contract is what made it possible to redesign four surfaces consistently without each one being its own separate negotiation.
The non-dismissable bottom sheet was counterintuitive but correct. Every time we tested a dismissable version, participants dismissed it and then asked for the information it contained. Persistent contextual instruction beats a cleaner screen. Using the state model as the weekly triad meeting artefact — not Figma frames — kept decisions grounded in system behaviour rather than visual preference.
Facilitator tools came too late
Treat system state as a first-class design object
State and transitions aren't engineering details — they're the primary design material for any workflow product. Design navigation, content visibility, and available actions around state first. Screens are a consequence of state, not the other way around.
Design for fast orientation, not just task completion
"What should I do right now?" is a UX failure, not a user education problem. If the answer requires a facilitator to speak it out loud, the product hasn't done its job. Orientation time is a measurable outcome worth designing for explicitly.
Share contracts, not just screens
A state machine reviewed weekly by design, PM, and engineering is more durable than a Figma prototype handed over at the end of a sprint. It survives scope changes, release trains, and personnel turnover because the behaviour is agreed, not just illustrated.
Favour patterns teams can reuse
The state chip, bottom sheet, and inject status patterns were built on the existing CYGNVS design system — not invented for this project. Every novel pattern is a maintenance cost. Extension is cheaper than invention.
I'm happy to walk through this case in detail, share additional artefacts, or demo the state model in a live conversation.