122
Sensemaking in Safety Critical and Complex Situations
1. Understand the context of use by field studies and interviews with the users.
2. Specify the user and organisational requirements.
3. Produce a design solution, this will be the prototype.
4. Evaluate the design against requirements. Here, the prototype is tested on
the end users.
The findings are then brought into a new iteration of the design process resulting in
a new, improved prototype. The process is then iterated until the application meets
the requirements.
teSt area anD uSer grouP
Before a user group could be recruited, a location had to be decided. One way would be
to look for an area with a large amount of leisure boat traffic. However, the availability
of very detailed bathymetry was necessary and a difficult problem. The Norwegian
Hydrographic Office offered an area in Søre Sunnmøre, a district south of Ålesund on
the Norwegian west coast which had been declassified and could be used. A central
municipality in this area was Ulsteinvik, which was to become the centre of the project. We needed to find local leisure boat mariners. A letter was sent out to 30 pleasure
craft clubs in the district informing about the project and asking about participation
in development and testing of the application. Unfortunately, only six leisure boaters
responded, all male, all relatively experienced and in the age group of 60+. But luckily
for us, these end users have helped us a lot with testing during the years.
unDerStanD the context of uSe anD uSer requirementS
A first focus group meeting was held in Ulsteinvik in January 2017. The users were
interviewed about their experience with leisure craft navigation and the proposed
concept of using a smartphone as a means of preventing groundings was discussed.
The group concluded that the idea was interesting and that there was a need for a
safety device alarming if the boat was approaching unsafe depths. The group agreed
on a prioritised list with different possible features ( Porathe & Ekskog, 2018).
Alarm
The phone should sound an alarm a configurable time before the boat went aground.
The application should be automatically started in the background when a boater
steps onto his boat, so that he or she does not forget to start the application. The time
should be short so that the number of false alarms in narrow archipelagos would
not be annoying and thus making boaters turn off the alarm ( which is often the case
with the look- ahead-sector in professional shipping). The default setting was agreed
as 30 seconds, and the procedure of the boater should be to immediately stop the
boat on alarm. The alarm should be silenced by picking up the phone and clicking
on the warning icon shown. The alarm should also be silenced by slowing down to a
configurable maximum speed ( default three knots) to allow boats to make landfalls
or approach a jetty without getting an alarm.
Sensemaking in Safety Critical and Complex Situations
1. Understand the context of use by field studies and interviews with the users.
2. Specify the user and organisational requirements.
3. Produce a design solution, this will be the prototype.
4. Evaluate the design against requirements. Here, the prototype is tested on
the end users.
The findings are then brought into a new iteration of the design process resulting in
a new, improved prototype. The process is then iterated until the application meets
the requirements.
teSt area anD uSer grouP
Before a user group could be recruited, a location had to be decided. One way would be
to look for an area with a large amount of leisure boat traffic. However, the availability
of very detailed bathymetry was necessary and a difficult problem. The Norwegian
Hydrographic Office offered an area in Søre Sunnmøre, a district south of Ålesund on
the Norwegian west coast which had been declassified and could be used. A central
municipality in this area was Ulsteinvik, which was to become the centre of the project. We needed to find local leisure boat mariners. A letter was sent out to 30 pleasure
craft clubs in the district informing about the project and asking about participation
in development and testing of the application. Unfortunately, only six leisure boaters
responded, all male, all relatively experienced and in the age group of 60+. But luckily
for us, these end users have helped us a lot with testing during the years.
unDerStanD the context of uSe anD uSer requirementS
A first focus group meeting was held in Ulsteinvik in January 2017. The users were
interviewed about their experience with leisure craft navigation and the proposed
concept of using a smartphone as a means of preventing groundings was discussed.
The group concluded that the idea was interesting and that there was a need for a
safety device alarming if the boat was approaching unsafe depths. The group agreed
on a prioritised list with different possible features ( Porathe & Ekskog, 2018).
Alarm
The phone should sound an alarm a configurable time before the boat went aground.
The application should be automatically started in the background when a boater
steps onto his boat, so that he or she does not forget to start the application. The time
should be short so that the number of false alarms in narrow archipelagos would
not be annoying and thus making boaters turn off the alarm ( which is often the case
with the look- ahead-sector in professional shipping). The default setting was agreed
as 30 seconds, and the procedure of the boater should be to immediately stop the
boat on alarm. The alarm should be silenced by picking up the phone and clicking
on the warning icon shown. The alarm should also be silenced by slowing down to a
configurable maximum speed ( default three knots) to allow boats to make landfalls
or approach a jetty without getting an alarm.