News Article 22/04/2009

Usability is the secret to common sense software
Marine Electronics and Communication, April/ May 2009, p.60-61

A key reason for scepticism about information management solutions stems from usability, or lack thereof, and the difficulty in measuring it, argues Dimitris Lyras*

Performance support software in a business is supposed to increase each person’s awareness to the extent needed for him or her to perform optimally and make the best decisions. The kind of support required in the maritime industry ranges from decisions to enter a port in fog, to planning a repair and to buying spares.
Useful performance support solutions offer tremendous benefit, but financial controllers who approve the software bills understandably have no easy way to measure value. They will, however, readily accept outlays in management software that have easily quantifiable costs and benefits, a good example being the software that is required for compliance purposes or that the oil majors expect their tanker owners to have.
Slowly, there is a realisation that such ‘recommended’ software can also serve to assist in management performance, and therefore, can be viewed as a management efficiency tool. However, few people in the maritime industry are fully convinced that software is an efficiency tool. A key reason for their scepticism stems from usability, or lack thereof, and the difficulty in measuring this.
Everyone understands the difference in productivity of a good mobile phone or PDA compared with an awkward one, even without measuring the difference. The reason behind the difference is known, along with the feeling of frustration when productivity slows. The difference is usability and it applies to every tool, from a hammer to a radar set; however, software is one of the most complex examples, so usability can become the primary issue.
Usability is more or less critical, depending on the purpose of the software. Accounting software has dedicated users who are experts in data management.
Ships have captains and chief engineers who are not used to data management, and if they are, they are likely the wrong type of person for the job.
Nobody can be good at everything. Shipboard staff have to manage people well, have to manage uncertainty well and they have to spend a large amount of time thinking about machinery and structures in a mobile environment. Why should they as well as be data managers?
Captains and chief engineers have to view onboard software as an effortless interaction with the outside world and with the ship’s information – simple subconscious and continuous interaction focusing only on real business issues, not software handling ones.
Otherwise, too much time is spent thinking about software when it should be spent on thinking about their main role.
Since their roles involve commercial, operational and technical discussions, also purchasing decisions, crewing matters, vetting and other audits, the master and chief engineer should ideally have a single interface that unites all these elements.
The only way that this will work is for a software system to articulate around the same activities that the master and chief engineer refer to in their own thinking.
In essence, it is all about common sense navigation and good profiling of the processes in an enterprise; however, common sense navigation is the hard part.
For example, a well-designed software system should know who the user is: if the user approached the company fleet manager and asked to discuss a technical defect in a malfunctioning hydrocarbon alarm, would that person be expected to converse with the user, taking into account his role in the company?
The answer is yes because the fleet manager has knowledge of who the user is and what he is likely to know as a professional, both of which are critical to intuitive discussion.
Imagine the consequences if the colleague mistook the user for a port state inspector instead of a colleague! Likewise, software has to present different variations of a process to people with different skills sets in a company.
Well-designed software should identify the context of the discussion: the first thing most people do when talking is to identify quickly the object of their discussion. Poorly designed software usually spends too much time asking the user questions to determine the object or context of a discussion. The reason for the discussion has to come up as soon as the dialogue begins.
Why must software link related processes?
Suppose it turned out that the above defect discussion was not about a malfunctioning instrument, but really about replacing the 10 year old hydrocarbon alarm with an accurate instrument suitable for today’s emission standards. The two people are switching from a defect discussion to a change management discussion but are still talking about a hydrocarbon alarm and related emission instruments. It is the same system but a different process.
Many programs would have the user start with a new process looking for the emission instruments again. Would he expect to go back to his desk and think about the management process involved in replacing the alarm and then have a further talk with his colleague? Would he then not be annoyed if he had to remind his colleague that he was talking about the hydrocarbon alarm and not the galley extractor fan or 900 other machinery components?
Must software be able to switch topics? If a discussion focused on the alarm panel and not the sensors, would the user then expect to return to his desk and spend five minutes re-adjusting his thinking to recall knowledge about the alarm panel instead of the sensors? A person could easily switch topics and maintain focus; software must be able to do this, too.
Business use cases must reflect the way business is done: if the user knew that he wanted to replace the existing alarm with a new instrument, he would be quite annoyed if his colleague jumped two steps, asking about the part number of the instrument required before the maker’s name was even known. Neither would he be happy if the colleague insisted on knowing how many parts were wanted when the logical next step would be to work out a quick budget based on the commercial benefit and the oil company vetting angle.
Finally, would the user be happy if it took him 15 minutes of trial and error to arrive at a way to convince the colleague that he did not want to discuss deck department defects, just the boiler hydrocarbon alarm, which is no different than the steam generator hydrocarbon alarm, which everyone understood was the discussion item?
Furthermore, the user also wants to discuss TMSA (Tanker Management and Self Assessment) and vetting observations but does not want to navigate through port state inspections first. When all discussions are finished, it is essential that the correct people know – not everybody but the right people.
One of the most fundamental concepts in usability is the ability to operate software subconsciously while concentrating on the issue at hand. This concept is especially apparent when using a mobile PDA device because these are often used while doing something else, for example, when on a street trying to find an address written on an e-mail or while talking to a taxi driver. The concept of using subconscious scripts to simplify our lives is essential not just for using software but also for driving and most of all for managing difficult decisions.
If a software product can be navigated without conscious thought, it can be used in stressful circumstances without taking attention away from the real world situation and without adding more stress and pre-occupation.
To overcome the usability obstacle requires building as much human common sense into a system as possible. This typically calls for a careful analysis of how much ergonomics effort is needed and in which software features.
Ulysses’ task oriented architecture aims to provide software that is highly intuitive and makes information uniquely accessible to the user. Unlike other products, which expect users to adapt their thinking to the navigational layout of the product, Ulysses software is designed to match the navigational layout to the way each user thinks through a process.
This increases the performance of users in every aspect of information handling. It also saves time for employees who are working in multi-tasking roles, while offering ever better process control without the rigidity of conventional systems.