CSI case study

SUMMARY.md

@@ -12,6 +12,7 @@
   - [Collaborative Digital Training](case-studies/CDT.md)
   - [My Best Life](case-studies/MBL.md)
   - [Tech vs. Abuse](case-studies/TvsA.md)
+  - [CyberSafeIreland](case-studies/CSI.md)
 
 ## Exercises
 

case-studies/CSI.md

@@ -0,0 +1,50 @@
+---
+description: >-
+  CyberSafeIreland (CSI) sent a brief through Tech for Better to develop a 'cybersafety' self-assessment tool for primary schools in Ireland.
+---
+
+# Case Study: CyberSafeIreland
+
+## Introduction
+
+While not strictly a Tech for Better project in that it was eventually completed independently of Founders and Coders, the brief did come through the Tech for Better pipeline and required a design sprint to define certain aspects of the tool. This is a useful case study because it shows a lighter design sprint structure which we tailored knowing that the solution idea was already largely defined.
+
+This sprint structure was created to define and ensure that the user journeys of the tool could be usability tested, to define the look and feel of the tool, and to further introduce the Product Owner, project and user personas to the dev team. After the sprint a prototype version of the tool was created which was usability tested and updated before development began.
+
+For the 'Consensus' exercise we discussed each themed group of how might we questions in turn, working out what the Product Owner required from each with input from the dev team. Satisfied that we understood the goals and users of the tool we could move on to defining its look and feel. This was chosen over a dot voting system as the Product Owner was able to make final decisions on how the tool would respond to the how might we questions.
+
+The Discovery and Definition workshops were attended by the Product Owner and dev team. They were three hours long each. Prototyping was then completed by the dev team, and usability testing by the Product Owner.
+
+---
+
+## Structure
+
+### Discovery
+* User personas
+* Mapping
+* How Might We
+* Theming How Might We Questions
+* Consensus
+* User Stories
+
+### Definition
+* Lightning demos
+* 3 part Sketching
+    * Ideas
+    * Crazy 8s
+    * Solution Sketch
+* User flow
+
+### Prototype
+* Create a prototype (figma)
+* Usability testing
+
+---
+
+## Reflections
+
+* A simple design sprint is an excellent way to get to know a Product Owner and unpack the goals and users of their product at the start of a project. Even if the solution is largely worked out it is useful to do some discovery exercises for better understanding or to identify risky assumptions. 
+* Lightning demos were particularly useful here because it gave the Product Owner a simple visual way to get across the design styles they wanted the tool to follow. The dev team were able to explain design and accessibility conventions, and from a series of styles displayed in existing products it was quick and easy to agree on some style rules to design to.
+* The 'Concensus' exercise worked well because the Product Owner was able and willing to make specific choices around questions that had been raised through the Discovery workshop. With a larger sprint team or without someone in the position to make a final decision this discussion could become lengthy or hard to resolve. In this case it may be better to use a 'Heatmap' or 'Dot Voting' exercise to formulate thes decisions.
+* The Product Owner was able to see value in the design sprint, and will apply its techniques to further product development in future.
+* This was a short, sharp sprint. Even so we managed to gather all the information required to make a testable prototype.