Mike Robbins, from Helios Design Lab (the guys behind NFB’s Highrise, OFFSHORE and 17,000 Islands) has participated to the UX Series by responding to Question 5: Rapid prototyping and testing: what to test for, and when, in i-doc production?
I asked Mike to tell me about the way they’ve been testing their projects and… interestingly enough… I learned that they have refined their methodologies through every single project they have done so far. Check what Mike has learned during five years of Highrise production, and through their latest project OFFSHORE!
Note that Mike will be coming to i-Docs 2014 and will present OFFSHORE with director Brenda Longfellow on Thursday 20th of March, in Bristol, UK. In another talk, Mike will also unveil how Helios Design Lab is addressing user experience and participatory design in the project they are currently working on: WOO (World Online Orchestra). Don’t miss your chance to meet Mike in person, and to be inspired by his contagious ideas: register for i-Docs now!
The other person that I interviewed is Isaac Pinnock, from Made by Many. This is a company that specializes in rapid prototyping and iterative testing. They have done projects for ITV, the Telegraph and Skype and Isaac has no doubt: any project should be tested at every single stage, and no more than 5 days of design should be done without testing. The trick is to test different things at each stage. To learn how to do it properly watch Isaac Pinnock in the UX Series.
In a Web world where everybody preaches agile design and iterative methodologies it is difficult to think that interactive narratives should be treated differently. And yet, from my experience mentoring projects, and when I speak to i-docs producers, I can see that testing is in the back of their minds but they often wait till the last minute to do it. The pattern normally goes like this: so much time goes into elaborating the idea that the interface and interactive storyboard (wire-frame) are rushed and often given to an external designer that was not involved in the initial concept. The author asks for a few design ideas and then selects the one s/he likes most. The coders are then asked to add the functionality. Bugs, technical issues, budget constraints then take most of the time and efforts of the team… and by the time there is a working prototype the project is near to launch. This is when there is a sudden panic attack and the team remembers testing. The assumption of the author here is that a narrative is more complex than a commercial website and therefore one has to wait for a working prototype before starting the testing. The consequence of this pattern is that what gets tested is only navigation and look and feel (do people understand what to click and what it looks like, rather than are they at all interested in the project, would they spend their time on it and what do they get out of it).
Issac Pinnock and Mike Robbins give us a chance to re-organize our production model in a different way. As Isaac says: “If you care about what people think of your project it will be always more effective, even for your own heart, to test it from the very beginning”.
Sandra Gaudenzi