< --- Back to Portfolio


Para-Stroke is a theoretical solution to identify stroke symptoms in a near-future scenario where technology has advanced in battery life, machine learning and detection algorithms. Para-Stroke would run on existing ambulance Mobile Data Terminals (MDTs) to augment data from Stroke Detector to paramedics received directly from monitoring potential stroke suffers, with the ability to forward the information on the EDs. 


Treatment seeking is delayed as patients do not recognise the symptoms of stroke, and/or do not appreciate stroke is a medical emergency.  The gold standard treatment for ischaemic stroke is a drug called tissue plasminogen activator (tPA), which acts to dissolve the clot and restore blood flow to the affected area. This drug can only be administered within 4.5 hours of stroke onset, after which time is loses effectiveness and risks begin to outweigh benefits of administration; risk of haemorrhagic conversion increases, significantly worsening prognosis. Despite this time pressure, only 39% of patients arrive at hospital within 4.5 hours of onset, with pre-hospital delays remaining a key challenge. Further, time of onset of symptoms is often unknown as the patient is unable to report when they were last well, with significant implications for the types of treatment they will be eligible to receive. 

UX Process

The design process for the Para-Stroke solution encompassed the following steps:

1.     Documenting the current flow of events when a stroke occurs from experts;

2.     Identify users in this process, conducting research and interviewing users to create Personas;

3.     Documenting current workflow from users point of view;

4.     Identifying pain points;

5.     Identifying opportunities;

6.     Identifying user stories to express requirements;

7.     Documenting design assumptions, and;

8.     Creating low-fidelity wireframes and the system design.  


From this process the following Personas were identified:

  • Michael the Paramedic;  
  • Jean the Potential Stroke Sufferer (PSS);  
  • Ellie the ER intern;
  • Bruce the Stoke Consultant, and;
  • Louise the ER Triage Nurse.  

From the current process the following pain points have been identified:

  • Michael only gets information that the 000 operator receives. Often this is only address, age, sex and the presenting problem (i.e. stroke)
  •  Information received does not consistently include anything else
  •  Michael may not know when the patient was ‘last well’ therefore there is insufficient information about time onset to radio to ED for quick decision making regarding treatment
  • All information is radioed to ED thusly may be inaccurate and cannot be retrieved to confirm   

In response to the pain points, opportunities were identified:

  •  If the PSS is prompted to call an ambulance all additional information can be logged and made available to Michael
  • Time-stamped log of symptoms detected and prior behaviour could assist doctors in determining time of stroke onset.  

Based on Michael’s Needs, User stories were created.

  • Michael needs to receive additional information about the PSS so that he can target his questioning to rule out other causes for stroke symptoms.
  • Michael needs additional information to be obvious so that he can quickly assess the patient.
  •  Michael needs to send information to the ED so that they can quickly get the PSS treatment. 

Low-Fidelity Prototype

Para-Stroke is integrated into the existing MDT’s. Existing information regarding the address, patient gender, age and symptoms are included.

The MDT’s provide route information to the ambulance on where they are and where they are going.

When the pickup address for the patient matches the address of a record in Stroke Eye, Para-Stroke prompts paramedics that there is extra information available.

Selections have being designed to have specific affordances so Michael knows how they can be used: radio buttons were selected for gender as only one may be selected and checkboxes for symptoms logged as PSS can record multiple systems.  

All of these fields are updatable if they are incorrect or new symptoms now exist.

This screen enables the paramedic to go back to the map view by clicking <Back - providing a simple exit for the user if they mistakenly came to this screen, enabling user control and freedom

If yes is selected for drugs or alcohol the paramedic must enter a free text description relating to this. They cannot proceed without providing this information; Para-Stroke will not enable them to do so, acting as error prevention.

When the paramedic selects ‘Send to ED’ a message displays that the report has been sent to the ED that they are en route to

This adheres to Jakob Neilson’s usability heuristic “visibility of system status” by providing feedback; Michael is told that the system did something, sending the report to the ED, rather than leaving him to wonder regarding the system responsiveness.  

Clicking OK automatically takes the user back to the map view, now showing the ED and the route to the ED.

This screen displays that the report was sent to the ED and they can view this report if necessary. The system presents the report status enabling at a glance assessment that the report was submitted so, with everything else going on, Michael doesn’t need to recall whether he sent the report - he can easy recognize that he did.