This week at work has largely been taken up by a Usability training course, borne out of the HMI team’s desire to have at least some sort of formal training in the area, rather than just being chucked in a team together because we were the only people that gave a damn that users liked using our software.
I was worried that it would be a fairly dry explanation of the best practices of usability testing, but thankfully it was far from it. The course tutor was engaging, and his presentation illustrated with viral videos and images that suggest – unusually for courses I’ve attended – that the tutor is actually part of the internet rather than being focussed on their subject to the exclusion of all else.
Though there was plenty of time spent going over the theories of various techniques of user-centric design, just as much time was spent going through the process ourselves for an invented product, all the way from user interviews at the beginning to letting other course attendees play with paper mockups of our designs.
The only major issue we had was not so much a problem with the course but with our industry. In terms of good usability practice, our tutor was clearly preaching to the choir – but it was a choir rendered largely incapable of religious belief. So many principles we would love to embrace whole-heartedly, but the sad fact of the situation is that the defence industry is not set up to permit user-centric software design.
It is a rare project indeed where we get any interaction with our end users. We supply our software to our customers, they hand it down to the users, the users just get on and use it no matter how hard to use it might be. Even interviewing, say, a sonar operator, is essentially impossible – much less getting them to play with paper mock-ups of our interface and offering feedback. Our software ends up being designed first and foremost to please someone in Procurement, and without being able to meet the users, we make a raft of assumptions about their use cases and what they do most frequently. If we make the wrong assumptions, often we don’t even find out.
To his credit, our tutor tried to think of ways around this problem, as did we, but there’s clearly no easy solution that we could roll out to revolutionise our software tomorrow.
It’s probably the most frustrating aspect of developing interfaces in this industry – we have so many ideas, and some of them our users would no doubt love to see in the software they use every day. But in the end, lack of access, or lack of requirements, or lack of time or money, means we’re often designing in the dark, adapting what best practices we can to a project that doesn’t support them.
Still, the course comes highly recommended – hopefully there are many developers out there who would find the techniques easier to apply than us.