The project was to update the M109 artillery vehicle for the military. My role was Human Factors Lead (and I was also System Safety Lead) which was responsible for how the system interacted with the operators & maintainers. The work included computer interfaces as well as physical ergonomics. This portfolio entry will focus on the design of the GUI for the vehicle’s driver.
To understand the user and the job, I observed individual training, unit drills, and I interviewed experienced soldiers.
I also read the military regulations which describe the physical & mental characteristics for those assigned to these user populations. I read the manuals for the predecessor system to understand how things were done before. I read through unit orders to understand how the teams were expected to function together. I read through design reports for the predecessor system to understand why things had been done the way that they had been. I read a lot.
I did many different types of analyses in order to define & develop the user tasks. Some of these analyses were from the perspective of an individual, and some were from the perspective of the entire crew. These were good for me because they helped me visualize the problem, and they were good for the team because they made it easier to communicate usability issues with stakeholders.
The interface was designed with simplicity in mind.
- We didn’t want the user to spend a lot of time clicking around the interface to the detriment of his other tasks.
- We wanted the training burden to be low
- The good thing about designing for a military user is that you get to train them. Is there something that you’d like to tell your user? Great! You can tell them anything that you want.
- The bad thing is that training days are already packed, and the cost of a user mistake is considerable.
The main screen had a primarily static layout so that all information would be present at all times, but there was one spot in the middle which would change function depending on the mission state.
The transitional area would typically show status indicators (fan on/off, lights on/off, etc.) but it would change to other functions depending on the situation.
- If the driver needed to point the vehicle in another direction, it would trigger a widget to help direct that task.
- If the driver needed to move the vehicle to another location, it would trigger a widget
- In the predecessor vehicle, only the vehicle commander was given the navigation information due to technological constraints. But since we were removing those constraints for other reasons, I saw the opportunity for an easy usability win.
- Another feature is that the status indicators would change display based on context. For instance, if the user left the parking brake on and tried to move the vehicle, the GUI would let him know that he was probably making a mistake.
The System Screen was designed to help the user understand the current status of the machine; to know what was working and what wasn’t working.
I’m particularly happy with the Potential Causes section of the Fault Detail screen. A lot of time a system fault could not be 100% localized to the individual box which was registering the failure (i.e. Box B says there’s a problem, but it’s really Box C’s fault). Due to many factors, there’s the tendency that a maintainer may see a fault in Box B and simply replace Box B to see what happens, and that is often the incorrect decision.
The evaluation involved typical usability testing to see if people could navigate the interface and could understand the information. The real fun part was presenting the interface at several User Juries. These are events where where soldiers and stakeholders freely comment on the design and its various characteristics; like a focus group except more empowered.