O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a navegar o site, você aceita o uso de cookies. Leia nosso Contrato do Usuário e nossa Política de Privacidade.
O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a utilizar o site, você aceita o uso de cookies. Leia nossa Política de Privacidade e nosso Contrato do Usuário para obter mais detalhes.
1.1. For the past thirteen years, “the polar bear” book by Lou Rosenfeld and Peter Morville has been an invaluable constitution for our industry. Maybe today we’ll be drafting a few amendments to that constitution.
You see, a lot has happened in that time. Google happened. Facebook and Twitter happened. Smartphones happened. IPTV happened. The paths to content have splintered, and the way we access information has become more organic and ubiquitous.
Today we’ll look at how the BBC now makes websites that better represent their core business,better fit how the web is today, and deliver on the mission they’ve had since 1922 to inform, educate and entertain. My colleague Michael Smethurst can’t be with us today, but he’s here in spirit; when we get to the science bits, it’s all him and his team. We’ll go on to discuss how you too can apply these principles, and if there’s time I’ll include the customary IA Summit rant about how you’re all doing it wrong.
And on that note, I should say that any implied frustrations with UX practices, whether intentional or incidental, are entirely my own.
2.1. As the polar bear teaches us, information is hard to categorise. We have a raft of tools and techniques to help us, from card sorts to use cases to content inventories, but at the end of the day, when we draw our taxonomical site map we know we’re making a series of compromises and workarounds to ‘best fit’ the limitations of that structure. In many ways, taxonomical site design hasn’t really moved on from the traditional library science approach where a physical book has to go on one physical shelf. In the last few years we’ve done things like tagging to expose more subtle facets of information and thus unlock more user journeys, but still information architects are largely limited to saying that one thing is more or less specific than another thing. So we do our card sorts and we label our boxes and we cross our fingers that our homepage superordinate categories will give some clue as to the goodies within, then get frustrated in user testing sessions when people demonstrate that they don’t visit our homepage at all, but deep link to our content from Google.
2.2. At the BBC no-one knows whether to refer to website singular or websites plural. In theory, our website is bbc.co.uk, but the reality is that small BBC web presences popped up over the years like tents on a hillside, and still in user research we hear people refer to…
...the news site, or the iPlayer site, or the CBeebies site.
The BBC publish a massive amount of content, 1500 programmes across its 8 national TV channels, 10 national radio stations and over 40 local radio stations every day. Over the years its been difficult therefore for a large organisation to represent its offering online, and there have been political, cultural and technical hurdles to overcome, and consequently they ended up building a web presence in just about the most expensive and inefficient way possible: teams working in silos, hand-cranking out pages all over the place. For years the BBC site or sites just weren’t very joined-up, have suffered from repetition of content (which is a curse of such a large and fragmented corporation), pages that aren’t linked to so have terrible SEO…
…pages that get mothballed (whatever that means) because the programme they supported isn’t on anymore, or removed completely throwing 404 errors…
…and most recently a government-appeasing diktat to reduce the number of “top-level directories” by half. Weird, for something that’s supposed to be one website, and all a bit embarrassing for a broadcaster regarded as the best in the world. Recently, as part of a strategic review, the BBC has pledged to cut its spending online by 25%, which will lead to a major loss of resource and so force a new, more efficient way of publishing content.
2.3. At the BBC, and arguably even beyond, the grey squirrel of user experience design is gnawing the legs off the red squirrel of information architecture. The focus is now squarely on the presentational and interaction elements of UX, and service design projects that start with beautiful, but largely imaginary page mockups. In a great metropolitan company right now, a senior executive is being seduced by a Photoshop comp that may or may not be buildable.
The perception is that rapid prototyping, by which I mean faked-up prototypes, are cheaper and easier to develop than anyone getting their hands dirty with code. So these things get incubated in a vacuum, which come to think of it isn’t healthy for anyone. UX design and prototyping commits a lot of product decisions, sometimes unwittingly, before anything gets in front of a real user, or before software developers are consulted about the art of the possible.
LINK TO NEXT BIT: So at the BBC, this whole web thing needed a bit of a rethink, and some rebel forces, striking from a hidden base, won their first victory against the evils of siloed thinking. They recognised the power of the semantic web; and how it could be used to build better bridges between content, extend user journeys and stitch all of the BBC’s offering into a single, extensible framework. Its a process that allows great things to be done quickly with real, not mocked-up content, and brings UX, software development, product management and users as equal partners to the process.
3.1. Usually when we’re doing some heavy IA, we’re trying to think about how our subject breaks down, and at the same time, how the website should be organised. We’re like librarians, finding the right boxes to place our stuff in, so we might do a card sort, and then we might end up with a box for photos, another for videos and a third for news. Two problems here; first is, that as we know, web documents don’t fit neatly into prescribed categories. The relationships between bits of knowledge are much richer and graph-like than just ‘broader and narrower’. The second problem is that when we think about our favourite subject, we’re not thinking of documents at all; we’re thinking about things.
Things. Real-world things. Last time at this conference I spoke about Disney theme parks. Disney World is a real place, in a real location. It has some theme parks in it. Each park is divided into lands, and as Disney fans know have an iconic weenie. The lands have attractions, each of which were created by someone, and might be based on, say, a movie. Then there’s the hotels, that have restaurants. Oh, the lands have restaurants too. The restaurants have meals, which might be associated with a character. And that character could be also be based on some prior art.
3.2. So in looking to represent a subject online, we think first about the things in that subject, long, long before we ever think about web pages. At the BBC the book Domain Driven Design has become the new bible. It proposes not a taxonomic, but an ontological model for modelling subject domains, called, appropriately enough, a domain model. It’s really just an attempt to accurately capture a user’s mental model about a subject; identifying the most important things in that subject, and the sometimes complex relationships between them. Domain modelling is now the first step for building new web products at the BBC, and is the key to an approach that has seen us move away from a process that starts with wireframes and Photoshop comps, to one that starts with a logical model of the subject we’re covering and working upward from there.
3.3. This is a simple domain model for music. In fact there are various ways to present a domain model. Sometimes its a simple diagram, other times a more complex entity relationship diagram, but always the point of it is to define the most important things and connect the dots between them. A recording artist creates several tracks, and a track might be released in more than one place; a single, an album, or greatest hits. We define release types to cover these kinds of releases, each of which has a date of release associated with them and a record label they were released under. You can start to see how describing this process through a simple hierarchy would be difficult.
3.4. The first step in building a domain model is to speak to people who really know their onions. Let’s call them domain experts. They don’t need to know anything about web design, just their specialist subject. Maybe you have some in your company, or if you’re freelance, its a great way to give clients direct influence over product design before you start to hate them. Get your expert to describe, or better yet, sketch their world to you. Ask lots of questions and uncover the hidden complexities. When we talk about a soccer match, how is that organised? Do matches exist in isolation, or are they part of a bigger competition? Soon you’ll find out what the experts think are the most important things and the relationships between them.
3.5. But we’re all about user-centred design, so your next conversation is with end users. After talking to the experts you’ll have at least a prototype understanding of the subject, but you may find users have a simpler or just different view of the world. It’s more important to get the model, and specifically the language, right for users. After all they are the ones who’ll be searching on Google and hoping to access your content according to their own mental model.
Again, sketch their world back to them. Identify the key things and figure out the relationships between them. Remember this isn’t yet about web pages, just modelling the subject itself.
3.6. Now we know from all those card sorting exercises we’ve done over the years that labelling things is hard. And defining conceptual differences is even harder. I like Wuthering Heights. But what do I mean by that? That I like the book? Or maybe I like the movie? Or maybe even the Kate Bush song. If it’s the book, am I thinking of a specific edition of the book, because all of these are different things. Or maybe its the overall concept of Wuthering Heights that I like, distinct from any specific manifestation; the creative work, if you will. In mapping a mental model you find that some things are harder to quantify than others. Outside of domain experts, people may find it hard to name things appropriately, even if they can appreciate the inherent differences between, say, The Beatles’ album Rubber Soul and all the other things that could also be said to be the same thing.
3.7. But defining the damn things is vital if you want to be able to point at them. To take our Wuthering Heights example, I expect most people wanting to buy a copy of the novel are thinking in general terms; not of a specific edition. Yet Amazon have no concept of a ‘cultural work’, so to them two different editions of Wuthering Heights are really as different as a copy of Wuthering Heights and a copy of Pride and Prejudice. When you Google Wuthering Heights you get a bunch of different Amazon results, which isn’t so great for their Googlejuice as one ‘master’ Wuthering Heights aggregation page would be. Plus they’ve had to put hacks in place to merge reviews together, so often you’ll find, say, complaints about the quality of a DVD version of a movie on the product page for the Blu-Ray. So we think about the basic level at which people are searching for things, and try to first represent a ‘canonical’ version of that concept.
3.8. Actually this touches on some cognitive science, if you know your Lakoff. Basic-level categories are the level at which we most readily identify things. They are the simple names we give things as kids; Dog, not Husky or Mammal. Car, not vehicle or Mustang. Tree, not Oak or plant, and we somehow see them as more important, or ‘cognitively real’ than higher or lower-order categories. Not only that, but that within a category there are what’s called ‘prototypical examples’; so if I asked you to name some furniture you might say chair or table, and even within chairs, there are probably things you’d think of as more chair-like. If we were playing Family Feud and I said name a type of bird, you’d probably say robin before you’d say ostrich.
In domain-driven design your goals is to get a ubiquitous language; an agreed lexicon used by everyone on the project team, which means in turn that the same terminology is used all down the stack from database tables to CSS classes to menu options. This way everyone on the project has a shared understanding and things don’t get lost in translation.
3.9. So where you stop? What are the limits of your domain? When creating your domain model, you may find that some things, like people or places branch into whole other subjects. This could mean a link between your model and someone else’s. Often the BBC domain models link into the FOAF (Friend of a Friend) ontology, which has been created to describe the relationships between people. The BBC music site makes extensive use of MusicBrainz, which describes all the releases made by recording artists. It may even be that other parts of your website deal with some of your domain objects, in which case its okay to link out to these pages. The point is not to replicate content unnecessarily, and don’t reinvent where someone else has already done the thinking.
3.10. But the good news is that you don’t have to get it right first time. As we’ll go on to see, the domain-driven process is heavy on iteration, right down to this fundamental level. Things change all the time; either new requirements come in mid-way through a project, or once your site has launched you’ll find that the things you thought were important aren’t proving so popular. The chances of you getting the model right first time are slim.
LINK TO NEXT BIT: Domain modelling is a big deal; bigger than we can cover in this quick run-through. The Domain Driven Design book is a coffee table read. Heck, it could be a coffee table. Hopefully this gives you some idea of the process that the BBC has put into practice. Let’s look at that practice now; first with how the BBC Programmes team met a long-held ambition: a way to make a permanent page for every one of the 1000 programmes the BBC puts out across TV and radio every day.
4.1. TV is a messy business, and was never designed to be put into much order. Sometimes one-off shows become the pilot for a series. Sometimes, the schedulers will decide that a 2-part story is like a mini-series within a series. Our general sense of a ‘show’, like Glee or The Wire or Silent Witness is what in the BBC they call a brand. It’s a different thing to a particular series (or season) of that show. Silent Witness, unusually, has sub-series within it, and of course individual episodes. And different versions of episodes, most commonly the version that goes out with sign-language.
Sherlock was a popular show recently, but it only had three episodes. What does that make it? Can we even answer that until we know its future? For now, Sherlock is a brand with some episodes, and it has an associated channel – BBC One – that it aired on.
But if there are more episodes of Sherlock made, how would that change? Maybe it would become a full series, or more likely, the new episodes would become series 2, which means we’d then have to define a series 1, which changes the current hierarchy of things. It could also switch to another channel. It’s problems like this that the Programmes team have to make sense of.
4.2. By talking to programme schedulers, the Programmes team came up with a domain model that describes the main objects within the domain, and the relationships between them. The brand is the highest level object. This is, if you like, the overall ‘cultural work’; something like Doctor Who. Well, Doctor Who has a number of series, though any fans will know that even that gets complex depending on whether you started counting in 1963 or 2005. Each series has some episodes, each episode may exist in different versions, and all of these have either been broadcast at some time, or available on-demand at some time. Collectively we call these things ‘programmes’, and they go out on (and in the possessive world of media, sometimes want to be associated with) ‘services’, which was an attempt to find a word that grouped TV ‘channels’ and radio ‘networks’.
4.3. That was the basic model, but it’s not much use without data. There’s tons of business data available about programmes; episode titles and synopses, broadcast dates, that kind of thing, perfect for populating this model. Only really not perfect, because was built for production staff to use around things like compliance and rights management, wasn’t consistent, and was never intended to be user facing. It took a lot of work and workarounds for the web team to whip this data into the right shape. And that’s an important lesson in itself; just as you know better than to replicate your company’s org chart in your site structure, don’t be a slave to the inherited data model, because often it just won’t be right, or at least complete.
4.4. With the model now populated, only then did the team start to work on anything resembling web pages. Because of the things and relationships already put in place, outputting a ton of linked webpages became relatively straightforward and for the first time in web history, a broadcaster had represented all its output accurately, persistently and scalably on the web. The approach generated one single web page for each ‘thing’. One page per programme, with one URL to locate that programme. Why is this important?
Just look at the success of Wikipedia, which has many thousands of single pages, each discussing a single topic.
Having a single URL makes it easy to point at that thing, which makes it easy to link to, and so easy to blog about and tweet about and generally share. Internally, it means content teams know exactly where to put their multimedia niceties to enhance that one page. And it focuses Googlejuice squarely on a single location, making it easier for people to find.
4.5. URI design is an important, though often overlooked part of the user experience. We use some guiding principles in making nice web addresses: they should be persistent (in other words, always reliably there), hackable (so people can chop them back at the slashes as a means of navigation), and preferably human-readable (since that’s just nice). Balancing those things can be tough, but as the hierarchy of needs shows, the most important one is persistence…
…after all as Tim Berners-Lee says, “Cool URIs don’t change”. Your web address is an implicit contract with the people who link to or bookmark your site.
But how do we maintain persistence with content that is subject to change? What do we need to look at. First let’s get rid of the extension - no-one cares about the technology, and one day we might change technology anyway. Is keeping the series part okay? Well as with Sherlock, that could change, so let’s take that out too. BBC One is the network, but one day this show might move to another network. The name Sherlock is unlikely to change, but across dozens of TV and Radio stations it might not be the only show with that name, so let’s lose that too. Which leaves just episode1, and that doesn’t make much sense at all.
So in fact, the URL format used leaves just about the only thing we know for sure; it’s a programme. The unique ID lets us pinpoint that programme. It leaves a URL that is only partly human-readable, but we’ve at least made pretty sure it’s going to be persistent.
4.6. So the Programmes site launched with a whimper, quietly giving people URLs to link to when referring to any BBC programme…
…from the worthy and educational ones that make good use of our public funding…
…to the ones people actually enjoy watching. No longer would only the popular ‘brands’ get a web presence. Did it set the web alight? Not at first, at least not to people outside the IA community. Because while the modelling was a major technical feat, content really is still king and beyond having episode details and air dates, the Programme pages were light on delight. They called it a skeleton in need of muscles and skin. Pretty soon though, programme content teams took a pride in having their own pages to embellish, and things got a lot richer.
First by embedding the programme itself onto the page (pretty cool, thanks to iPlayer - the BBC’s equivalent of Hulu) and then production stills, behind-the-scenes clips…
…even track listings for the music used - which got very cool when the team made those things clickable and linked to the Music domain.
4.7. Programme pages have become the standard for representing programme content on the site. Gone are the days of siloed teams making siloed microsites that were full of glory while the TV show was hot and then left to wither when it was not. Instead there is a completely scalable ecosystem that comprehensively represents the BBC’s massive output. Still, people do quite like those programme microsites, so content teams have been given the tools to make branded support sites using Programme pages. And of course you still need URLs you can put on the side of a bus, but thanks to some polite web redirects our on-air announcers don’t need to say “just go to www.bbc.co.uk/programmes/b006ml0g”. The experience is a lot like the old microsites (maybe losing the downloadablewallpapers and Flash games - though you could even have those if you really wanted) but instead of being siloed, they’re stitched into the wider fabric.
We’ve even started to explore modelling things within the content of a programme like characters, locations and plot events, with a view to recontextualising stories beyond the confines of the episode.
LINK TO NEXT BIT: But modelling programmes was only the start of the story. On a business and content stack largely built around AV content, once you can point to programmes, and even to individual bits of them, you’ve unlocked a ton of content you can then use to make more products.
5.1. The BBC Food site was always doing okay, but never that great. Its a recipe database, a bit like Epicurious, and justified by the fact that the BBC make a lot of cooking shows, and people needed to go somewhere to get the recipe. Well I don’t know about you, but if I want the recipe for apple crumble, there’s only one place I go first - and that’s Google. I’ll get back a ton of recipes and I’ll probably pick one from the first couple of results. SEO therefore is hugely important in the totally saturated recipes market, and frankly the SEO wasn’t great.
They had apple crumble alright; too many of them which splintered our Googlejuice. How then could SEO be improved, and more value from the content be unlocked?
5.2. The Food team went back to consider the things people think about, and in this case the things that people are searching for. In my modern, sensitive view of the world, men think about Nigella while women think about chocolate. When he thinks Nigella, he thinks chocolate cake. Meanwhile she’s thinking of a show she saw this morning that had a chocolate cake recipe on it. Great minds think alike.
This is how that looks as a simplified domain model. At it’s heart is the recipe, which is written by a chef, and has some ingredients – and sometimes, recipes, like chicken stock or corned beef, can make something then used as an ingredient in another recipe. It might have an associated technique, such as how to knead dough or scoop out lobster brains, and because this is the BBC, the recipe has come from a programme. Then there’s the all-important dish, which we’ll come back to.
Now think about the content of a recipe; a lot of this data is in there, but usually its baked-in as static, unexploitable text. Through applying domain modelling, the Food team were make each ingredient and even some techniques into a pointable thing, and so able to move the site from ‘sauces’ to ‘resources’. Oh yes.
By modelling around the structure of a recipe, they unlocked new ways of exploring food and cookery. “Show me all of Nigella’s cupcake recipes”. “Show me what I can do with this zucchini”.
5.3. Most important was the concept of the ‘dish’; another example of having a master canonical ‘work’ - a mental image of Spaghetti Bolognese if you will, from which individual recipes could be hung. The dish gave something for people to point at, consolidating all the Googlejuice toward a single URL. It gave a more stable structure too; recipes are more rights-protected than you might think, but even when a specific spaghetti recipe had to be removed, the canonical dish stood firm.
The recipes were carefully selected and named by studying the search analytics. We used to have the oh-so-fancy name Vichyssoise, until we found out people were searching for plain old leek and potato soup. All the photographic love and fancyness was quickly migrated to Leek and Potato soup.
5.4. So this focus on unlocking many new and interwoven routes to content, along with a big push on SEO-friendly language massively boosted both internal link density and external linking. Traffic to the Food site has doubled. BBC Food now has 20% of the UK recipes market. 150,000 extra search users each week. Let’s look at those users for a minute and ponder something else.
Last year the site saw a 20% rise in access from mobile devices…
70% of traffic comes directly to recipe pages from Google; far more than from the BBC Food homepage, and I’ll bet those referral figures are similar for a lot of other sites too.
So which is the real BBC Food homepage? Web, Mobile or Google? The old rhetoric that your homepage is your most important page is no longer true. According to the traffic, at best 30% of effort should be on the homepage, and 70% on your thing pages.
LINK TO NEXT BIT: Finally, let’s look at what is perhaps the standard bearer for domain-driven design at the BBC. A site whose subject could be said to inherit a domain model, and needs more data than even the BBC can provide.
6.1. Wildlife Finder is a showcase for natural history footage, something the BBC has a reputation for of being the best in the world. But far more than being a simple video gallery, it presents these clips in a new and useful way, attempting to show how the natural world joins up.
Educational, informative and entertaining clips have been pulled from thousands of hours of archive footage.
Specific clips from more general programmes have been extracted to focus on individual animals.
The learning is not just in the clips themselves, but in how the species, adaptations and behaviours, habitats and ecozonesof the natural world are connected.
What does the Polar Bear have in common with…
…the Barn Owl?
Both are polygynous; where one male mates with multiple females, but each female mates with only one male. What else is polygynous?
Maybe the Hippo, which is herbivorous, lives in flooded grassland and is - uh oh – on the vulnerable list. You could lose yourself for hours in these user journeys, but unlike sites with randomly related content, each onward link is teaching you something new.
6.2. As you can imagine, the domain model is rich, and based part on the Linnaean taxonomy for biological classification. The natural world is of course a huge subject, and while we have a natural history archive stretching back 50 years, that only provides the video clips. There aren’t teams of elves working away to attach the written descriptions needed for every creature in the animal kingdom. Oh wait, there are.
It’s just that they do it on Wikipedia. Yes, the Wildlife team are fans of using the whole web as their content management system. Need a description? Pull it in automatically from Wikipedia. Do some Wikipedia entries suck? Yes, so edit them directly on Wikipedia so that everyone benefits.
The clips in Wildlife Finder are defined as being segments of programmes, so link to the BBC Programmes domain. Similarly, the conservation status of animals is maintained, not by the BBC, but by the University of Michigan. While the distribution data comes from the WWF.
This hints at the power of using linked data; treating the whole web as your database from which you can draw bits and pieces of content to plug the gaps in your own offering.
6.3. Once again, these thing pages are the canonical work that gathers the Googlejuice and gives people a place to point to and talk about when they want to reference lions, tigers and bears.
But it doesn’t end there. Because really, these pages are a collection of a whole bunch of individual audio and video resources, each of which can be accessed individually. The Wildlife team have made it easy for developers to access this content and add it to their own meshup applications…
…right down to using the same URL format as Wikipedia. By using a known URL scheme and by being able to serve content in HTML, RDF and the species microformat, the Wildlife Finder site is also its own API. If you’re a data-hacker, go dream up the next big thing.
6.4. And in fact the Wildlife team continue to build next big things, using the resources and thing pages as Lego bricks. The big addition is curation, addressing one of the main criticisms of the domain-driven approach; namely how to add some editorial voice, a human touch if you will, to the order laid down by the data model. Curation is a layer on top of the resources. It collects together hand-picked examples and uses them to tell a particular story. The first example was to get the naturalist David Attenborough to pick his favourite wildlife moments, and since then there have been light-hearted collections like Wildlife Wind-Ups to ones to promote events like Year of the Tiger. Collections add new context, timeliness and promotion; an alternative view through the eyes of presenters and film makers. This kind of curation enhances the experience without undermining the structure.
LINK TO NEXT BIT: The success of these projects has changed the way we make websites at the BBC. From Music to the Solar System to the Olympics and World Cup and soon to History. The domain driven design means everything not just links to, but seamlessly integrates with everything else. Let’s recap the approach.
7.1. First develop your domain model by exploring the subject and talking to domain experts and end-users. List the things they talk about and sketch the relationships between things. This can be done with as simple or as complex a diagram as you deem appropriate. Define the most important things, and develop a ubiquitous language used throughout the technology and user interface. The objective is to map a mental model that works for both casual users and subject experts. Think only at this stage about representing the subject, not about creating webpages.
7.2. Develop data model and populate. Working in collaboration with a software engineer, translate your domain model into a database schema. Check to see what data is available within your organisation and if any holes may be plugged by data available from external providers (either through commercial licencing or for free) and user community data (via the Twitter API, that sort of thing). Reshape data as appropriate to be able to pipe into your domain-model-based schema. Don’t just expose your internal data models as-is. Consider latency issues, sadly still a problem for using web data in general. Data availability decisions will iterate the domain and data models. Remember you have the option to expose only parts of the domain model based on available data.
7.3. Design URIs for all the individual resources and aggregations you’re going to offer. The URI scheme should follow your domain model, and follow as far as possible principles of persistence, hackability and readability. Please don’t expose your technology in the URL. It isn’t necessary, it isn’t pretty, and it’s a problem for URI persistence should you change your technology platform down the line. Maintain a policy of one URI per thing, one thing per URI. Don’t worry about building taxonomic hierarchy into your URLs; those garden swingsets in your product catalog could equally appear in the boys and girls sections. Get extra credit for using web-scale identifiers if possible to make it easier for outside developers to meshup your content: remember it’s in your interest to give your content as much possibility for reach as you can. Make your URIs human-readable if you can but avoid including anything that could change over time. If content must move, do it nicely: Use 301 redirects for permanent redirection, 302 redirects for temporary redirection.
7.6. Test and iterate. Actually you should be doing this at every step. This whole approach is about getting to real code, real data, real content and real users as soon as you can, not generating lots of interim, well-meaning, but ultimately fake deliverables. From sketching domain models back to users to verify understanding, to putting real people and not personas in front of your basic layout pages, to testing again once the pages are prettified. Test understanding of the conceptual model, not just of the interaction. The advantage over top-down design is that your product is far more malleable and able to adapt to new requirements – you haven’t painted yourself into any corners. For every development cycle, test and iterate again.
8.1. Understand that user experience goes far deeper than presentation. It reaches down through all the layers of this software trifle, and as an IA or UX designer you have responsibility to get your hands dirty throughout. Business logic, SEO, pointability, document design, URI design, even server load and caching; all these things have a profound effect on the experience your users will have when interacting with your content. And all of them are facets of information architecture. The approach practiced at the BBC puts IA at the heart of an end-to-end service design, not just interaction or presentation. With great power comes great responsibility.
8.2. Think about your content in terms of things, not documents. The standards exist to allow you to add semantic meaning, allowing you to model complexities in knowledge and make links between things represent a specific - and actually machine-readable - relationship, as we’ve seen with the Wildlife Finder. Adding semantics involves two things: allowing documents to contain machine-readable information, and allowing links to be createdwith relationship values. When computers can read our stuff properly, we can use them to do the heavy-lifting we’d otherwise do by hand, like saying “show me all the Blu-ray players under $70 from suppliers who offer overnight shipping” or “where in Denver can I get a hair appointment for 3pm tomorrow?” - all of those things could be built fairly trivially today if only the suppliers and the hair salons published their data in the right format.Understand the business you’re trying to represent, and understand the most important things - both to the experts and to the customers. You might be thinking that domain modelling is all very well for an enormous content provider like the BBC, but even if your project is a site for your local restaurant the main principles apply. What would diners care about? Dishes? Cuisines? Local producers? Paired wines? How do these things connect?
8.3. Think about the web as a whole, and how your contribution can make it a better place. The World Wide Web didn’t evolve by chance. It was designed by a man, who said “The Web is designed as a universal space. Its universality is its most important facet.” We are supposed to use this space to share information, not to build ourselves ivory towers. Make your stuff easy to point at, and easy to share, and convince your bosses of the value of the increased reach this gives you. Design using web-scale identifiers where you can. And reap the benefits of shared information; enhance your own content with linked open data. DBpedia is a great place to start - it’s an open database with all the information from Wikipedia and it’s free to use.
8.4. Bottom-up everywhere. Don’t begin your design process by thinking about web page wireframes. Instead start designing from the domain model and data model upwards. Put most of your effort into your core content pages - thing pages - rather than the home page. Most of your traffic will be from deep links into your content. Google is your front door. Design for your least-able user first. This isn’t just about accessibility for screen-readers; I pretend to care about that kind of accessibility as much as the next guy. The Googlebot is your least able reader, but could be your best friend. Mobile users too; Mobile traffic to the BBC Food site is up 20% from last year, so this isn’t about throwing a bone to fringe users, it’s about maximising reach.
8.5. Make friends with a software engineer. In the advertising industry, great work is done by pairing and art director with a copywriter. Just think what a dynamic duo an IA and a coder could be. Be agile and iterate often. Prototyping is fine, but the real rapid prototyping tools are not things like Axure or Flash, they’re things like Ruby, PHP, CSS. How much more effective will your prototypes be if they’re powered by real data, real code, so they can be put in front of real users, real fast. Doing it for real isn’t really more expensive than creating tons of UX documentation, but it does takes some new skills - and that investment is far outweighed by the benefits. I really do think as a community we need to move on from the kitsch user story comics and persona posters if we want to be taken more seriously. Heartbreaking I know, because I enjoy making those things too.
8.6. More than anything, accept that the web has changed since the Polar Bear book first came out, and that some of our practices need to change with it. Of course, we’re still about creating the shortest route to content, making it easier for people to find what they’re looking for. We’re still about defining, and to some extent classifying information. But the emphasis is no longer on using taxonomic library science to build a series of private libraries. Access to information is perhaps more ubiquitous and fractured than ever before. Consider the whole web as your canvas, and make your content mesh seamlessly into it. Design for a world where Google is your homepage, Wikipedia is your CMS, and humans, software developers and machines are your users.
LINK TO NEXT BIT: In closing then, have we gone beyond the polar bear? How do we keep up with a changing web? Here comes the ranty bit.
9.1. Yes, the web has changed from documents to things. People, Locations, Things, verbs can have URIs associated with them to form the basic of semantic assertions. Google may not be a fully realised semantic search engine yet, but that’s largely because it doesn’t have your metadata to work with. In some ways the web is going back to its roots; away from corporate silos and toward a shared, open network of information. Today, the public at large are doing your information architecture for you, by bookmarking, tagging and socially curating your content. Half of all social media traffic to websites comes from Facebook. Can people easily point to your content from there? The polar bear asks ‘Does your site need search?’. The BBC has a site search, yet 70% of traffic to Food is coming from Google. So probably not, because Google is your search. Hell, Google is pretty much your information architecture.
9.2. Modelling the complexities of knowledge with all its semantic subtleties turns IA from largely taxonomic to ontological; from boxes and arrows to wibbly-wobbly lines. Many of the practices outlined by the polar bear still hold true; finding the right labels for your things is still vital (and still hard), you need to consider the many and varied facets of your content, and know the value of metadata; although we’re not talking here about tagging your webpages after the fact, but designing with metadata from the ground up. But the polar bear’s main message is one of managing broader and narrower categories, be they uniform or polyhierarchical. And as the book acknowledges, that has never been a particularly accurate fit for modelling information. Things have properties, and those properties inter-relate with other things.With an ontological structure the definition of the links between things becomes as important as the things themselves.
9.3. I believe there’s an elephant in the room, and it’s getting bigger. Information Architecture, like Rodney Dangerfield, “can’t get no respect”. It’s struggled for years to define itself and, as a result I think, sold its soul to the Technicolor religion of user experience design. We’ve become known for the quality of our documentation, and talk introspectively in conferences about abstract processes rather than the actual projects we’ve delivered. We’re getting squeezed by interaction designers on one side and software architects on the other. Some places I’ve been, the IA team meetings are held in clandestine priest-holes, with that team often bitching about how they’re seen as irrelevant in a culture that favours design led by flashy conceptual prototypes, or overtly technical engineer-led solutions. But I wonder if its just a skills gap to be closed. In a web of semantic information, is it less about detached deliverables like Axure, paper wireframes and persona design, and more about learning to wrangle information - data - at its source? The UX niceties like curation, seductive interactions and, God help me, gamification, can be layered on top, but we have the power to tame the roots and branches of knowledge itself. There are rich social graphs to mine, appetites for infographics and data journalism, growing repositories of free data to exploit and the hot topic of user-owned social data and identity. And if architecting information isn’t a job for an IA I don’t know what is.
Deep Cuts Across The Online
Division<br />The BBC has made a commitment to halve the number of ‘top level directories’ on its site<br />In 2011 it will reduce its online spend by 25%<br />Controversy has arisen over a recent announcement that legacy content will be removed from the web<br />
UX emphasis on the top
Fake ARTIFACTS<br />Projects usually begin
with extensive front-end prototyping tested against user stories and personas, not actual users<br />The belief is that ‘real’ technical prototypes are too expensive to develop<br />
A way of representing the
important ‘things’ within as subject, and the relationships between those things<br />A way of using the subject knowledge of users and experts to influence software design<br />The first stage in the BBC’s process of designing new websites, and one of the few tangible artefacts<br />Inspired by Eric Evans’s ‘Domain-Driven Design’ book<br />What is domain modelling?<br />
What a domain model looks
like<br />ALBUM<br />LIVE<br />artists<br />release types<br />SINGLE<br />COMPILATION<br />releases<br />release events<br />tracks<br />labels<br />
Talking to experts<br />Domain experts
need not be technical, they just need to know their subject<br />They will help you understand the important and complex things<br />Break out the pencils and sketch their world back to them<br />
Talking to users<br />round<br />competition<br
/>Use their language; learn how they speak, what they consider important and how they search<br />Users may understand the subtle differences between concepts, but can struggle to label them<br />Your aim is to capture their mental model<br />stadium<br />match<br />team<br />goal<br />player<br />
The canonical thing<br />Novel editions<br
/>Film adaptations<br />How about something like<br />bbc.co.uk/works/wuthering_heights<br />?<br />Wuthering Heights<br />The ‘Master Work’<br />Has a general sense of wutheringheightness.<br />Musical adaptations<br />
Creating a ubiquitous language<br />Defines
a common lexicon used by all members of the team, at all levels of the design<br />Labels for things can be informed by thinking about basic-level categories<br />Specific priority of things can be informed by thinking about prototypical examples<br />domain model<br />CSS classes<br />user labels<br />
Don’t reinvent, link<br />In defining
your subject, define the boundaries of your domain<br />Where objects touch existing models, use them instead of replicating them<br />If canonical content pages already exist on your website for domain objects, link to them<br />Don’t have more than one page covering the same topic<br />
Test Understanding and iterate<br />Verify
the model with experts and users as soon as possible<br />Check against business requirements and available content<br />It’s not too late to change, even after you’ve started building<br />
Getting the data right<br />Massive
amounts of content, so metadata needs to be captured during business as usual<br />Many data systems were built for production purposes, not for users<br />Quality of data capture and labels used varies across departments<br />Data needs to be reshaped to best fit the domain model<br />
Choosing a Nice URL design
Pattern<br />http://www.bbc.co.uk/bbcone/sherlock/series1/episode1.shtml<br />Don’t expose your technology. No-one cares and it might change anyway.<br />http://www.bbc.co.uk/bbcone/sherlock/series1/episode1<br />Is it really series 1 until there’s a series 2? Will it be the same overseas?<br />http://www.bbc.co.uk/bbcone/sherlock/episode1<br />What if this show moves to BBC TWO or another network later?<br />http://www.bbc.co.uk/sherlock/episode1<br />What if Radio 4 decide to do a programme called ‘Sherlock’ in the future?<br />http://www.bbc.co.uk/episode1<br />Hmm, well now that doesn’t make much sense at all!<br />
Making microsites<br />Model allows for
fully-skinned and even restructured pages<br />Additional material can be associated at brand, series or episode level<br />Marketing URLs are redirected to the Programmes space<br />User experience is enhanced without undermining the structure<br />
Desktop TRAFFIC vs. mobile<br />89%<br
/>10%<br />1%<br />Of the top 2500 search queries November 2010 saw over 20% of searchers arriving via smartphones alone - an increase of 20% since October.<br />Source: Google Webmaster Tools<br />
Where does Food traffic come
from?<br />70%<br />30%<br />other<br />Most visitors arrive into the middle of a site, via a deep link, not via the homepage.<br />Source: Google Webmaster Tools<br />
Develop a domain model<br />Talk
to experts and end-users<br />List the important things and sketch relationships<br />Develop a ubiquitous language<br />Think only about the mental model, not webpages<br />
Populate your data model<br />Work
with a developer to translate your domain model to a data model<br />Look at your business data and reshape if necessary<br />Identify sources of linked data to enhance your product<br />Don’t reinvent where someone else has done the thinking<br />
Design URIs<br />Design for persistence,
hackability and human-readability<br />Maintain one URI only per thing<br />Don’t expose your technology in the URI<br />Don’t include taxonomy or other things that may change over time<br />Use web-scale identifiers where you can<br />
Build pages<br />Start with simple
stub pages for all your objects<br />Think about all representations, not just HTML<br />Design your document to put the most important things at the top<br />Consider requirements for caching and load-balancing<br />
Apply layout and décor CSS<br
Test and iterate<br />Test at
every stage, from the domain model upward<br />Test not just interaction, but the conceptual model itself<br />Test with real people, not against personas or user stories<br />
UX Thinking All the Way
Down<br />User experience goes far deeper than presentation and interaction<br />Consider things like business logic, SEO, document design and URI design<br />Take your rightful place at the heart of service design<br />
Think Things not documents<br />Design
your content for a semantic web, modelling things and relationships<br />Understand the business you want to represent<br />Consider the domain modelling approach for projects of all sizes<br />
Think of the Web as
a Single Shared Space<br />The web was designed to be universal<br />Design your content to be pointable, sharable and used to plug gaps in the Web<br />Use the data published by others, and publish data of your own<br />
Think Bottom-up everywhere<br />Don’t start
Team with a developer<br />Design
in the browser, using CSS frameworks and code that references real data<br />Be agile and iterate often, putting your prototypes in front of users<br />Focus your personal development to meet the skills gap between IA and software engineering<br />Standards-based CSS framework<br />Standards-based web editor<br />Design in the absence of content is not design, it’s decoration.<br />Jeffrey Zeldman<br />Living, breathing wireframes!<br />
Think How the web has
changed<br />It’s still about making the shortest route to well-organised content<br />Primary routes to content have shifted from silos to aggregators<br />Design for a world where Google is your homepage, Wikipedia is your CMS, and humans, software developers and machines are your users<br />
The new Information Architect…<br />Thinks
about real-world things<br />Thinks ‘user-experience’ from the ground up<br />Designs for mobile first<br />Designs for search and social media<br />Wrestles data from around the web, and publishes their own data back out<br />
Beyond the Boxes and Arrows<br
/>The complexities of knowledge call for ontological structures<br />Relationship values attached to connections teach us how the world joins up<br />Reusing content and linked data across domains greatly unlocks value and maximises investment<br />
Playing nice with The Other
KIds<br />Has IA turned into UX?<br />Has this put the focus on interaction and presentation?<br />Can we make a more direct contribution to the building of web services?<br />What skills will that require?<br />Photo by Oliver Klink<br />The way to get started is to stop talking and start doing.Walt Disney<br />
Thanks to<br />Michael Smethurst@fantasticlife<br />Silver
Oliver @silveroliver<br />Chris Sizemore @onpause<br />Chris Thorne @songschris<br />Tom Scott @derivadow<br />Paul Rissen@r4isstatic<br />Patrick Sinclair @metade<br />Further Reading<br />‘How we make websites’ by Michael Smethurst<br />bbc.co.uk/blogs/radiolabs/2009/01/<br />‘How does the emergence of the semantic web change the way we think about information architecture?’ by Silver Oliverblockslabpillar.com/2010/09/18/<br />‘Some thoughts on curation – adding context and telling stories’ by Tom Scott<br />derivadow.com/2010/03/11/<br />This presentation appearing soon at<br />slideshare.net/reduxd<br />
Picture Credits<br />THANKS TO<br />flickr.com/photos/<br
/>cobalt/4330261604<br />dtaylor28/4369801559<br />debbcollins/4620829591<br />notm/1499506651<br />krustysplodge/1297721427<br />fcam/2476027735<br />peadar/2487923494<br />joncandy/3931662699<br />smaira/3721669619<br />phes999/1180686827<br />peterbecker/233071629<br />andertoons-cartoons/2517000136<br />benmcleod/11391970<br />89142790@N00/3212373419<br />danbri/2415237566<br />rapettif/4399201987<br />jjay69/4050882410<br />rwr/281039209<br />philip_d/2559996327<br />photos/saariy/2612208165<br /><ul><li>“Linking Open Data cloud diagram, by Richard Cyganiak and AnjaJentzsch. http://lod-cloud.net/”</li>