Recently I gave a talk at the 2011 IA Summit in Denver. It was prepared by me and Michael Smethurst, and covered the great work that has led to some of the BBC’s most respected online projects over the past few years; notably Programmes, Food and the ever-shiny Wildlife Finder.
We cheekily titled the talk ‘Beyond the Polar Bear’ in reference to Rosenfeld & Morville’s book Information Architecture for the World Wide Web, which has been the standard text for IA for over ten years. It wasn’t a case of saying that book was flawed (indeed it is still an excellent introduction to the organisation and classification of content), but the domain-driven approach practiced at the BBC speaks to a different, and perhaps wider, view of information architecture. You could say that IA itself is in a transitory state, becoming ever more conflated with the broader (and in my view, more vague) term ‘User Experience Design’. That’s a rant for another day, but with a growing number of UX designers emerging who have no grounding in IA at all, it’s timely to propose a model based on the state of the web, and the industry, today. Here beginneth the lessons…
5. People think about things, not documents
When I’m geeking out over vintage Disneyland (as I do), what comes to mind is a messy blur of stuff; Adventureland, Tomorrowland, the Haunted Mansion ride, Walt Disney’s apartment above the fire house, the various incarnations of the Disneyland model in Florida, Paris and Tokyo. I could go on (in fact I did, here). The point is that I’m thinking about real-world stuff, and the often complex relationships between those things; John Hench designed the Cinderella Castle in Main Street and Space Mountain in Tomorrowland. Pirates of the Carribean is a creative concept that spawned not only the original attraction, but the subsequent movies, video games and lunchboxes.
However with traditional taxonomical IA, a lot of that complexity gets lost. We organise webpages into ever-broader sections and categories, less like a tangled web and more like neatly-stacked russian dolls. Often we won’t structure by ‘thing’ at all, but instead by type, leading to categories like ‘photos’ and ‘videos’ – which isn’t much more advanced than the dark ages of the web when you’d routinely see ‘Links’ as a main menu option.
At the BBC a new model for making websites has taken hold. Domain-driven design puts the emphasis on the real-world connections between things, rather than the tree-like hierarchy of webpages. It encourages us to expose the most important things within our chosen subject (or business) and then sketch the graph-like relationships between those things. If we’re designing a website for a restaurant chain, those things might be locations, cuisines, dishes, ingredients and providers (since it’s no longer enough to be served mere bangers and mash, but Cherry Tree Farm Lincolnshire sausages with mashed Saxon potato). Ultimately, each of these ‘things’ may be represented by a document (or other machine-readable) resource, but by using things and relationships as our means of organisation, we expose a navigation model that better fits with a user’s mental model, and thus opens up a wealth of user journeys where the links between resources can serve as informative content. For example, BBC Wildlife Finder features animaly stuff like Species, Habitats and Adaptations. By connecting the Giant Panda to the Broadleaf Forest and the Herbivorous adaptation, we’ve not only learned some stated assertions about the Panda, but can see which other animals display those characteristics.
A thing-based structure acknowledges that we are trying to represent reality in our information architecture, and furthermore that a desktop webpage is only one of those representations. Equally we could serve up mobile views, TV views, RDF or microformats. Consistency across platforms comes from the relationships between the things.
4. Canonical concepts help people and SEO
Sometimes however, the complexities of reality don’t exactly map to our idealistic mental models. In my head, there’s a novel called Wuthering Heights published in 1847, The Beatles released their album Rubber Soul in 1965, and Star Wars is a movie that came out in 1977. Would that reality were that simple. In fact, countless editions of Wuthering Heights have been published over the years (including one with added raunch!), Rubber Soul has been reissued in various vinyl, cassette, CD and digital formats, and don’t get me started on the ever-shifting sands of Star Wars re-releases. Maybe sometimes my thinking is even more abstract; my mental image of Wuthering Heights is of the tragic and doomed love between Heathcliff and Marmaduke [citation needed], moreso than the pages and binding of a physical book, or indeed any movie or musical adaptations of that story.
Clearly then, we formulate our mental models around comfortable levels of abstraction. On the web that most often surfaces when we search for things. But when I Google, say, ‘wuthering heights amazon’ I get back a boatload of results, many arguably correct yet still leaving me to do the guesswork as to picking a result. This isn’t great for me, neither is it great for Amazon, since their Googlejuice for the term ‘wuthering heights’ is splintered across their inventory. It would perhaps be better for both of us to have an Amazon page referencing the general concept of Wuthering Heights, and aggregate all the various books, DVDs and CDs onto there. This after all is what works so well for Wikipedia; a single page per concept, mostly at a search-friendly level of abstraction, but containing all the nuances of that subject within the page. One page per concept makes it obvious where people should link to when referencing that concept, which is one of the reasons Wikipedia is so often used as a citation in online articles.
On the BBC website, managing this level of abstraction for programme pages results in resources at series and brand level, or conversely, it’s why there’s one page per episode of a show, but not one page for every time that episode has aired. BBC Nature aggregates programme clips around its canonical ‘thing’ pages, so when you Google ‘BBC lion’, you’ll get the Lion aggregation page, rather than a ton of pages for the separate clips. BBC Food used to have a similar ‘splintering’ issue to Amazon, whereby the 280-odd results for, say, “apple crumble recipe” likely resulted in option paralysis. By redesigning the Food site to conform to a domain model, the concept of the ‘dish’ was established; an abstract concept of apple crumble from which the individual recipes could be linked. This was particularly advantageous for that site, since due to rights-restrictions individual recipes come and go. Directing traffic primarily toward the canonical dish page establishes a persistent URL displaying all currently-available content.
3. URL design is a part of User Experience
URLs. We see them every day on business cards, buses, and boxes. We share them via email and social media. They are the connecting nodes that make up the web itself. Yet too often they are overlooked as part of user experience design. Effective URL design should balance three main principles: They should be hackable (so that foo.com/products/gangly_wrench can be chopped back to foo.com/products) thus serving as a form of orientation and navigation. They should be human-readable, since this makes them memorable and easier to promote, and above all they should be persistent.
Persistence means your URLs never change. After all, the web is made of links, and if the URL of a resource changes, it effectively becomes disconnected from the wider web. Your URL is an implicit contract with those who have linked to you or bookmarked you, so presenting users with a 404 is as heinous as changing your telephone number without telling anyone. But designing for persistence has implications. To truly future-proof your URLs, you need to remove anything that is subject to change. Do all your URLs end in .php? Then you’d better not be planning to move to ASP any time soon. Got something like ‘…/music/artists/Prince’? Good luck managing that when he decides to change identity again.
When the BBC designed their URL schema for Programme pages, they had to accommodate the inherent volatility in TV production. One-off dramas can morph into series. Series routinely hop from one network to another. Even programme names themselves can change on the long road from planning to broadcast. It was a tough call for a project aiming to provide a persistent URL for every BBC programme broadcast, and the solution was a URL format whose only human-readable component was the one thing they knew for sure: it was a programme. They opted for bbc.co.uk/programmes/:pid (a unique alphanumeric ID to identify each programme). The use of unique identifiers doesn’t exactly make for human-readable URLs, but you can be damned sure they’re not subject to change.
Persistence should be supported by pointability; allowing your content to be referenced uniquely via its URL. Employ a ‘one thing per page’ policy, describing a single topic at a single URL. This strategy has been instrumental in Wikipedia’s ubiquity, since it encourages linking to that topic page whenever the topic is referenced elsewhere. If your documents and media assets have URLs they can be pointed at, otherwise they can’t. It’s that simple.
2. Rapid prototyping means real prototyping
UX dogma loves to big-up rapid, iterative prototyping; putting small, spit-and-sawdust versions of a product into play, rather than diving headlong into building the super-duper version. This is all well and good, yet the tools employed – Axure, Flash, paper mockups – are inherently fake, and therefore fail to test the most important mechanic; how people interact with actual content. Worse still, they are throwaway deliverables; expensive to create, but contributing nothing to the actual development effort required to create the live site.
Better then, to prototype using the native tools of the medium: HTML, CSS and Javascript, connected to a database of real content. This necessitates getting the data model (and thus the content strategy) in place up front, but that’s undoubtedly a good thing anyway. If information architecture is the management and structuring of information, then it must follow that this needs to be in place before worrying about how the user interface looks. Rough web pages that broadly structure and position content can be created relatively quickly, ready for iterative design embellishment. The beauty of this approach is that your protoype is actually an early version of the live site itself, so no effort gets wasted.
It’s probably heresy for many UX designers more comfortable in the Adobe suite, and who may consider HTML/CSS as client-side development that just ain’t their bag, but perhaps it’s just a skills gap that’s yet to be closed. In his IAS11 talk, Jared Spool asserted that the ‘most valuable UX person in the world‘ is one who can code. The increased efficiency in having a designer implement their own vision using native tools is clear, even if the resultant ‘code’ isn’t exactly production-ready. It also forces designers to work with the art of the possible, rather than tacitly suggesting functionality or data relationships in their wireframes that are presumably supposed to be realised by developer magic.
Real prototyping means UX can break free of its culture of interim documentation, and actually get on with making the damn thing. There’s little need for persona documents or paper prototypes when you can put real users in front of real content, real fast.
1. User Experience isn’t just what you can see
Every time a project manager says ‘We need someone to do the UX on this’, God kills a kitten. User Experience Design is NOT limited to the user interface, and yet it’s tough to shake this perception that UX is a kind of glorified interaction design, post-rationalised and invoice-enriched through a bit of cod-psychology and ten-cent sociology.
On a practical level, every layer of a web build has significant impact on the experience a user will ultimately have. User Experience therefore touches everything from the business strategy, through the content and data modelling, to the many and varied ways that this content can be served to users. In that sense, everyone involved in the project is contributing to its design, and thus we need to do away with this cultural and procedural divide whereby the white-collar (or more likely black t-shirted) ‘designers’ ideate in a vacuum, before tossing their Photoshop comps over an invisible wall for the blue-collar ‘techies’ to build.
Domain-driven design (as practiced at the BBC) begins with breaking down the elements of a subject domain, connecting these elements via their real-world relationships, then mapping the conceptual ‘things’ to available content. Once you start to work in this way, it’s hard to imagine a more sensible approach. Domain modelling is user-centered design at its most elementary, upon which can be layered all manner of sophisticated, device-appropriate presentation models, safe in the knowledge that you’re building on solid foundations. This is a web that has moved away from ‘sticky’ siloed websites, towards a decentralised dissemination of content via search and social media. Presentation and interaction are therefore less important than the content itself, which sounds blitheringly obvious when you say it out loud. The new wave of Information Experience Design Architects need to worry less about interaction, less about taxonomy, and more about making content findable, pointable, searchable and sharable.
I am, as ever, indebted to the boys: For some less theatrical, more practical grounding in these practices, check out the seminal How We Make Websites by Michael Smethurst, or this equally-lovely webcast by Silver Oliver.
It's not the despair. It's the hope. 