³ÉÈËÂÛ̳

From Tom Spalding, Senior Designer on Visual Radio...

I realise that this subject has been blogged to death here, but it seemed a good idea to wrap up phase 1 of the trial with a bit of a user experience dissection, of what went well, what not so well, and what can be learnt for the future. Earlier posts have covered the technical aspects of the trial, here we will focus on the concerns of the user experience delivery.

First things first, I felt the trial was a success. At its very best it illustrated exactly what we were looking to achieve, at its worst it served to teach us where we can improve in the future.

The times where it really came together, were where the production teams in the studio were really engaging with the technology we had given them, using the console to supplement their broadcast, but not to the detriment of normal radio listeners.

The Switch show on Sunday 18th was the best example of this, with creative uses of graphs and text messages, with very strong links to live studio events, and innovative use of the video feed.

Sometimes, I felt what the trial occasionally lacked was a sense of pace, something conveying to a user that things were happening, a general sense of liveness. For great chunks of time nothing apart from the video was active in the console, this was certainly not our intention for the user.

We never wanted to show the video in total isolation, it was always meant to be supported by other visual data feeds, such as graphs, text messages and the studio blog. When we did show the text message feed, often we were displaying it with no visible updates for great lengths of time, this meant the messages themselves lost a sense of relevance. The longer these feeds remained static and stale, the more danger there was for users to simply ignore them and this has definitely emerged from our subsequent focus groups.

Arguably the text messages didn't get through the system quickly enough, and the studio blog was not updated as regularly as we would have hoped. We can learn from this, for example we could look to have more intelligent default states; to never let the console stand still and to always show something, without needing any manual studio intervention.

From a UX point of view we made a lot of educated guesses about how exactly the studio teams would use the console, in many cases there was too much of an overhead involved to use it fully. The managing of this overhead certainly got better as the week went on, as the Moyles team learnt to better engage with the product.

We didn't want to radically change the way a programme is produced, or how the output is perceived by the listeners. What we did want to do is add value for a new group of listeners, and I feel at points during this trial we achieved this.

Roll on phase 2...