The critique cross

At the UX Cambridge conference in 2014, my friend Alisan Atvur talked about techniques for managing designers and managing managers, which I enjoyed very much.

EDIT: October 2015 –

Alisan now has a short video that explains this concept.

One of the tricks he told us about is what he calls “the critique cross” – a very simple tool for inviting and managing design critique in a structured way. Since he hasn’t written about it yet (as far as I know!), and since I frequently refer to it and tell colleagues about it, I thought I’d take it upon myself to share the detail.

Alisan Atvur suggests four simple aspects of critique, to keep it focused and manageable

If you need to provide or receive useful critique on something – sketches, a prototype, an interface, physical or digital – it is useful to do that in a structured way.

What Alisan suggests is that we consider four main aspects for the critique. These four aspects are associated with each quadrant around the cross you see in the image above, read clockwise from the top-left.

1. “Dwell time” – how much time do we have to talk about this (5 minutes or an hour… it makes a difference)
2. “User context, goals, needs” – what problem are we trying to solve here? what are the user needs?
3. “Logic” – what design decisions have been made, and why? What are the suggested solutions?
4. “Design principles” or “Business goals” – what else has guided our decision-making, in terms of what we’re trying to achieve.

In his original talk, I think Alisan actually suggested “Emotion” as the fourth quadrant. What emotion are we trying to produce in the user; what experience are we aiming for? I think this is a fine option but in practice, I’ve found it equally useful to reiterate any design principles that we have generated from research within a project.

So there you have it, a straightforward way to manage design critique.

Useful questions to ask when designing data visualisations

For the third Cambridge Visualisation of Biological Information meetup, organiser, Will Spooner, invited Greg McInerny and me to talk about “best practices in bio vis”. While Greg covered wisdom, mistakes, and deception in visualisation (particularly in figures used in academic papers), I wanted talk about how we can apply UX design practices to visualisation challenges. Rather than just give a talk that lists and describes methods and techniques from UX design, I tried to focus on WHY you would use any of those approaches; why would you bother to learn and apply them, on top of everything else you have to do? I framed things in terms of important questions you might want to ask whilst going through the process of designing data visualisations, so that we can try to gain clarity and develop your understanding.

UX design, bioinformatics and cars

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

EuroIA 2014 and activity diagrams

[May 2015] – I’m tending to refer to these things as “[key] activity descriptions” these days, since the “diagram” bit could sometimes be confusing. You could also refer to it as an “activity canvas”, too. Anyway…

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

UX Bristol 2014

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!

UX lightning talks 2014 – Cambridge Usability Group

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…

Evaluation: role-playing the UI

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.

Evaluation: usability testing

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)

Evaluation: critique

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).

Evaluation: heuristic analysis

Heuristic analysis provides a way of objectively evaluating your own work or that of others against a set of design principles (“heuristics”). While it is a great way to pick up issues early on, it is not a replacement for observing real people using your system. We’ll get to usability testing later on!

A nice little primer for Jakob Nielens’ 10 Usability Heuristics. This was created by João Machini and is used with permission