100,000+

100,000+

potential reach
potential reach

Increasing cyber resilience to a potential audience of over 100,000 education professionals at over 2,500 schools across New Zealand.

8.46 / 10

8.46 / 10

average response for "How valuable?"
average response for "How valuable?"

Teachers rated it highest at 8.73. Across all roles, participants found the game easy to follow (4.54/5) and said it prompted new thinking about their school's cyber readiness (4.32/5).

First-of-its-kind

First-of-its-kind

in New Zealand
in New Zealand

The first cybersecurity tabletop exercise designed specifically for New Zealand schools — bringing an industry-standard format to the education sector for the first time.

70 / 72

70 / 72

schools rated the experience 7 or higher
schools rated the experience 7 or higher

The most valued aspects of the session were discussion and collaboration — with 30+ participants specifically calling out the conversations it sparked across different school roles.

In a nutshell

Glitch! is a cybersecurity tabletop game created for the Ministry of Education to help school staff across New Zealand prepare for cyber incidents.

Rather than delivering guidance through static policy or training, the project explored how a physical, discussion-led game could build shared understanding, clarify roles, and give non-technical staff confidence to participate meaningfully in a cyber response.

Client

Client

Ministry of Education

Role

Role

Lead researcher, UX and content designer

Year

Year

2025

The challenge

Designing for every school.

From rural schools with limited infrastructure to large institutions with dedicated IT teams, the game needed to be relevant across different contexts and cybersecurity confidence levels.

From rural schools with limited infrastructure to large institutions with dedicated IT teams, the game needed to be relevant across different contexts and cybersecurity confidence levels.

From rural schools with limited infrastructure to large institutions with dedicated IT teams, the game needed to be relevant across different contexts and cybersecurity confidence levels.

Translating cyber-speak.

Industry frameworks and technical terminology had to be stripped back, reframed, and rewritten into plain, actionable language that felt relevant to everyday school roles, not just IT specialists.

Industry frameworks and technical terminology had to be stripped back, reframed, and rewritten into plain, actionable language that felt relevant to everyday school roles, not just IT specialists.

Industry frameworks and technical terminology had to be stripped back, reframed, and rewritten into plain, actionable language that felt relevant to everyday school roles, not just IT specialists.

A new kind of learning experience.

Glitch! had to introduce the common cybersecurity industry tabletop format to the education sector in a way that felt credible, purposeful, and easy to run within real school constraints.

Glitch! had to introduce the common cybersecurity industry tabletop format to the education sector in a way that felt credible, purposeful, and easy to run within real school constraints.

Glitch! had to introduce the common cybersecurity industry tabletop format to the education sector in a way that felt credible, purposeful, and easy to run within real school constraints.

The approach

This project was a two-person collaboration with a visual designer.

I led the research, content design, and UX: designing the core function of the game, testing and iterating on digital and physical prototypes, and authoring and refining the majority of game content through multiple iterations to ensure the experience was engaging, understandable, and practical for staff at all levels.

The concept

Ideation: The first concept

Our initial ideation explored a traditional game format with points, tokens, and layered mechanics like specific roles with specific skillsets.

Mockup of our original proposal, showing a top-down view of what the game would look like in action (Miro)

We also considered the physicality of the game: what makes board games fun?

Having a tactile card element was important to our game for engagement. We started with two types of handheld cards: one for characters, who could represent different roles and skillsets, and a set of Chance cards, which could introduce an element of unpredictability that’s common in cybersecurity incidents.

Character and Chance cards (Miro)

Desktop research: What the industry told us

Unfortunately, desktop research into existing cybersecurity tabletop exercises revealed that industry-standard formats were dry, text-heavy, and assumed significant technical knowledge…a clear signal that directly transposing this format for a non-technical school audience wouldn't work.

Our client also flagged that our initial concept didn't align with the industry standard they'd expected — which, combined with our research findings, prompted us to reconsider the concept entirely.

Refining the concept: Stripping it back

With a much clearer idea of the cybersecurity industry’s standard for this kind of activity, we pulled back the complex mechanics of our original idea and redeveloped our concept into a simple, step-by-step, discussion-led game.

This led us to a flippable tent-card format, which supported the discussion and pacing of the game by allowing groups to gather around a shared artefact and focus on one scenario step at a time.

To keep the exercise engaging, we retained an element of unpredictability through Inject Cards, introducing realistic curveballs without overwhelming beginners.

A low-fidelity mockup of our proposed concept, showing mid-gameplay interaction with a timer and scenario progression.

The flippable tent-card format that allowed us to take players through the scenario step-by-step.

A low-fidelity mockup of our proposed concept, showing mid-gameplay interaction with a timer and scenario progression.

The flippable tent-card format that allowed us to take players through the scenario step-by-step.

The research

1:1 usability sessions: Testing with real school staff

I ran remote 1:1 sessions using a high-fidelity digital prototype with principals, teachers, and IT leads. This surfaced where content felt overly technical, scenarios lacked realism, and the flow and timing of the exercise broke down.

🤔 Why digital? — We were designing for every school in New Zealand. In-person testing would have been expensive, and skewed heavily towards larger schools with strong IT capability who needed this game the least. Remote sessions over Zoom let us hear from rural schools, non-technical staff, and roles I wouldn't have accessed otherwise. The decision to go remote was pragmatic, but it made the research better.


Our digital prototype in action.

Observational research: Live conference testing

I then observed gameplay with the physical prototype during two live workshops at an education conference, with over 70 people in groups of 4–5 people.

I learned how different roles engaged in discussion, how a strong facilitator (or lackthereof) could affect momentum, and where ambiguity stalled decision-making. A short paper survey captured perceptions of clarity, value, and ideas for improvements.

My colleague and I attended the conference so we could observe how users would actually play the game.

Our client facilitating the game at an educational conference in Auckland.

The paper prototype tent card format we tested, with 4 Inject cards spread out.

My colleague and I attended the conference so we could observe how users would actually play the game.

Our client facilitating the game at an educational conference in Auckland.

The paper prototype tent card format we tested, with 4 Inject cards spread out.

The changes

The changes

Clarified scenario flow

Clarified scenario flow

"Injects" is standard tabletop terminology. My hypothesis was that using these as the scenario steps would spark curiosity, but it sparked confusion instead. Starter questions were too technically specific, which stalled discussion.

I reworked scenarios into clearly numbered steps and streamlined prompts to reduce cognitive load. Players stopped getting stuck on terminology and started focusing on what they actually knew: who to contact and how to respond.

Before

Each step in a scenario is called an "Inject" and has 3-4 starter questions to prompt discussion.



After

The scenarios were rewritten to be more compelling and the starter questions were simplified—with specific prompts being moved to a dedicated facilitator guide.




"Injects" is standard tabletop terminology. My hypothesis was that using these as the scenario steps would spark curiosity, but it sparked confusion instead. Starter questions were too technically specific, which stalled discussion.

I reworked scenarios into clearly numbered steps and streamlined prompts to reduce cognitive load. Players stopped getting stuck on terminology and started focusing on what they actually knew: who to contact and how to respond.

Before

Each step in a scenario is called an "Inject" and has 3-4 starter questions to prompt discussion.



After

The scenarios were rewritten to be more compelling and the starter questions were simplified—with specific prompts being moved to a dedicated facilitator guide.




"Injects" is standard tabletop terminology. My hypothesis was that using these as the scenario steps would spark curiosity, but it sparked confusion instead. Starter questions were too technically specific, which stalled discussion.

I reworked scenarios into clearly numbered steps and streamlined prompts to reduce cognitive load. Players stopped getting stuck on terminology and started focusing on what they actually knew: who to contact and how to respond.

Before

Each step in a scenario is called an "Inject" and has 3-4 starter questions to prompt discussion.



After

The scenarios were rewritten to be more compelling and the starter questions were simplified—with specific prompts being moved to a dedicated facilitator guide.




Reframed response guidance

Reframed response guidance

Similarly, the original response guide was meant to provide players with a practical, actionable checklist of cybersecurity practices to compare themselves to. This was another moment of too much technicality, and within the context of the game it was easy to dismiss them.

I replaced the overly-detailed response frameworks with more concise pages focused on a prioritised set of preventative actions, real-world context, and practical takeaways.

Before

A Response Guide (after each step) and a Response Summary (after each scenario) with best practices categorised by capability.


After

Removed Response Guide title after each step to make it feel more natural, added a real-life example, and simplified it into 3 key actions. Renamed Response Summary, removed the block of text, and recategorised the actions by stage.


Similarly, the original response guide was meant to provide players with a practical, actionable checklist of cybersecurity practices to compare themselves to. This was another moment of too much technicality, and within the context of the game it was easy to dismiss them.

I replaced the overly-detailed response frameworks with more concise pages focused on a prioritised set of preventative actions, real-world context, and practical takeaways.

Before

A Response Guide (after each step) and a Response Summary (after each scenario) with best practices categorised by capability.


After

Removed Response Guide title after each step to make it feel more natural, added a real-life example, and simplified it into 3 key actions. Renamed Response Summary, removed the block of text, and recategorised the actions by stage.


Similarly, the original response guide was meant to provide players with a practical, actionable checklist of cybersecurity practices to compare themselves to. This was another moment of too much technicality, and within the context of the game it was easy to dismiss them.

I replaced the overly-detailed response frameworks with more concise pages focused on a prioritised set of preventative actions, real-world context, and practical takeaways.

Before

A Response Guide (after each step) and a Response Summary (after each scenario) with best practices categorised by capability.


After

Removed Response Guide title after each step to make it feel more natural, added a real-life example, and simplified it into 3 key actions. Renamed Response Summary, removed the block of text, and recategorised the actions by stage.


Defined roles and instructions

Defined roles and instructions

The role of a facilitator was critical to the flow of the game; regardless of their existing cybersecurity knowledge, a strong leader was able to drive deeper discussions.

I introduced facilitator and notetaker roles, rewrote instructions for clarity, and added guidance on questions, timing, setup, and group dynamics so the game could run without external support.

Before

Everyone received the same instructions, with a generic "choose a role" instruction.


After

A dedicated Navigator (facilitator) guide with prompting questions for each scenario and separate instructions.



The role of a facilitator was critical to the flow of the game; regardless of their existing cybersecurity knowledge, a strong leader was able to drive deeper discussions.

I introduced facilitator and notetaker roles, rewrote instructions for clarity, and added guidance on questions, timing, setup, and group dynamics so the game could run without external support.

Before

Everyone received the same instructions, with a generic "choose a role" instruction.


After

A dedicated Navigator (facilitator) guide with prompting questions for each scenario and separate instructions.



The role of a facilitator was critical to the flow of the game; regardless of their existing cybersecurity knowledge, a strong leader was able to drive deeper discussions.

I introduced facilitator and notetaker roles, rewrote instructions for clarity, and added guidance on questions, timing, setup, and group dynamics so the game could run without external support.

Before

Everyone received the same instructions, with a generic "choose a role" instruction.


After

A dedicated Navigator (facilitator) guide with prompting questions for each scenario and separate instructions.



The retrospective

The outcome: First-of-its-kind

Glitch! launched as a first-of-its-kind cybersecurity tabletop exercise designed specifically for the New Zealand education sector. 70 out of 72 participating schools rated the experience a 7/10 or higher, with users praising how the physical format sparked collaboration across school roles.

🔗 Try the digital version of Glitch yourself!

The takeaway: Do less by doing more

Designing a physical game rather than a digital product was a unique challenge, but the biggest learning applies to both: people hate reading.

I thought robust content design could carry the game, but live conference testing revealed that even the most linear narrative still needed a strong facilitator. Simplifying the game at the expense of better supporting materials for the facilitator made it more engaging, not less.

This was hard to catch in remote testing sessions, though remote was worth it for reaching rural schools and different role types. Next time, I'd pair it with at least one in-person facilitation-focused session earlier in the process.

The impact: AI-assisted research workflows

This project served as the foundation for my featured presentation at UX Auckland (2026), where I demonstrated how leveraging Dovetail for synthesis allowed our two-person team to rapidly generate recommendations in a 4 hour (!) timeframe.

You can view that on this page, or on Youtube.



The outcome: First-of-its-kind

Glitch! launched as a first-of-its-kind cybersecurity tabletop exercise designed specifically for the New Zealand education sector. 70 out of 72 participating schools rated the experience a 7/10 or higher, with users praising how the physical format sparked collaboration across school roles.

🔗 Try the digital version of Glitch yourself!

The takeaway: Do less by doing more

Designing a physical game rather than a digital product was a unique challenge, but the biggest learning applies to both: people hate reading.

I thought robust content design could carry the game, but live conference testing revealed that even the most linear narrative still needed a strong facilitator. Simplifying the game at the expense of better supporting materials for the facilitator made it more engaging, not less.

This was hard to catch in remote testing sessions, though remote was worth it for reaching rural schools and different role types. Next time, I'd pair it with at least one in-person facilitation-focused session earlier in the process.

The impact: AI-assisted research workflows

This project served as the foundation for my featured presentation at UX Auckland (2026), where I demonstrated how leveraging Dovetail for synthesis allowed our two-person team to rapidly generate recommendations in a 4 hour (!) timeframe.

You can view that on this page, or on Youtube.



The outcome: First-of-its-kind

Glitch! launched as a first-of-its-kind cybersecurity tabletop exercise designed specifically for the New Zealand education sector. 70 out of 72 participating schools rated the experience a 7/10 or higher, with users praising how the physical format sparked collaboration across school roles.

🔗 Try the digital version of Glitch yourself!

The takeaway: Do less by doing more

Designing a physical game rather than a digital product was a unique challenge, but the biggest learning applies to both: people hate reading.

I thought robust content design could carry the game, but live conference testing revealed that even the most linear narrative still needed a strong facilitator. Simplifying the game at the expense of better supporting materials for the facilitator made it more engaging, not less.

This was hard to catch in remote testing sessions, though remote was worth it for reaching rural schools and different role types. Next time, I'd pair it with at least one in-person facilitation-focused session earlier in the process.

The impact: AI-assisted research workflows

This project served as the foundation for my featured presentation at UX Auckland (2026), where I demonstrated how leveraging Dovetail for synthesis allowed our two-person team to rapidly generate recommendations in a 4 hour (!) timeframe.

You can view that on this page, or on Youtube.