Category Archives: design

Team management in large organisations

Recently I’ve been asked to help some design teams in the bbc deliver better work faster.

This got me thinking.

I’ve spent a few years reading about management approaches and more recently have been working as part of the product management team on iPlayer radio. This involved me being responsible for day to day work in one of the teams, as well as being involved in strategy and prioritisation discussions – all great fun.

During my work with the iplayer radio team we tried a variety of approaches from agile, lean and kanban schools of thought.

As you might guess, I have realised there is often no quick fix, no magic bullet.

Hey, you know, like good management is hard!

It is likely that a particular team with a particular set of skills, will need to optimise itself in a unique way.

How do you know you’re making a good decision?

I believe that company values should help you make good decisions. Looking around, many company principles do not actually help you manage a team. Recently created companies like Facebook and Google may prove better at having company values that you can apply to management choices. “Don’t be evil” – right then that’s option b off the table, “move fast and break things.” – don’t worry too much if option d does break things – we will fix it, but it should help us get somewhere useful fast. The BBC’s “trust is at the heart of everything we do.” – helps make decisions, but also makes the leadership risk averse – will it work all the time, can the user trust it? I suspect that value was intended for content, but it is applied across the organisation – is it encouraging the right behaviour for software development? When we are also told to ‘optimise for speed’ that feels like 2 values that can conflict – this is something the BBC should discuss, since conflicting values make decision making harder, slower, and make ‘the right option’ less obvious.

Many times corporate values don’t help with decision making – “creativity is the lifeblood of our organisation.” (Bbc again, sorry) That value isn’t really going to help me make daily decisions, but it might help with longer term decisions about team membership and recruitment.

My theory remains: a few guiding principles for a project should help make quick good decisions. Determining those values may be different for each team. Likewise determining how to apply those values and how much you can apply them will vary from team to team.

My current values to help me make decisions.

Here are my current values that I try to apply on the projects I work on.

1. Optimise for speed, particularly “don’t fall in love”

“Don’t fall in love” comes from Facebook, and means get feedback from the customer within 2 weeks of your initial idea. Any longer than that and you’ll risk being in love with your idea, and therefore a little resistant to changing it based on user feedback, so move fast.

2. Optimise for learning

This is from lean management , and also peter drucker -,your team should learn as much as they can to do their jobs better.

3. Colocate the team members whenever possible.

This is my experience – multi discipline teams that are physically close are more likely to minimise communication errors and collaborate more often and more successfully.

4. Encourage open honest collaboration, no egos and a ‘one team solving problems together’ attitude.

5. Delegate responsibility. Optimise signoff processes and people.

This is really a repeat of Optimise for speed, but in large organisations the decision making is often slow, as :signoff’ involves many senior (overworked) managers, so focussing specifically on this should help the team move faster.

Reviewing progress with retrospectives

Hopefully the above principles help any manager in a large organisation. As a practical process, having used them to run a team of engineers and designers, I’ve found agile team retrospectives immensely useful (even when you’re not a particularly agile, lean or kanban team). Asking the team to focus on ‘What can we do to optimise our performance?’ has been great. Letting ideas for team optimisation come from the team is also part of applying the principle of empowerment. Applying the teams values to this conversation allows us to ensure that the teams behaviour changes in the right way. Suppose the team believes they should improve quality….If a team believed that they should introduce more process to achieve higher quality, that would probably slow down the team, so applying ‘optimise for speed’ makes the team focus on ‘is there a way to improve quality whilst optimising for speed? These values should alter what the team chooses to do. Equally, if the values are useful they can free management up through not having more decision making escalated to them.

What values do you use?

So those values are my starting point, but what values do you find useful? Tweet me @songschris or email chris@chris-thorne.co.uk.

Return on investment in ux planning

I have recently completed an attachment in the BBCs Radio and Music team as a product owner.

The BBC invests heavily in training, and I have greatly enjoyed learning and practicing kanban, scrum (agile), and release planning techniques.

One of these techniques was release planning using return on investment (ROI).

Assigning business value

In the ROI technique, the set of possible tasks are put on tickets – one ticket for each task. Each ticket is first ordered by business value. The most valuable at the top, the least valuable at the bottom. The value of each ticket of work is recorded on the ticket.

For example, here are some (made up) tickets, for a site that already exists, but is being rebuilt:

  • re-Branding of the whole site to give it a consistent feel.
  • New horizontal navigation bar to give users access to significant parts of the site.
  • Revamped search with autocomplete and search results page.
  • New homepage redesign.
  • Content management system redesign

Each task ticket is then given a number for its business value, the highest number at the top of the list of tickets, the lowest number is at the bottom.

In conversation with our stakeholders, we might decide the following business values. These values are made up during that conversation – it is not the value itself but the relative value when compared to other work, that is important.

  • New homepage redesign. (value=250)
  • Revamped search with autocomplete and search results page. (value=150)
  • New horizontal navigation bar to give users access to significant parts of the site. (value=100)
  • re-Branding of the whole site to give it a consistent feel. (value=25)
  • Content management system redesign (value=10)

ROI Release planning lets you answer:

Which bits of work will have high value to the business and be easy to complete?

We can see that the stakeholders really want a new homepage, and also really value search. They clearly see some value in a navigation bar across all pages of the site, and a limited value to rebranding the whole site. The content management system is considered a necessary cost, but if they could get away without having one, that would be fine by them.

Technical complexity using poker points

Now the tickets are re-eveluated by an experienced technical member of staff (usually a tech lead).

Each ticket is considered for its complexity – we can use planning poker points or any other approach. So, the complexity of a ticket now has a numerical value.

The numerical complexity is now recorded on each ticket.

In the case of our made up list, the list is now:

  • New homepage redesign. (value=250, complexity = 21)
  • Revamped search with autocomplete and search results page. (value=150, complexity = 21)
  • New horizontal navigation bar to give users access to significant parts of the site. (value=100, complexity=5)
  • re-Branding of the whole site to give it a consistent feel. (value=25, complexity=13)
  • Content management system redesign (value=10, complexity=13)

Points to note: Don’t worry about the numbers too much. The value of this process is that it results in an ordered list of tickets which can be discussed, not in the exact number assigned to each ticket.

Return on investment is relative

Return on investment (ROI) is now: Business value/Complexity.

The ROI can now be recorded on each ticket.

The backlog of resulting tickets can now be ordered by ROI.

In our case this gives us:

  • New horizontal navigation bar to give users access to significant parts of the site. (value=100, complexity=5, ROI=20)
  • New homepage redesign. (value=250, complexity = 21, ROI = 11.9 )
  • Revamped search with autocomplete and search results page. (value=150, complexity = 21, ROI=7.1)
  • re-Branding of the whole site to give it a consistent feel. (value=25, complexity=13, ROI=1.9)
  • Content management system redesign (value=10, complexity=13, ROI=0.76)

For large groups of tickets, its worth subdividing the group of tickets into smaller ‘feature’ groups. This will help answer “what should we do?”

The tasks in this roi list, with the highest roi number represent your best guess at what is valuable to the business and easy to do?”

 

Reusing the ROI technique in UX planning

The really exciting thing about this approach for me, is that it can be reused in a variety of situations. Particularly, it can be used in planning UX work. For example, we can replace ‘business value’ numbers with ‘user value’ (how much will the user value this feature?). Likewise our estimate of complexity can be based on just the time required to complete the ux work required, or ux+tech+test staff estimates.

So, as a creative director or head of ux, you can now look at a slate of work, and this ROI technique lets you look at the slate in a new way – which bits of work will have high value to users, and be easy to complete?

 

Release planning

Having got a list of tickets ordered by roi, you can now plan a release, by considering a group of tickets you are going to complete for that release.

Using your roi list order, you can see which tickets represent good value.
Some tickets of work will be high value, high cost (therefore limited ROI), and still be worth doing. In our made up slate, the item:

  • Content management system (CMS) redesign (value=10, complexity=13, ROI=0.76)

has very limited business value, since the stakeholders view it as having no benefit to the business (unlikely, but lets suppose). However, if the new homepage cannot be built without a new CMS, the CMS would have to built as well, even though it doesn’t represent a good ROI.

Planning a ux slate using roi

This ROI prioritisation technique can be reused with different axis (user value replaces business value) and it can be applied without having perfect estimates. If we replace business value with user value, we can use qualitative (eg a card sort with sample users) or quantitative (eg traffic data) to find user value.

The list of work ordered by ROI is showing you which tasks look like good valuable work, and which don’t.

For me, it feels like a good technique with which to have very constructive stakeholder or management conversation.

An exciting framework for product management and ux

I’ve been reading 2 interesting books recently.

“The Lean Startup” by Eric Ries is a great book about how to do product management for a new product. In his book, he talks about the development cycle: Build Measure and Learn.

BML

An illustration of the cycle of Build Measure Learn
– Build, Measure Learn. A new products goal is to repeat the build measure learn cycle as quickly as possible. Build a new feature, Measure the user response to that feature – did they want it? Did they use it in the way you expected them to?

If you measured the right things, you’ll know more about what users want. For each feature you can now improve the feature , keep it as is, or discard it. As you learn more about what users really want from your product, you are better able to predict which new features to build.

The quicker you successfully complete a build measure learn cycle, the closer you are to having a successful product.

– Your assumptions about what the audience wants are probably wrong. What a relief! Seriously, it becomes easier to reach agreement between stakeholders, if you able to admit that nobody knows what the right feature to build is. We can hopefully make an educated guess, but that is all. Until its built and you see users using it, no-one knows for sure.

I know from my own experience that a design always changes following user testing. You think you’ve delivered a great design, and there’s always something that needs to improve because users don’t want it, or don’t know how to use it.

Eric Ries recommends a book called ‘The Other Side Of Innovation‘ (written by Vijay Govindarajan and Chris Trimble) which is a great book for those of us trying to improve innovation within an existing (large) organisations.

In ‘The Other Side Of Innovation’ the authors convinced me that in order to complete the measure and learn part of the cycle you need to create ‘hypotheses of record’.

School science projects taught us about hypotheses, so this is quite an easy concept to understand.

Creating a hypotheses of record for a product

A hypothesis for product development needs to be focused on assumptions about user behavior. It also needs to be derived from the core business goals. In many businesses, the business is trying to provide a product or service that users want. By providing something that users want, the business can sell more products or services to the users. The business goal is to get more revenue and profit, which it achieves by selling more products and services to users.

In the BBCs case, in my opinion, the business goal is to increase audience reach and engagement so that when a user is asked to purchase a TV license (which funds the BBC) they feel it represents excellent value for money. There are of course additional aims, notably to educate, inform and entertain, but without achieving reach and engagement, the organisation cannot hope to achieve these subsequent aims.

An example hypothesis for the new BBC homepage might be:

Hypothesis: Given the user experience of the new BBC homepage we expect most users to use the carousel buttons at the top of the page.

What does success looklike? If, with time, more visitors (as a proportion of the total visitors) to www.bbc.co.uk are using the carousel buttons then the design works as well as we hoped. As a subsequent success we would expect to see more clicks through to items within the carousel. Each click through to an item in the carousel represents an increase in engagement. If we see a low proportion of users or a decreasing proportion of users engage with the carousel over time, then we think the carousel design needs to change.

Other parts of a products design can similarly be considered – For a particular feature, what is the user behavior we expect, if that feature works? Which of our goals is this feature going to improve? If we can’t agree with a stakeholder about which business goal this feature will improve, perhaps this feature isn’t as needed as we thought it was!

Writing down a set of hypotheses and how each hypothesis will be tested, forms a “Hypotheses of record”. Once a hypothesis is tested, and the metrics obtained, then we can check our records to see if our hypothesis is correct.

Priorisation of hypotheses

Some of our assumptions are high risk and high cost (ie we don’t know if the audience want this new feature, but in order to deliver this feature it costs a lot of money). These high risk high cost features are the hypotheses we should focus on testing first. If the hypothesis about the user is wrong, we’ve spent less money developing it if we test it sooner.

[Testing a feature can be just interviewing users with a paper illustration of the feature and asking them if this feature is something they would use? Would it make them likely to use the product more often?]

Hypotheses of record in my experience

Recently ive been trying to apply this in my work (building the new bbc.co.uk/radio).

The combination of the ideas above has been very interesting.

In my experience, the conversation between stakeholders and development team can get stressful – particularly when it comes to agreeing requirements.

Typically person A insists that they need this feature, and person B insists that they don’t need that feature, and there is very little data with which to make either case.

Either person might persuade the other that their case is valid, and therefore agree the new functionality required.

However, the conversation and persuasion can be hard, complex and slow.

A “Hypotheses of Record” allows us to complete our measure and learn parts of the Build Measure Learn cycle: We can:

  • Deduce what we need to measure for the hypothesis we are testing.
  • Agree what success or failure results look like. We’re not going to base our decisions on a snapshot of results from our testing. We are looking for a trend in results over time.
  • Learn from the results through proving or adjusting our hypotheses.

In the BBC homepage example, we might see only a few users navigating with the carousel when it launches, but if the number of users navigating the carousel is increasing significantly with time, we might say that the new carousel feature succeeds as a design. If we see the opposite trend, we might say that the carousel design is not working.

Each time we prove or disprove a hypothesis we have more accurate information, which helps us decide what features users want, and therefore what to build next.

This framework focuses stakeholders and product management on the assumptions in the current approach, and the desired user behavior if the product is a success.

These are very very powerful points to focus on – in my experience they shift the conversation from a sometimes delicate negotiation, to a more easily agreed route forward, where testing and evidence from the audience will be used to determine improvements to the product. When stakeholders and product management disagree about a feature, we can still agree the test and the user behavior we want to achieve, and therefore find a positive way forward.

Its still early days in applying this approach, but trying to “Build Measure and Learn”, and creating a “Hypothesis of Record” is proving very valuable in focusing effort and gaining agreement between product management and stakeholders.

The BBC proms website now on mobile phones

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.

Screen Shot 2014-05-22 at 11.45.51

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).

Music charts and playlist data for bbc radio

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:

chart-db-schema
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 using data over a long period of time.

The Archers 60th Anniversary – Social media simulcasting experiment

Its taken a while to write this up, but on January 2nd of this year, we conducted a little social media experiment with The Archers.

The audience were invited to tweet their reactions during the 60th Anniversary broadcast of the show. We built a web experience for users to enjoy. This experience summarised live reactions to the unfolding storyline in the Archers.

We also built a ‘summary experience’ for people to enjoy after the episode.

BBC - Radio 4 - The Archers - Tweetalong 2nd January 2011_1304257653273
Screen grab of the archers tweetalong
The hard work was largely done by the Radio 4 interactive team, and the BBCs social media team, and a company called metabroadcast. [Who are rather excellent at their engineering and getting stuff done]. My role, as usual, was to lead the information architecture for the BBC.

This project comprised an audience experience, with a content management system including integration with the ‘twitter firehose’. The entire development took just under 5 weeks over Christmas. A great example of us doing agile development.

There are several interesting parts to the information architecture:

Despite a careful social media campaign, the hashtag that got used most by the audience was not one prescribed by the BBC, but one prescribed by the hardcore fans, on the archers message boards. They picked up on the marketting that had been done, suggesting that events in the 60th episode would be ‘Shaking Ambridge To The Core’. Their chosen hashtag? #sattc.

Naturally there were several other hashtags in use, each of which had to be monitored by the content management system. For example #archers #thearchers #archers60.

The content mangement system we built can be reused for many other dramatic events. For example, Metabroadcast used it for covering dramatic news in Egypt. It would also work on Xfactor, The Apprentice or any other broadcast where there is a controlled vocabulary of terms (eg peoples names).

Different users refer to the people involved in the drama in different ways. For this reason there are a set of synonyms for a particular term. For example, in The Archers, fans refer to Helen as ‘The Ice Queen’. It’s important to capture this reference to Helen and attribute it correctly.

The word cloud needs to reflect audience sentiment, but also block rude terms. So, our moderators had full control (including revoking approved terms, in case they made a mistake) and could look at the unmoderated list of terms, choosing which are appropriate to be published.

Similarly our moderators have full control over ‘Highlighted tweets’ and can also select a host account to be highlighted in the experience (in this case @BBCthearchers with a title of ‘Plot’ – see the above screengrab).

One of the interesting results of this work was the idea that when you’re moderating in real time, you can actually moderate too quickly for the audience! The highlighted tweets were, in my opinion, updating to quickly to be read by users – something quite distinct to real-time experiences.

The experience seems to work best if it starts slightly before broadcast, and ends after it. That way you capture the lifecycle of the episode – from anticipation to the broadcast, to the aftermath.

I really enjoy the sense of connection that these experiences can bring. It feels a little similar to watching a film or theatre in an audience – the sense of joint participation and connection with the unfolding drama, it’s one of the compelling things about social media in general.

There are many things I would improve about the experience, but I think given the time and effort that we had available, I’m very proud of this work.

All credit to the audience and social media team for the fact that the Archers trended worldwide for an hour on January 2nd 2011. Not bad for a drama that’s been running 60 years :-).

Lorem Ipsum not cool at all

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?

Radio 3 – the bbc proms website redesign

BBC - Proms - 2011 Season Home

An image of part of the BBC Proms website.

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:

proms domain model

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:

consistent navigation
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:

Twitter1303902963577 Twitter1303904477856 Twitter1303904549115 Twitter1303904673065

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.

Origami wireframing

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.

I realised that instead of waiting for these amends, and struggling to get all our stakeholders to signoff a new revision, we could do some (really bad) Origami :-). All the necessary UX was on the original design, just not laid out in quite the right way. So……

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.

website-rapid-wireframing
Components of the original wireframe rearranged and then captured using an iphone camera.

Desert Island Discs

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’.

BBC - Desert Island Discs - Home_1301506560181
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.