Guillaume Filion is team leader at a genomics lab in Barcelona. On his personal blog, in January 2015, he published the article “If Cars Were Made By Bioinformaticians” which one of my colleagues pointed out to me. Regardless of the self-explanatory title, it is actually a wry, satirical view of how bioinformatics tools and software are developed. It made me laugh (particularly the bit about “having many options”) but it also got me thinking.
As a user experience designer at one of the world’s leading bioinformatics institutes (and proud of it) I thought I’d offer my perspective. Here’s the summary version:
- Don’t worry about a clever name; spend the time to understand what people need to do, to test your assumptions (don’t make bioinformatics Ford Edsels), and to figure out where your software or tool is going to fit in
- Speed and accuracy are important factors, but these should fit with the needs and perceptions of the users. What is “good” for them?
- Focus on outcomes and value, not on huge lists of features
- Constraints make good design decisions possible
- Consciously design bioinformatics tools with the appropriate degree of complexity and for the love of BLAST, please handle errors elegantly
I had the privilege of giving a quick talk at EuroIA 2014, entitled “Maybe there’s more to this than user-centered design?”. As you might have guessed, I think there is more: I wanted to explore and share some thoughts I had about how we approach UX design in complex settings like scientific service design (and others besides). In recent project work, I’ve been using modified activity diagrams to help me characterise apparently important activities. I thought this might be useful for other people, too.
Picture of activity diagram template – click to download a PDF version
I was really pleased to be back in Bristol on July 18 for UX Bristol 2014. I’ve been a couple of times before, and I might have enjoyed this one the most. I learned a lot, and there are various topics and discussions that I want to follow up on. I enjoyed sessions on estimating, repertory grids, design sprints, and brand-building basics.
Participants have a selection of four one-hour workshops to attend, and the day wraps up with a few short talks. I have sketchnotes for the things that I attended, and I’ve included those below. There are also great live blogged notes online, too… quite by coincidence, I seem to have attended the same sessions as the live blogger!
I was lucky enough to be involved in organising the UX lightning talks event for Cambridge Usability Group again this year. Towards the end of March, I sent out a call for people in the Cambridge UX community who would like to give a 5-minute talk about their work. Tips and tricks, stories from the trenches, thoughts, ideas, questions… anything. They didn’t disappoint, and on the night, to a sell-out * audience, everyone shared ideas and told stories based on their experience. Just for a bit of added excitement / headache, I gave a talk as well. We hosted it at Microsoft Research, and Red Gate Software kindly sponsored drinks afterwards at a nearby pub.
I’ve managed to pull together notes for the talks, in order of appearance…
While this might not be as strict (or serious?!) an evaluation technique as, say, heuristic analysis or usability testing, having two people act out the roles of the user and the user interface (UI) of system can, I think, be very revealing.
It’s a little bit like some of the more elaborate “paper prototyping” scenarios I’ve seen, but I first heard of this in a talk by Stephen P Anderson, at UXLx 2010. Perhaps the best thing to do is see Stephen describe it at another event in Norway.
Observing representative users carry out representative tasks using a system (for example, your data visualisation tool), and recording any issues that come up!
Ideally, there’s a participant (a user to test your system), facilitator (that might be you), and observer (let them take notes).
Dave Hamill’s usability testing tips & tricks (sketchnotes from NUX2)
As part of evaluation, critique gives you a structured way to discuss usability issues with the developer of a system. Aim to give and receive feedback in positive way. Be kind, though. You don’t need to put the recipient on the defensive (although that takes skill and practice).