Safety Observation : Human-Centred Design for Software
A recent fleet-wide meeting was used, in part, to discuss software changes that would be implemented over the next year. These included software packages for payroll, human resources, safety management system and procurement/purchasing/stock management. When shoreside technical management was queried regarding integration of these packages with widely used spreadsheets on vessels for port paperwork, the gulf in knowledge between Port Paperwork as Done (PPaD) and Port Paperwork as Imagined (PPaI) was immediately evident. The software package that technical management thought was in use for generation of this critical and closely scrutinized paperwork was not used due to its cumbersome and less-than-agile structure. Instead, a package of spreadsheets generated by ships’ captains was in use that could be manipulated and changed as forms for various ports were added or changed.
When again asked if certain functions would be available, the answer from technical management was that the end users would be queried before implementation onboard to find out what features were desired. Identifying the end users’ requirements so close to the implementation of these software packages displays a lack of concern for the end user’s needs. Project management best practices and the IMO MSC.1/Circ.1512 Guideline on Software Quality Assurance and Human-Centred Design for E-Navigation identifies defining stakeholder requirements as Stage 1 : Concept Development (see attached diagram). While the IMO circular is designed for the development of e-navigation software, it provides a good structure for the development of other software from a human-centred design perspective.

While late in the process, it is recommended that technical management engage stakeholders (vessel crews) in the development of these software packages and future software packages to ensure suitability for use onboard. Failure to do so may result in increased administrative burden on vessel crews, frustration due to cumbersome and less-than-agile software and widely used “work arounds” such as the spreadsheets in use today to generate port paperwork.
Additional Reading and Links
Developer User Stories: Guide for Software Development Teams

And somewhere in the process, light dawned on Marble head.