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.

Comments > (HTML is allowed)

1. Zac

   June 12th, 2008 @ 12:46 PM

   One of the differentiating qualities of Mingle is its fantastic usability. Great job, Luke.

2. Ben Hidalgo

   June 13th, 2008 @ 12:30 AM

   Hi, I had a client two years ago who was using Dreamweaver and PowerPoint to illustrate their requirements documents and screen definitions. We (the developers) found that very unsatisfactory for their lack of navigation, the effort to publish and other reasons. The solution I created is called Rogdl (http://rubyforge.org/projects/rogdl/) which is an OGDL and ERB bridge to generate rapid prototypes. We've been using it for over a year on my project, quite successfully. The concept is: a structure is defined and then populated in OGDL, then transformed with ERB into HTML. We also have ERB templates for transformation in JSP, XML and Java. However, for Rails, the ERB templates would be almost identical to the actual Rails files. This is extremely flexible and easy to use. We primarily have BAs using it and they generate working HTML prototypes in my client's look and feel. They prototypes are real time modifiable with client feedback. I've also written scripts to publish some of the contents of the (machine/human readable) OGDL documents in Mingle via the Card RESTFul API. I've been considering writing an online version of the tool. It is currently a gem and we use Eclipse RDT.

3. Luke

   June 13th, 2008 @ 12:22 PM

   Ben, what you've created sounds pretty powerful - it also sounds like it is working well for you and your team (which is probably most important). I think the overall point I wanted to make about the use of PowerPoint (or paper) is that you can get a surprising amount of value out of a very simple approach that doesn't have some of the richness of navigation you mention. What I've sometimes seen is teams do nothing in this direction because they think without higher fidelity, without working nav, etc. it isn't worth it. This is not the case. If, in addition, you have a framework that helps you quickly generate and refine a navigable prototype - great - but if you don't pretty much everyone can get to grips with paper or a simple presentation tool.

4. Prashant Poladia

   June 14th, 2008 @ 01:31 PM

   Have you tried Axure for creating rapid prototypes? It gives great freedom to experiement new things at quick pace. Before that I used to use word, photoshop or flash for creating quick wireframes but Axure cuts time to half and we get almost same look and feel of the development files.

5. Luke

   July 1st, 2008 @ 01:21 PM

   Yes - and there are a number of other tools out there which help quick mock-up screens and screen flows. Different teams are going to prefer different mechanisms and also there's often a natural tendency to prefer what you know best. I've used PPT for mock-ups for a bunch of years now, have built up my own stock of widgets and like the fact that it encourages me to keep things simple. Historically it's been very accessible (with the number of installs of Office, it's been a safe bet that your end-user would be able to open it) obviously with tools like Mingle online collaboration is gaining more and more popularity. At the end of the day the important thing is the speed and veracity of the feedback you drive out - for me there's a step change in the quality of feedback you get when you present users with visual models. One thought here, though, about separating interaction and interface design from the the visuals and branding. Wireframes deliberately avoid too much detail around branding and colour schemes, etc. Early on this can be unwanted noise when you're looking for feedback on the basic design (sure it needs to come soon but not too soon)...

6. PA

   July 1st, 2008 @ 08:01 PM

   Read the above blog post. Liked your approach towards usability. Are you hiring in usability? I am currently working in Pune, India Best

• RSS feed for comments on this post

Sorry, comments are closed for this article.