Good software practice is for everyone
Authors: Yo Yehudi, Katie Taylor, Aoife Spengeman
“Design stuff isn’t a good use of your time. So long as it works, it doesn’t really matter if it looks pretty or not.”
- Anonymous principal investigator
Hulk smash computer
Think back to a recent time when you wanted to say a few rude words, or imagined tossing your computer out the window, when a program wasn’t doing what you hoped, or forced you to do it in a painfully laborious way. Computers are supposed to make many tasks easier, but sometimes can end up being a huge hassle instead. I’ve heard many people say “I’m not very good at X”, when after a few minutes of investigation it becomes pretty clear that the software that they’re using is at fault, rather than the person sitting in front of the computer.
Part of the process of designing software tools, if you want them to be good, is to run research, often known as “user testing”, “usability testing” or “UX (user experience) research”. We generally prefer the term “user research” over “user testing”, as research can apply more broadly to user interviews, diary studies, and other meaningful research types that can improve a software user’s experience. The idea is that by observing people using the software we’ve created, we can discover where the tricky bits are, the places where doing something takes a lot of time or isn’t intuitive, and probably find some bugs as well. Other types of user research come before any code is implemented, to help us understand the problem we are trying to solve. To learn more about different UX research methods and when each one is appropriate, consider visiting Nielsen-Norman, a research group that provides evidence-based advice on UX.
The reason user research is needed is because software engineers may not think of all the real-world scenarios that come into play when they’re designing their work, and since they’ve created it themselves, they always know exactly what a given button does or where to click to move on to the next step. They sometimes forget that others can’t see into their brains to understand the design intent. This isn’t a dig at software engineers — I’m one myself — but a simple statement of fact: we’re humans, and we can really only see things from our own perspective. Bringing in others from a variety of different viewpoints always results in a better product design.
The quote at the head of this article was a statement from a principal investigator I’d approached — let’s call them Jesse — hoping to use their work as a case-study for software I was designing that would help scientists analyse their experiment results. I’d sketched an idea for what the software interface might look like on paper, using my best guesses as to how it might be used by someone else, and then I’d converted those pen-and-paper sketches into slightly prettier mockups on my computer. I wanted to ask Jesse, a potential user of my software, if they could help test the mockups based on the real scientific data they had. This almost certainly would have revealed shortcomings in my thinking that I could then improve upon. Their derogatory response effectively shut down the conversation before it got started — they considered it to be nothing more than making the design pretty and couldn’t see any point going ahead, even though UX is so much more.
UX in science, research, and health
Jesse’s attitude towards UX research is unfortunately reasonably common, both within science/research and elsewhere. Despite this, having software that works and is efficient (maybe even pleasurable?!) to use is hugely important — increasing usability of a tool offers time savings, reduces mistakes and the need for training, and indeed can be the difference between someone using a tool at all and abandoning it in frustration. Better UX broadens your range of potential users — people are more likely to stick with your software and more likely to recommend it to others.
A couple of years ago I attended a UX in life sciences conference known as UXLS. The conference was reasonably commercial-oriented, so many big pharma organisations were talking about ways UX was applied in life science contexts, and when they referred to software created by scientists, the opinions were not always kind about how good the UX was. As someone working on scientific software at the time, this hit a nerve for me — I always tried my hardest to make things pleasant to use — but the point is nevertheless a reasonable one: all too often people creating software in research don’t value UX or don’t feel like they can justify spending time on it.
Good UX can make or break scientific results or output. Peter Cock wrote a series of blogs running back to 2015 about a poorly documented feature in BLAST+ (a scientific software tool for analysing DNA and RNA sequences) that doesn’t behave in the way people might intend, and could easily result in scientific results being misunderstood, incorrect, or impossible to reproduce. Testing designs with real-life users won’t ever pick up everything, but it can help reveal underlying assumptions like this one and ensure they aren’t used incorrectly by accident.
Moving Forwards: Good practice doesn’t stop at UX
If software for science and health is to be useful and worthwhile funding, it should be good to use (good UX for software that’s being re-used by people other than its creator is never a waste of time), and make people want to adopt it, but it should also be easy to maintain and update. This reaches further than user experience, to topics such as community management for open software — integral if you want to create pathways for others to contribute to your work — and typical “good practices” for software engineering such as testing, continuous integration, and documentation for users and developers.
In order for researchers who write code — or who get others to write code for them — to feel like best practices can be justified, funders, research institutes and journals all need to make clear that good quality research code and software is not wasteful, and not just a nice “fluffy” addition — but instead is time well-spent on creating a first-class research output.
Title image: Photo by UX Indonesia on Unsplash
