We recently had a minor but telling software issue with one of our clients (a big thanks to @peninsulahealth for being one of our fantastic client-partners – it was your RCD schedule names that got us) that highlights an issue we see overlooked again and again. Usage patterns.
We have developed a form to assist with a database entry entry for one of Peninsula Healths’s management systems that allows just a restful API to work with a flask web app. Whilst the mechanics are not important, what we found is that computing professionals (like our in-house test team) and target users (hospital engineers and technicians) may see the same system so differently that what we consider a minor compromise becomes a massive usability issue in the hands of the very people we seek to serve.
We’ve seen this time and time again with software we use everyday (not ours, thankfully) and we have traditionally prided ourselves on avoiding the pitfalls but this time we fell right in (and it’s now fixed!!). What this highlights is one of the most important pieces of the “agile” software puzzle. Involving your client early, often and via a wide audience of their users, not yours.
It is so important to find out that the people who do the work that your systems support, always (for example) analyse electricity and gas together, so don’t want to return to the same selector screens for each, but just want to toggle between the two.
Seeing (logging) what people click on, in what order they click on things and where they click next is one of the best tools we can use to enhance software flow and take the friction points out of the system use (yes – I’m looking at you Oracle Iprocurement) and keep our clients happy, productive and ready to make long term partnerships with us as software providers.