Enable javascript in your browser for better experience. Need to know to enable it? Go here.
Blogs Banner

Usability and Mingle

The usability of Mingle has been the team's focus from the very beginning and with 2.0 released I thought it might be interesting to take a little time to look at some of the challenges and opportunities we've had along the way.

Firstly, having the usability hat on a team is always interesting - and I have to say that it's doubly interesting when on an Agile team. When each point of effort must be justified in terms of business value, it can be tough to argue on behalf of work that isn't always easy to express in those terms. Don't get me wrong. I'm not saying that you can't analyse usability in terms of business value, I'm just saying that if the decision is between having functionality period or having usable functionality, it can be tempting to opt for just functionality. Winning that argument is a lot about the mindset of the team and the sponsors - so I wanted to talk about what we did on Mingle...

Usability as a team effort: Everyone on the Mingle team uses Mingle day in and day out. Because of the nature of this product, we use it to build it. Typically the development team itself can be one of the worst judges of what a product needs, because in most cases they aren't representative users. But with Mingle that's turned on its head to a certain extent (although not entirely). The upshot is that usability becomes a distributed, team effort. And since we're a pretty hard-to-please bunch, there's no shortage of immediate feedback. Team members spot, for example, where the interface requires them to traipse through multi-click interactions where one would do, and beat me up about it. Use of the forums means this extends beyond the team to our wider user base too.

Storyboards: There's nothing quite like feedback early and often. We make extensive use of MS PowerPoint-based boards to make mock up interaction and interface designs for new features. This doesn't mean we get it right the first time, but it does mean we have something cheap and tangible on the table to help the 'robust' discussions which usually follow. In the first case, the storyboards are reviewed and feedback given only by the immediate team - in the second case, and particularly for bigger features, they are also user tested. We probably go through several rounds of iterative design on the boards before an initial implementable design is settled on.


Guerrilla usability testing: As Nielsen pointed out many moons ago (well..in 1994) you can get tremendous value from a small number of depth interviews when trying to assess the usability of an application. This is the approach we adopt. Usually running for 45 minutes to an hour, each session involves volunteer users from an appropriate user group completing a number of pre-defined tasks set into an overall user scenario. As mentioned, depending on how mature the feature is, the users use either a development version of Mingle or simple MS PowerPoint screens. While having users interact with MS PowerPoint may sound a little bizarre (and I'm not talking about wiring the PPT up here - no hyperlinks, nothing clever, just a deck following a particular path through the app interaction by interaction) I'm always amazed at how quickly users settle into treating it like a real application. This is splendid news for the quality of feedback for such a relatively cheap investment. This generally leaves us with pages of feedback which we must then prioritise and decide what to act on.

We recognise we're never finished: Designs that seemed to work well as boards don't flow as hoped in reality; what was simple to do in PowerPoint is a significant and expensive technical challenge in practice; a new and more streamlined interaction in one area is now inconsistent with an older more clunky interaction in another.The above reasons and more mean that work to revise and tweak the design is an ongoing effort. In particular, as Mingle becomes richer and richer in terms of features, one of our most significant challenges will be avoiding the confusion many interfaces can become as they try to cram more and more options into ever-reducing real estate.

Watch this space to see how we do what we do.

Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.

Keep up to date with our latest insights