There are millions of commercial, naval and pleasure vessels and other marine assets in service across the globe at any one time, with a multitude of local and global regulatory systems governing their safety and usage.
Lloyds Register of Shipping, formed in 1760, are a large engineering organization with charitable status and a commercial wing in the business of classifying, certificating and surveying ships and marine shipping assets.Put simply, the operation can be likened to an MOT system, but for ships!
I worked alongside two other UXer’s, each of us taking on adjacent workstreams with a team of round 15 including PM’s, BA’s, data analysts, systems architects and stakeholders from the business. My main activities over the period of the project were:
The technology in use by Lloyds to create and maintain shipping asset records had been built up slowly over many, many years and consisted of a variety of autonomous systems including databases of various flavours, old legacy mainframe systems and even paper-based in some cases.
Infosys were engaged to design and engineer a brand new system from the ground up. This would involve significant business and operational transformation as well as brand new technology.
Each workstream was approximately 8 weeks in duration, and one of mine involved designing a system that allows for the entry and maintenance of vessels at component level.
My first job was to attend daily requirements gathering workshops, initially to begin the extensive process of knowledge transfer from the business and stakeholders with expert levels of domain knowledge.
Once requirements began to be driven out through workshops, we worked closely with the senior management executives and systems management experts to imagine in sketch form how new interfaces might feel.
We fed our sketches back into the workshops, refining our ideas as we went. As our ideas matured, I began to work up the sketches into a higher state of fidelity in Axure, often in ‘real-time’ during the workshops.
This proved incredibly valuable to our stakeholders, as the business processes we were designing are very complex, and had multiple dependencies across the wider business. For our expert users to able to see (rather than just try to imagine) how their new systems might look meant that the workshop discussions moved from the realm of the abstract and became tangible.
Now that the requirements gathering workshops had concluded and we had basic architecture for our product, I began working directly with users to refine the user interface.
I did this by taking use-cases through our product and iterating the wireframes out into a higher state of fidelity. I also began to create prototypes to illustrate new and unfamiliar patterns to stakeholders.
This was a sensitive phase of the project as our users are domain experts in a highly technical field who had become accustomed over many years to the quirks of existing processes, and doing things in a certain way.
However, on many occasions I was able to propose new ways of achieving certain tasks, especially repetitive behaviours, through new UI patterns that my users were genuinely delighted with. One notable example of this was improving the mechanism of manually entering (potentially thousands) of components on to a ship’s ‘inventory’ one by one, by creating a ‘stacked’ interface which could reduce the amount of data entry required by factors of ten or more.
With the system architecture in place, and user interface design and design pattern libraries aligned across the various workstreams, we were able to hand over a future-proof user interface layer offering significant improvements in efficiency and with excellent, evidence-based user acceptance within the business.