Chris Thorne

I have worked in many teams who define product and project requirements as user stories and acceptance criteria. What makes a good user story?

As a User I want to listen to a documentary programme from Radio 4 on my PC, so that I can increase my understanding of the subject of the documentary.

As an example, here is a bad user story:

I want to click on a ‘buy this’ link that adds the item to my shopping basket.

One of the easiest ways for us to assess a projects success during development is by using user stories and acceptance criteria. However, user stories seem to be very dependent on who has written them.

In my opinion, a good user story has the following characteristics:

* It defines Who needs this requirement met – for example the Product Manger, a Stakeholder, or the User.

If the team don’t know who the requirement is for, and we want to find out more about this requirement, who should we talk to? Knowing who is important, to help us get further understanding.

* It defines what is supposed to happen.

This is the surface requirement. Ideally there is some evidence, research or analysis to support this requirement. You might add this research as supporting notes for the story.

* It defines why it is supposed to happen – what is the benefit?

Defining why a requirement is important (the ‘So that’ part of the story) increases understanding of the underlying need, and can greatly help innovation.

For example, we know that in the above ‘radio 4 programme’ story, the goal of the user is to understand the subject better. Perhaps on the web, this can be accomplished in other ways than ‘listening to the programme’ (a solution might be simply providing some related links for the programme). If we just have 1/2 the story – eg ‘As a User I want to listen to a documentary programme from Radio 4 on my PC’ , without expressing why this is important, we miss the opportunity to innovate.

To further encourage innovation, I also try to remove any reference to how from a user story. Supporting notes for the story might suggest:

* When it is supposed to happen.

* Where it is supposed to happen.

* How it is supposed to happen – this is just an idea, but might be useful as inspiration for the team.

The keyword here is ’suggest’. If we dictate the How and When and Where then we have weakened the project teams ability to innovate. If we were working on a factory production line, a lack of innovation can be useful (although Toyota seem to have done quite well through innovating on the production line), but if we’re knowledge workers working on a project, one of the outcomes should be some innovation.

Improving user stories

‘I want to click on a ‘buy this’ link that adds the item to my shopping basket.’

The above is a restrictive user story. Lets try and improve it.

Start by adding who it is for:

As a user I want to click on a ‘buy this’ link that adds the item to my shopping basket.

Now we know that if we want further information about this story, we should talk to user experience staff, or audience research staff. They may have further research that explains this story.

Now we can remove the how from the story. In this case the ‘buy this’ link is defining how the story is to be implemented. Removing this we end up with:

As a user I want to add items to my shopping basket.

This shopping basket idea might be well understood, but we would do well to define its behavior better, just to be sure we will get what we want. The shopping basket concept has several features that are worth considering separately.

The underlying function of adding items to a shopping basket is to collect all items I want to buy in one place, so that I can review all my proposed purchases  and pay for them all at once.

As a user I want to collect all the items I want to buy, together in one place, so that I can review my proposed purchases and organise payment and delivery details for all of my shopping just once.

If we add a note to this user story ‘The one place that collects all items together might be a ’shopping basket’ then we’ve explained our idea, but also left it open to design staff to think about other solutions that satisfy the same story. For example, they might think about storing previous payment and delivery details, so that repeat visits to the site are even easier.

The other aspect of the basket is being able to add, remove and change the quantities of items I have collected, before I purchase them.

As a user I want to be able to add, remove and change the quantities of items I want to purchase without journeying back to each individual products page, so that it is easy to complete my shopping.

So now we have 2 user stories, but a clearer definition of the basket functionality, and a clearer definition of the underlying needs of the user.

Conclusions

Great user experiences (I’m going to say it, sorry) for example, those delivered by Apple, are partly successful because they have worked hard to answer not just the surface requirement, but the underlying need. Great user stories are the foundations on which experiences are built. Making sure those stories are solid, researched, and prescribed appropriately for the project aims is very very important. By making sure that a user story defines who, what and why we have the basis of a good story.

Keeping how out of the story gives a project important room to innovate.

Thanks for reading – let me know your comments.

I’ve written previously about the proms website redesign.

However, we just updated the site to supply a mobile view for those using the site on a phone. The site is now multiplatform, and uses content negotiation to provide the user with an appropriate experience for their device.

One of the aspects I find most pleasing about this is that it is still ‘1 URL for 1 thing’. One of the major advantages of this approach is that  the things that users want to talk about or point at can be shared easily across many devices. If a friend sends me a link to a prom, I can visit that proms page, and get all the information I need, even if my friend is on a PC and I am on a phone.

The ability to share content seamlessly across devices seems to me to be a very important part of user experience design, and one that often isn’t possible for technical reasons, or (worse) isn’t possible because the design team didn’t think about it early enough in the project. I’m proud that in this case, we did design for multiplatform from the outset.

See what you think.

PS You can compare and contrast the experience on different devices (I use a firefox plugin called user agent switcher to fool a browser into thinking it is on an iphone, a PC or other device).

This project took place late last year, but is worth writing up because it shows some of the problems that the BBC has when it tries to build user experiences based on data, at the scale that it needs.

This project provides the BBC with a data service for music charts and playlists. It turns out that, even in an age where music is competing with many other media “what is top of the charts?” is still a question that can get 2 million visitors a week excited enough to visit the radio 1 chart site.

This project provides the BBC with a technical solution that can cope with 2million visitors, and is easier and quicker to update live as the charts get updated.

The database schema we agreed was as follows:

An overview of the chart and playlist schema

Notice the ‘item’ entity. This is the thing (eg a particular top 40 single) being talked about.

One of the hard things about working at the BBC is the fact that it publishes a vast amount of content. For music, it turns out there isn’t a great source of super accurate music data. The official chart company publishes the charts, and the BBC licenses that information for use on its radio programmes, but the chart company data doesn’t use identifiers, it is just a text file.

What this means is that there is no super accurate way of curating charts over time. If Rihanna changes her name to Squiggle (hey, Prince did it) we know its her, because we’re told by a huge marketing machine, that its the same person. But a computer can’t make that same leap. So, any data associated with Rihanna would not be associated with Squiggle. Similarly if a particular mix of a single becomes popular, can we associate that mix with the original song that it is a remix of?

When you’re trying to maintain data integrity for the BBC, so that you can tell stories about it, and show the audience interesting journeys, the fact that we have many playlists and many charts each week becomes a real maintenance problem. Who is going to polish that data, curate it and maintain it? Is it something that represents good use of the license fee?

Luckily, for music artist we have a great source of identifiers. The BBC uses the musicbrainz data set. By matching artist names to an identifier in musicbrainz, we can associate new data with the same music artist, even if they change their name. Therefore it is much easier to maintain the data associated with that artist, even if they change their name, because their identifier won’t change.

Unfortunately for the item data, there is no great source of track names.

For now, the BBC is trying to maintain that data itself, and accepting that some of the data may be slightly broken over time, and may need tidying in the future.

In the next few weeks, musicbrainz will be releasing their ‘next generation schema’ which the BBC is supporting. Like the artist names identifiers, musicbrainz will then be able to give us a great set of identifiers for each item.

Exciting news for Information Architects like me, who want to be able to tell stories about data over a long period of time.

If you’re a UX professional, I suspect you’ve used Lorem Ipsum dummy text in your deliverables.

I’ve done it, but I don’t want to anymore.

It appears I’m not alone, but Lorem Ipsum dummy text in UX deliverables does us no favours. It adds confusion.

One of my main concerns at the BBC is to check if we have the metadata and content to deliver a great user experience. In my role as lead Information Architect for external projects, I often review wireframes from agencies. It has made me realise a really common question. “What is this text here?” [*points to dummy title or copy text*].

In a large data driven website (for example almost any website delivered on bbc.co.uk) it is important to know if a design will work in practice, given our metadata systems. A wireframe that has dummy text ‘This is the programme title’ as dummy text is much more easily understood than one that states ‘Lorem Ipsum’. “This is the brand title (maximum 90 characters)” is even better  – it implies that you understand the data system being used to populate the wireframe, and makes it easier to understand if the design works.

So, lets all use better, more descriptive dummy copy please – copy derived from the underlying data and domain model is best. Lorem Ipsum, just say no, right?

An image of part of the BBC Proms website

Update October 2011: we’re submitting The Proms website to this year’s Webby Awards:http://www.bbc.co.uk/proms

A week ago we relaunched The BBC Proms website. This website and content management system was developed by Magnetic North, in collaboration with the BBC. I was lead information architect on the project.

Key features of the new website

Andrew Downs, editorial lead on the BBC Proms website development, adds:

In 2011 we rebuilt the BBC Proms website from the ground up.
We wanted to do a more streamlined and focused job of meeting, and exceeding, the online expectations of both the broadcast and live event audiences for the World’s greatest classical music festival.

The new website offers easier ways to book tickets, listen and watch, and reveals a wealth of in-depth content from the BBC archive as well as shorter, light-touch briefings directly related to each concert programme.

Key features from before the Proms season is underway:
Browse, book and listen by composer, performer or category
Discover more about the music with links on every event page to the Radio 3 online archive of programmes about works and composers.

For 150 of the works performed we offered preview clips of the music right up to start of the concert.
Sign up for the newsletter.
Search the archive with details of every Prom since 1895
Play the Proms quiz
Mobile-optimised version of the site.

When the season is underway:
Listen live in High Definition Sound, or listen to or watch Proms broadcasts on demand for 7 days.
Audio and video highlights of each week’s concerts in the Proms Showcase.
In-depth programme notes for each concert
Relive and share your favourite moments with photos, videos, reviews and comments on site or via Facebook and Twitter.
Go behind the scenes with the Blog and Q&A with the Director of the Proms
Download interviews with key performers in our weekly podcasts or download a daily 4 minute briefing on a key work from each event.

On TV press Red Button to watch Maestrocam with explanatory commentary.

Background to the design

We began redesigning the proms in October last year, with some user research work conducted by Engine.

One of the deliverables Engine produced was a set of Personas for each of the target audiences. There were 3 types of audience defined, which I summarise as follows:

• The casual enthusiast - This person is interested in the Proms but doesn’t feel confident in their knowledge of the music. They are looking for guidance and reassurance.

• The existing Radio 3 audience – Knowledgeable and articulate about classical music. Knows what they want, and wants to get to it quickly and easily.

• The expert enthusiast - Highly knowledgeable and articulate, but looking to be further educated, to learn more about the music they are choosing.

We also did some user testing of 2010s proms site, and user interviews, with users who were classical music enthusiasts (conducted by Foviance). In some of these interviews, users talked of how they would ’swot up’ before going to a concert, by listening to recordings, so they really knew the music they were going to listen to before they attended the concert.

Core objectives from the audience research

The above research gave us confidence when setting objectives for the redesign. We found out that when talking about and selecting classical music, the audience almost always talks about liking music from a particular composer. They don’t tend to talk about liking a particular piece, until they have framed it with ‘I like <composer name>’.

This encouraged us to make selecting a prom based on the composers name a core piece of the navigation (hence its presence in the top navigation).

Discover the music

The discover the music panels used throughout the site came out of our audience research. One of our business objectives is to increase the number of listeners to radio 3. The expert and classical enthusiast personas also caused us to develop the ‘Discover the music’ panels that are seen throughout the site. On each event page, the ‘Discover The Music’ panel is used to highlight relevant content, based upon the music being played at that event.

It helped that Radio 3 were given permission by the BBC trust to make more use of their fabulous archive of music programmes. For example, Radio 3’s Discovering Music programme involves a presenter/conductor showing the audience a well known piece of classical music, and performing parts of it with an orchestra. An amazing resource for users looking to ’swot up before they go to a concert’!

Starting the redesign – Content Management

The new site is built on the BBCs latest infrastructure, which allowed us to build a content management system. As usual, I took a domain driven approach, which meant that we started by defining ‘What things are in the proms?’ and ‘How are these things related?’.

You can see the final domain model we derived below:

The Proms Domain Model

Notice how this is not very specific to the Proms. A good domain model is about the domain, not the particular brand or project. What we have here is an approach for building any music events based website. So, our content management system is reusable across any music events site.

The concepts shaded in light blue are concepts that have a controlled vocabulary of terms – for example there are approximately 80 terms that can be used to define a performers role in a performance. They can have the role of ‘guitar’ but not of ‘guitarist’. This helps us when building aggregations of performers. For example, our Composers A-Z shows all contributors with a role of ‘Composer’.

Performance Flags allow us to provide emphasis to a particular performance – for example if it is the world premier, or the UK permier. This obviously helps the user notice certain performances more than others.

Similarly, a contributor can be flagged as someone that Radio 3 supports through its ‘New Generation Artists’ programme.

Where to put the effort in a Content Management System?

One of the strategic decisions to take when defining a CMS is about where to put the effort. The approach we took in this CMS is all about the reuse of the content. A lot of the effort in this CMS goes into populating and curating the ‘Works’ information.The reason for this is that the Works information can be reused in subsequent years. For example, editorial staff can associate an audio preview with a work. Next year, when that work is performed, the audio preview for that work will be already populated. We know that in classical music, a lot of the works are regularly performed, so putting effort in here makes strategic sense.

Contributor information is also reusable in subsequent years, so adding related links for a particular contributor is efficient use of effort.

A final example of careful Content Management design is that because many of the classical music composers are dead, we can reuse analyses of their music over many years. So, by associating an analysis with a work, we can reuse that analysis each time the Proms performs that work. Episodes of the ‘Discovering Music’ programme are each an example of an audio analysis which we can reuse each time that work is performed.

The easy alternative would be to put a lot of effort into creating beautiful event pages, but without contributor, work and performance concepts, this effort would have been very hard to reuse in subsequent years.

The website navigation

One of the navigation elements I’m most pleased with is the consistent event navigation on (almost) every page:

Event navigation is used on almost every page to help the user navigate the site easily.

The launch and audience reaction:

It has been particularly pleasing to me to see the audience reaction. A significant change from previous years was that we decided to build ‘a page per prom’. This lets users talk about, link to, blog about and generally point at an individual prom. They have!

It’s been great to see on twitter the number of users linking to parts of the proms site. For example:

These and many other coversations vindicate the strategy of ‘one URL for one thing’ which we followed on this project.

There have also been some great articles talking about their favourite proms. And more great articles like this.

I’m looking forward to seeing how ‘discover the music’ panels get used – I’m hoping that this feature on the new site encourages the users to listen to Radio 3, and then to get to a prom and hear a great classical music performance.

The Desert Island Discs project had a very aggressive development plan. At several points in the project we had to work very quickly.

As usual, when working for  a large employer, there were many stakeholders, each of whom needed to be satisfied in order to achieve signoff.

One of the crunch points we found was when we were trying to achieve signoff on the wireframes. One of the designs that Magnetic North proposed was not accepted at the review meeting. We could have waited for another round of amends and another opportunity to get all the stakeholders in the room.

What we chose to do was a bit of (really bad) Origami .

We took multiple copies of the original wireframe, folding each wireframe to create individual components. Then we repositioned the components on the table. Once we had a layout we liked, we took a photo using a camera phone. You can see the photo we took below:

By doing this, we were able to achieve signoff quicker, because all of the stakeholders were able to signoff the origami wireframe, without needing to wait for another set of amends and wait for another chance to gather together.

You can see the final design of this page here.

Components of the original wireframe rearranged and then captured using an iphone camera.

The desert island discs project is one of the highlights of my career. It does lots of things that I think a redesigned site should do, and working on it gave me the chance to work with some of the best content the BBC has (which lets face it, is pretty good ).

You can find out about the project here, but suffice to say it has been months in the cleaning, curating and building.

My particular role was to lead the information architecture for the BBC. As part of the external projects team (EPIC) for the BBC, I worked closely with magnetic north., a brilliant agency, and a brilliant team.[Props to @cazsotorrio,@raymosley ,  sanj and Adam Todd amongst others for excellent work!]

To start the project, I suggested we domain model the experience, which starts with considering ‘What is desert island discs?’.

The constituent parts of the desert island discs experience are (I believe):

1. The castaway – the guest being interviewed.

2. The presenter

3. The music

4. The artists who wrote and or performed the music.

5. The luxuries.

6. The book

7. The author of the chosen book.

These are the core concepts in the domain model – and each concept has a relationship to other concepts. By starting with ‘What things have we got?’ and ‘How are these things related to each other?’ we begin to articulate the data we have to gather and clean.

Having defined the concepts, we can then define the attributes for each concept. For example, a castaway can be a musician (which means they can have a musicbrainz identifier – useful for the rest of the BBC and elsewhere to identify them). A castaway can also have a wikipedia article about them – which can be easily used to identify that person, since it can be used to derive the dbpedia URL for that person. Having unambiguous identifiers which are webscale (ie used around the world, across the web) helps us syndicate this content if we choose to. It also helps us in the BBC, because these identifiers are used across the business. So, if the music team want to build deep links into the DID site from /music , they can, because they know exactly which artists are being interviewed or played on the programme.

Once we know what data we might want, we can also start to describe a full list of user stories (the things we want users to be able to do).

As part of this redesign, we were required to use much of the BBCs existing infrastructure. Since much of this is well built, it also encourages good practice. For example, we now have a page per episode of desert island discs. We also have a tracklist for each episode, which tells the audience which pieces of music were chosen. This tracklist data is then used on /music to populate parts of artist pages, which gives us many links into the desert island discs site, which benefits the DID site ‘Search Engine Optimisation’.

Desert Island Discs homepage

The data cleanup and assembly for DID took a long time, and also involved a ‘traditional’ IA piece of work – classification. Jo Attree (@romneymarsh) did a great job classifying the castaways and their luxuries. It’s perhaps worth pointing out that this isn’t a traditional library classification – it’s a classification to try to build a great user experience. So, at one point we had a very precise classification, which had several categories with only one castaway in them. Great, accurate, but not that great for the audience if they select a category to be shown only one result. This is what we might call ‘a cul-de-sac’ of an experience.

So, each of the categories on the site have many castaways in them by design. My rule of thumb is at least 5 castaways for each category – not a cul-de-sac to be found until you start really using the filters.

The results of this classification are that the related episodes part of a castaway page really works. The site data is stored in solr, and (while my technical knowledge isn’t expert) solr is matching the classification given to a castaway, and then prioritising those castaways who have audio you can listen to.

As part of the site redesign, you can also now use the URLs of the different pages to talk about the site. Castaway URLs (each castaway has a unique URL) and search URLs should deep link into interesting results (or maybe this one is more interesting) you can blog about!

I am also particularly pleased that this is a multiplatform site – one URL for one thing, delivered in a way that is appropriate for the device being used. So, each URL can be shared and browsed using a mobile phone or a PC.

I hope those of you with screenreaders find the site reasonable to use – if not let me know and Ill try and get it fixed.

Hopefully you find browsing the archive to be useable and fun, I hope we’ve done the great content justice.

Last week we launched the new archers website. It’s an example of how we’re trying to bring structure to the content management systems used to maintain the BBC websites. It’s also an example of publishing the same content to multiple platforms.

The new archers site as an audience facing proposition is not something I can take much credit for. The design and IA of the site was largely determined by Radio 4 and the agency we asked to deliver the site: Airlock.

For example, radio 4’s brief to Airlock was that the old sites user stories should be retained – users should be able to perform the same tasks they could on the old site.

However, the content management of the site, and the interlinking between concepts, and the fact that the site can be delivered on multiple platforms is something that I will take credit for.

Central to this is the ‘domain driven approach’ that I took. As a fan of domain driven design, I try to consider the real world concepts that we talk about when we talk about a soap opera. The net result was the domain model below:

It is one of the most exciting things for me to see content producers move away from thinking about pages, and updating pages, to start thinking about the content again. In this case, thinking about characters, locations, storylines, events. In other words, the things that we talk about when we talk about a drama. [in the diagram above you can see timeline events, but in my head they're still events - timeline events is just where we ended up in the audience facing website, but you can't win them all ].

The fact that the Content management uses the same concepts as the website,and as the audience would use to talk about the soap, makes it easier to work out where you need to go in order to change and add to the content. It makes it easier in project management too because it gives everyone a common vocabulary to work with.

There is no concept of a page within the content management system, there is a character.You want to give more information to that character, you update that characters content and relate it to (for example) locations or storylines within the CMS.

On a mobile device we use exactly the same content, and publish it to the exact same URLs. One of the things that I’m most proud of is that the audience only needs to know one URL to get ‘the archers experience’. We use what is called ‘content negotiation’ to give you back the best experience we can given the device that you are on. I’m very keen on this approach because I think it is an important part of user experience – why should the user have to remember different URLs for the same content depending on which device is being used – the user just wants the content…..the URL is just a piece of information they have to remember to get that content…..try going to www.bbc.co.uk/radio4/features/the-archers on an iphone and a PC to see what I mean – the same URL and the best version of that content that we can supply given the limitations of the device that you are viewing on.

Ideally, we would have used this domain model to create the URL pattern, that would have been part of ‘proper’ domain modelling, but that will be for the next redesign.

Recently we launched a new iteration of the radio 4 homepage. This work was done by clearleft. It was great for me and the rest of the team to see them in action. I thought you might like to hear about some of the design process.

The Design Brief

The brief for clearleft included the following design information:

The Radio 4 website user is typically aged between 30 and  45+ years old. The network also looks to appeal to a mindset – ‘curious minds’ – across all demographic groups.

What are they going to the BBC website for?

* Listen to a radio programme that has been previously aired 94%
* Read a blog: 68%
* Download a podcast 43%
* Comment on a blog 35%

The detail: Specifying the sitemap and user stories.

Before commissioning an external agency, we try to define the size and shape of the project. This helps agencies know the size of the work they are committing to, which helps them and us determine time and cost for the project.

To begin, we look at the amount of content we needed to show the audience. In Radio 4s case, there was some user testing of the old site, which highlighted several issues with existing page designs (see the below user stories). Radio 4s audience have become quite engaged with social media in the past year – there are some excellent blog posts from people like Steve Bowbrick and Paul Sargent which are well worth a follow! There are also facebook sites, twitter updates, which help the programmes connect more directly with their audience.

So, from this we determined that there are 5 pages which will be accessible from a global navigation bar on the radio 4 site:

Home

Programmes

Schedule

Podcasts

Comment

The Schedule page is produced automatically by the /programmes service (something for another blog post). Similarly, the podcasts page is built upon a feed from /podcasts. However, the Home, Programmes and Comment pages were to be redesigned, based upon our requirements. Although there is an automatically produced ‘programmes’ page,  it doesn’t really give them a great sense of what is available to listen to. Users have told us that it takes ‘too many clicks’ to get to what they want.

So, having determined which pages are to be built, we usually specify requirements in terms of user stories. We try to keep user stories non-prescriptive (let the designer design) of how they will be implemented, but make sure they describe the result the user wants.

Having got a list of user stories for each page, we then prioritise them to make sure the most important user stories are answered well. So, for each radio 4 page that clearleft redesigned, you can now see the user stories we tried to answer, most important story at the top:

The Homepage:

As a user:
I want to discover programmes that will interest me
I would like the Radio 4 homepage to give me a good overview of what is on the site
I would like to find a particular programme more easily
I would like the homepage to be as simple as possible
I want the page to be bright and visually appealing, with images and colour
I would like to do less scrolling to find what I want
I would like to listen to an audio clip or watch a short video
I would like the link to the Radio 4 Help section to be more prominent

Programmes page

As a user:
I want to find and listen to a programme I have missed on-air
I want to discover programmes that will interest me
I would like to listen to programmes using fewer clicks
I would like clearer information about what archive programmes are available to listen to
I want the page to be bright and visually appealing
I would like it to be easier to work out what genre programmes fall into (e.g. I would not guess that “food and drink” is a sub-genre of “factual”)
I would like to see all the sub-genres as well as genres
I would like to do less scrolling to find what I want
I would like larger fonts whenever text is small
I would like more user-friendly language
I would like to avoid long lists
I would like less emphasis on the iPlayer, and more on what episodes are available.

This page also needed to be produced and maintained automatically.

Comment page:

We would like to create a visually-appealing page that aggregates conversation about Radio 4 programmes on our site and the wider web. Audience research also shows an interest in more content/opinion/recommendations from key R4 voices, which we feel could be achieved via our blog portfolio and social media activity.

This page also needed to be produced and maintained with minimal resource.

User testing results:

We also had additional requirements for the radio 4 site, that came from observing users trying to navigate around the old site:

Horizontal navigation for a particular programme (for example: The News Quiz )

As a user:

I would like to find the navigation on brand and episode pages more easily
I would like more clarity about which part of a programme website I am currently visiting
I would like links to be more obvious, with a greater contrast between links and text
I would like more clarity between the labelling of “home” and “website” in different navigation bars
I would like more consistency between the labelling of “contact” and “contact us”

Judge for yourself how well clearleft have done with that brief. To help you compare, below is the old radio 4 homepage:

The old radio 4 homepage (pre re-design)

Personally, I think the new homepage is a great refinement of what was their before, and the new programmes page is a particular success (since it satisfies all the use cases, and is now a much more compelling offer).

Let me know what you think.

It’s been a while since I did a blog post. I thought I would write about one of my favourite projects of the last few months.

Quizmaster is a new content management system for the BBC which is specifically focused on multichoice quizzes. Using it, content producers at the BBC can quickly develop and deploy a quiz. The quizmaster platform publishes to facebook, flash, ajax and mobile (Ajax and J2ME) platforms, and is fully accessible.

The project started in March 2009, with a small (but perfectly formed?) company called Kite.

[you can also read their take on the quizmaster platform.]

Back in March we were asked by BBC Radio 2 to develop a multiplatform quiz for the Ken Bruce show, an online version of his ‘Popmaster’ quiz.

As the BBCs Lead Information Architect on this project, and part of the ‘External Projects and Integration Consultancy’ team, it was my job to shepherd the project through to launch. It’s quite a simple looking quiz, but arriving at the final result was a long, and surprisingly convoluted journey.

I can’t take much of the credit for it really (most of that goes to Kite!) but there are bits I’m particularly pleased about.

1. It is fully accessible.

We tested the different versions of the quiz with a wide variety of audience. This included testing with blind and partially sighted users (result: we increased the default amount of time you get to make an answer, and increased the vertical distance between the hot spots for answer buttons in the design). Kite also rebuilt the flash version to be more accessible using tab/enter keys).

The vertical distance between answers increased as a result of user testing

We also did testing with autistic users (result: Some of the comments the presenter makes were made less negative, since autistic users we tested had difficulty recognising them as humour and got upset by them. This is something that I was surprised about at the time, although with hindsight it seems obvious – it’s one of those results that makes me love user testing!

Other interesting bits – the options screen, accessed from the quiz home page, and its impact on the quiz (again trying to keep it accessible).

[But not everything can be made accessible]

The last point about accessibility is the timer. We could have taken the timer out for some parts of the audience (for example if you have difficulty reading the answers within the time limit). However, it wouldn’t be the same game.

Taking it out would fundamentally change the offer to the audience, and the core principal of the BBC when it comes to accessibility is to offer as many people as possible the same experience.

Hopefully, with this project, we achieved that. I hope that the audience with accessibility needs enjoy the resulting experience. If not, let me know, and I’ll try and get quizmaster adjusted.

2. The design is flexible, the technology is reusable.

The same technology platform has now produced many different ‘multichoice quizzes’ for different parts of the BBC, all of them pretty quick and easy to produce, and fully accessible from the start. It would be easy to build a one-off product that delivers a small amount of functionality to bbc.co.uk. I’m pleased that we designed and built a product which has been reused many times across the BBC.

Here are some examples of quizmaster in use:

• Popmaster – the original, flash version.
• Popmaster – the ajax version (more accessible for screen readers)
• Popmaster mobile versions (j2me and ajax)
• Popmaster on facebook

• Glastonbury 40th Anniversary Quiz – Flash version here
• Radio 3 Proms Quiz- Flash version here

And an interesting extension of the original version – the 5live world cup shootout quiz (with a tournement/football match structure).

This version of the game was playable on iPhone and Android mobile phones.

An example question screen from Radio 3's Proms quiz

The Evolution of the Quizmaster

You’ll notice some subtle changes through the different versions, as we try to refine the experience. For example, the proms and glastonbury versions score points for each tenth of a second that is left on the clock when the player answers correctly. In popmaster we scored for each second. This resulted in a large number of players having the same score (not good). The 10th of a second scoring gives much more variations in scores.

Social integration

My favourite way to play these quizzes is on facebook, because it’s really easy to invite your friends, and I think its when comparing scores with friends that it becomes truly fun! [even if like me, you're rubbish, so score really badly!]

My favourite user journey is ‘Send to a friend’  from the home screen (after you’ve decided to play with sound or not), or as I called it, the ‘I forgot to send this quiz to my mate, but I like it and I don’t want to play the whole game before being able to tell my mate about it’. That button (and rather wordy journey) is one I’ll take credit for . I think its actually quite important in improving the chance that the quiz can ‘go viral’ amongst internet users.

Let me know what you think.