As programmers, we might sometimes fall into the trap of thinking our ideas - and the user experience they provide - are fine, because they work for us and we can adapt to poor interfaces without much problem. Put the same idea in front of an audience, however, and you're in for one hell of a refactor if you wrote the code beforehand.

This is a story about the two days I spent prototyping a new feature with the BBC; how figuring out the UX was far more challenging than writing the code could ever be; and why nothing could possibly be more entertaining than X-Factor.

BBC Connected Studio

The BBC occasionally runs a series of events aimed at encouraging innovation amongst their divisions or offerings, some of which have focussed specifically on the iPlayer, the news, and learning.

My colleague Makoto and I were invited to attend the first stage of the iPlayer Connected Studio event in January, where we had to build a team and pitch an idea that fit the brief for the day. While my colleague's idea was not accepted into the second stage (but was nevertheless successful by all accounts), I was invited back on the behalf of New Bamboo to work with the BBC folks we originally teamed up with.

Using mood to discover content

Using the prior research conducted by some of the BBC R&D staff on the team as a foundation - which you can read more about in the white paper and a related blog post - we pitched a content recommendation system that suggested TV shows based on the 'mood' of the programme just watched (the data of which was produced from processing the audio, video, and subtitles), instead of suggesting them based on popularity, ratings/votes, and the behaviour of the user.

The benefits of this were that we didn't need to track users, and we could potentially avoid the Napoleon Dynamite Problem: we weren't concerned with trying to find what you'll personally like (which, as with Napoleon Dynamite, you may either love or hate); only with finding programmes that bear thematic and emotional resemblance to what you've just watched, with the option to go for something that isn't similar if you preferred.

We had this data already, and the problem we had was all in the UI. How can we use this data in such a way that it adds value to the iPlayer experience? And how can we present it so it works consistently and intuitively across all the devices the iPlayer has to support?

Talking yourself out of the idea

The mood dataset provided us with two axes: topic (informative, entertaining), and mood (similar, different). Given the four different options the user could pick, we decided that being able to choose one by moving up, down, left or right would be the most useful way to interact with them.

A 'similar' programme would be one that had a similar topic or plot (eg. crime drama), and ranked similarly based on whether it was serious, humourous, fast paced, or slow paced. A 'different' one would be something that had nothing in common, although care had to be taken not to present useless programmes (eg. kids TV shows after watching Silent Witness).

Our problem was that, even after settling on this plan, we weren't sure how intuitive or useful it was, and came close to discarding the whole idea as unworkable. We had decided to place the navigational prompts on the edges of the screen, but the UX designers on the team were skeptical of that. Research suggested that the top edge of the screen was so overlooked by users that placing an important feature there would almost certainly reduce its visibility. In our case, would users even know they could find more informative content? Further to that, the bottom edge of the screen was unusable, as the player controls occupied that space.

Our other alternatives were to go for a 'toolbar' of sorts, where all the options were laid out horizontally, or something similar to the Playstation 3's 'Cross Media Bar', which aligned the menu sections horizontally, and items within that menu vertically.

The problem was that we'd pitched the four way navigation once already, and we were able to prototype based on that initial idea. Even if we couldn't figure out something nice in two days, we could at least iterate on the idea and improve it with extensive user testing at each stage. We had to present it again anyway, to see if we were heading on the right tracks, and for the most part it appeared we were.

These were the lessons I learned both before, and after we gave the main presentation.

Don't polish your prototype

It's generally a bad idea to present a prototype to any audience that has too much polish. The more finished it looks, the more the audience gets hung up on the way you've implemented it. You want them to buy into the idea, or the concept, and not the demo you threw together in a few hours. You want to field questions that are concerned with what you intend to do with the idea in future, or how you intend to overcome the challenges of implementing it. You certainly don't want to be asked why the buttons are bright orange, the text is uppercase, and the design matches but doesn't exactly fit in with the rest of the site (uncanny valley).

The best way to avoid this is to leave as much as possible to the audience's imagination by removing any semblence of a defined implementation, and making sure the focus is entirely on what you want to deliver.

We avoided most of the problems by creating a non-specific prototype, and filling it with real mood data that was generated beforehand, because that was what we wanted to show off, and it was the basis of being allowed to spend more time coming up with a well-tested user experience.

Trust the audience

If you're bringing an idea to life, the opinions of the people you expect to use it are worth far more than what you believe yourself - even if you do think you know what you're doing. We doubted the effectiveness of our four way navigation system, but the layout wasn't questioned or debated by any member of the audience. It wasn't questioned in the final presentation either. While this doesn't mean UI and UX is less of a problem, it instills confidence in the idea and changing it at the last minute without consultation could have caused more trouble than it was worth.

Be careful with what you suggest

I've consistently referred to suggestions being made relative to the mood of the last programme watched, ie. more similar, more entertaining, and so on. If you thought about a programme, and then thought about how we could suggest something 'more' entertaining, or informative, you'll understand the title of this post. Our audience did, and they were practically offended:

How can you tell me what I'll find more entertaining?

The audience were up in arms about using the term 'more' in our interface, because to them it suggested we were the arbiters of taste and there's no way we can tell them what they want to see.

What could possibly be more entertaining than X-Factor?

One member of the audience got hung up on the use of 'more' too. They believed that the recommendation system would fall apart when they watched X-Factor, because it was their favourite TV programme. None of the recommendations for more entertaining programmes would be correct, and so our feature would be broken.

So, there you have it. Nothing is more entertaining than X-Factor, at least if you ask some people. It's probably a conversation best avoided, especially as a result of your prototype.