[fancy_headline]On February 14th 2014 I spoke at World IA Day in Bristol. I talked about how an IA-mindset that can be shared across UX teams and organisations to seed IA-thinking throughout products and services. Rather than focus on the practice and process of IA, I wanted to talk about how IA theory can have an impact across experience design. Here is what I planned to say.[/fancy_headline]
I work for the BBC in MediaCity, which is in Salford. And I live just outside Sheffield, about 55 miles away.
I get the train to work, so I spend a lot of time standing at train stations and sitting on trains, waiting and thinking. A lot of this thinking is about IA. I think I’m quite lucky. After the day of ‘doing’, I get some time and reflect on what that ‘practice’ might be able to tell me about my ‘theory’ of IA. Because I think having a theory of IA, what it is, why it’s needed, what it can do – is important.
I’m not going to talk about the perennial problem of what an IA is or does. But I think the fact that even in an organisation like the BBC, the topic can still prompt discussion implies a responsibility on us to describe and demonstrate what it is that we bring to a team of brilliant and broad-talented designers and UX professionals.
‘Information architect’ is an evolving and highly prized discipline within the UX&D team at the BBC, but it’s probably worth me coming clean and confessing that technically I’m not an ‘information architect’. Last year, IAs at the BBC changed our name. We went from being ‘Information architects’ to ‘User experience architects’.
There were lots of reasons for this, but I think the chief one was the recognition of what I like to think of as an ‘IA mindset’.
I like to think that the name change was recognition that as well as being able to ‘architect information’, IAs are able to deliver additional value to our audiences if we’re allowed to broaden our horizons and think about the ways ‘information architecture thinking’ can ‘architect experiences’.
I think great information architecture is never just about the information. We do think hard about ontology and taxonomy – but we think just as hard about utility – the experience of spaces and interfaces we help to create – the architecture in use. For a public service broadcaster, the range of experiences that our IA powers is what stands out as a priority. I think it’s good that our job title now has the user in it, as well as the architecture we create…
Now in no way am I denying that IA is a craft. There are a set of specific skills and processes that constitute great IA practice. But I like to think that good UXAs at the BBC aren’t just doing the ‘information architecture’, they’re looking across all of the elements of the user experience and using their skills to improve the end result for the audience.
These are JJG’s Five elements of the user experience. Maybe it’s because I’m an IA, but I’ve always thought we’re the best – and the best-placed to pull UX disciplines together to focus on and deliver the big picture as well as the individual elements that make up designed experiences.
[blockquote]We’re the cool kids”[/blockquote]
People talk about ‘design thinking’ as a way of approaching challenges, and I like to think that there’s a version of design thinking that IA’s are particularly good at. I think we’re able to bring a focus on coherence and cohesion, on the resilience of content to adapt to multiple representations and making information spaces feel like places – imbued with meaning. I think an IA mindset and thinking can influence each element of the user experience to arrive at better, more thoughtful, better value products, services and tools.
Coming to an IA at ‘step three’ of a project, after the strategy and scope have been defined, is missing a trick – it’s too late to get the full value of our thinking. Similarly handing over your sitemap, wireframe and other deliverables doesn’t stretch you to think in literal terms about your architecture in use, you’re halfway through the conversation. I think we can do more.
I think we IAs can be more ambitious. Particularly in an organisation like the BBC. We have 10 online products, 4 screens that we care about. We have multiple formats – text, audio, video and interactive content – we’ve got Guides and study guides, iPlayer and an interactive red button. We’ve got huge live events like the winter olympics and Glastonbury and an archive of over 400 castaways who have chosen their desert island discs. And then there’s innovation and creating new products and services – and that’s mostly what I’m going to talk about today. I wanted to choose a project that I think demonstrates the way an IA mindset can influence a project. So I’m going to talk about a recent set of design sprints.
Design sprints are something that I originally read about Google Ventures doing. It’s a five stage process (usually over five days) that’s great at interrogating a specific challenge or opportunity. We’ve run design sprints looking at new products and services – and this project focused on ideas around personalisation for the product I work on, Knowledge and learning – you might have seen the new iWonder guides for WW1 we launched recently.
We tend to use design sprints early in a project – during a discovery and definition stage where we’re exploring the possibilities. The design sprint process is pretty intense – it collapses a design process into a single week, so it’s a pretty good example to use to talk about where we can have impact.
Each day of the sprint is focused on a different stage of the creative process, so focuses on different elements of the experience. Because of this compressed process you get to think about strategy, scope, structure, skeleton and surface all within the space of a week. I’m not going to talk about the specific ideas that came out of this project – the sprints only ended a few weeks ago, so there’s a lot of work still to be done. Instead I’ll focus on the process, and hopefully you’ll find something in it that’s useful for the way you work.
Let’s start with Day one.
Day one is about understanding the problem or opportunity you want to address. This day is typified by processes of discovery and definition – which sounds like the sort of jobs that IAs should and do excel at. During this stage of a process we’re able to bring our understanding of both the users and product to find the gaps that we can project new ideas into.
Being the start of the week, we understand the requirements of the sprint, what we hope to achieve.
We’ll often string design sprints together – this project saw us complete 3 more or less back to back, so day one is a good day for reflecting on the process – working out what from previous sprints you want to keep and stop or start doing. The rest of the day is about defining the challenge we’re going to undertake in terms of user needs.
One technique that we used extensively in this project was storytelling. I love stories and I’ve met loads of IAs that are fascinated by the form and function of stories in communication and learning – so I’m pretty sure I’m not the exception.
In this project stories were integral to everything we did. We started the week telling stories about a central design challenge. All of these were based on audience research we’d carried out before the design sprints. We told stories about people getting bored on the bus, or stressed on rainy days with the kids, or challenged by a new acquaintances’ knowledge during the local pub quiz. The stories focused on needs and motivations and forced us to start the creative process with the people.
We told three types of stories. ‘Pages’ were the stories of single, discreet interactions, situations or challenges. ‘Chapters’ connected these ‘page-like’ experiences together into longer term relationships and ‘Books’ where interests or needs that had become aligned to the users sense of self and identity – they were ‘that sort of person’. This variety in the types of stories ensured we could focus on different types of solution – some were really low friction, others described the behaviours and needs of our most committed audience members.
At the end of the day we’d analyse the stories, spot similarities, maybe combine one or two and vote on which ones to take forward into day two.
The stories that we choose set the direction for the ideas we create, they also act as a great aid to recruit audience members to test with in the final stage of the sprint.
Day two is all about ideas. I like to think of this day as a combination of flair and discipline – which I think is a pretty good description of what IAs can excel at. We solve difficult problems by working methodically, with discipline and occasionally with a little spark of genius that forces things to fall into place. Day 2 is just like that – we have a reliable process that we go through to create ideas. It starts with the stories that we created in Day 1 – these help us identify needs and opportunities and construct ‘How might we…’ questions to shape our ideas around. ‘How might we…’ questions set a creative challenge, but assume that a solution exists. They also encourage you to think creatively – it’s ‘how might we’, not ‘how should we…’ This stage isn’t a search for the perfect answer, it’s looking for possible answers that could be refined to move closer towards perfection. This is one reason why we use the next technique – Crazy 8s. Using one of these questions we have a rapid session of ‘Crazy 8’s’, which is basically folding a sheet of A3 to make 8 panes and use a fat marker to describe the essence of an idea. It’s not as crazy as it sounds. But the fat marker helps you avoid jumping to too much detail – again this process is as much about interrogating aspects of the challenge as it is about creating solutions.
But refinement is important, even as we think, ‘divergently’. Throughout the day there are planned opportunities to critique ideas and choose the ones to move forward. This is where we combine the creativity with some constraints. We can begin to refer to our understanding of the product, the technical architecture and ‘what’s possible’ to influence and shape the direction of ideas. There’s a definite skill to establishing creative constraints when you’re coming up with new ideas – I think IAs are usually good at this kind of thinking.
We take the Crazy 8 ideas and work them up into simple, single sheet specification. These will be on a single sheet of a4 and usually focus on the 2 or 3 steps that describe the idea in use. These are the ideas that we’ll converge around on day 3.
This day is about selecting ideas to prototype. On Day two we’ve created and described ideas, ultimately creating the simple, single-sheet specifications that describe the idea or feature. As a design team, and with stakeholders, we can vote on these ideas to select the ones to prototype. We can do this in a number of ways – if stakeholders are spread across the country we can photograph the idea sheets and ask for votes and feedback via email. If we’re all able to be in the same room we’ll use ‘dot voting’ everyone gets a few little stickers and votes for the idea they want to take forward.
Again, this stage plays to the strengths of the IA mindset. We’re able to take the ideas, unpack them into individual features or requirements and connect them together. We can see similarities and dependencies, figuring out what gets you from one idea to the next of a supposed user journey. In this project we did this by again relying on some storytelling.
We took the ideas that had been voted on connected them into stories – using the ones created on day one as a rough template. Once we had a sequence that seemed to make sense, we made sure we understood each stage of the story and the ideas. We broke up the stories into features and interactions – preparing to build prototypes to test them. At one stage we even had strands of coloured string, physically connecting the sequence of ideas we would be testing – it looked like we were making a weird 90s detective drama.
There’s a switch somewhere between Day 3 and 4 that marks the adoption of a production mindset. We’ve got the ideas that we’re going to focus on and now we need to work out how to make them work. Here we get a chance to exercise some of the individual crafts of IA, albeit on a scale that’s appropriate for a single day in which to make a prototype.
In this project we were looking at personalisation, so much of the practical IA challenge was about the resilience of content, the ability to chop it up, reformat it and support multiple representations.
I sometimes talk about the notion of ‘informed consent’ in the design and information architecture of a product. I think that throughout the choices we ask our users to make as they navigate our products, if we want them to be genuine choices we need to empower the user through good IA. This is just giving them the right amount of information in order for it to be a genuine choice. I think this good practice is probably even more important in testing prototypes. I’ve been in testing sessions where we spend the time testing and talking about bad bit of labeling, rather than the idea we wanted to test.
Having an IA at this stage of the project can make sure that the prototypes are reasonable simulations of the idea. We used really low fidelity wireframes, making oversized iPhones and iPads from foam board – Users are able to forgive this artificiality, but it’s harder for them to suspend their disbelief when the content isn’t quite right, or the sign-posting and labelling hasn’t been thought through. These kinds of weaknesses in a prototype can wreck a testing session – and when you only have a few in one day, that’s something you can’t afford.
Testing pulls you back to the user. We ran a day of testing – running through the prototype we built with 6 members of the audience. In days 3 and 4 we’d worked hard to understand what we were testing, our assumptions and how we were going to facilitate the discussion.
Because we had recruited testing participants based on the stories we’d made on day one, we’d been able to create fairly compelling and engaging journeys through the prototype. We’d removed some of the barriers by making sure that the testing participant was interested in the content and potentially open to the proposition. It was at least plausible to the users that they might be interested in the things we were showing them.
This ‘plausibility’ is one of the themes that emerged from this way of working. I think an IA mindset is focused on what is possible. We’re analytical and we’re as interested in the gaps as the things that inhabit them. That makes us well suited to spotting when things don’t add up, or when the spaces between designed experiences are too ill-defined.
Another way we ensured plausibility – and something I haven’t mentioned yet is service design.
IAs think in terms of services. We’re good at identifying dependencies – we think taxonomically about our products and services, as well as the information that constitutes them, so we’re good at connecting experiences together into broader services.
Three things that we brought from service design into the design sprint process helped us do this in particular, so I’m just going to spend time on each one. 
One is a much stronger focus on the user. I think this is a good idea for any designer, and maybe especially IAs. Let’s not just focus on the information or content, we need to make sure we’re grounded in use cases and user needs. We can create mental models and then try to translate these online, but we should always keep coming back to measure whether the representations we’re creating both meet expectations and play to the strength of our online spaces.
Last week a colleague was talking about personas. He argued that often creating personas knocks the corners and quirks out of the audience. I think there’s probably something in this. But by using personas as the characters in our storytelling process we were able to add some corners back in – providing creative stimulus – room to inject more personality and fun into our ideas.
The second was ‘Lifecycles’. A lifecycle describes context and need – it allowed us take some universal needs and drivers that we’d identified through user research and focus them on specific contexts.
This project was focused on personalisation and how we could better support people to pursue their passions and interests over time.
Through the lifecycle we described key stages in how our audience might develop and pursue a passion. We didn’t think specifically about online, or even BBC services. We focused on recording each stage in this relationships (in blue), and only then described a possible role to the BBC at each stage (orange). We were also able to record what the audience might be thinking, feeling and doing at these moments (yellow) – giving us more information about needs and motivations as the user transitioned through different states in their relationships.
I like to think of a lifecycle as being a lit bit like a content audit, but an audit of context and needs. It works for all kinds to contexts so is adaptable, and it reliably focuses you on the user needs and motivations at different times and places.
Into the context described through the lifecycle we start to project our service and experience, to begin to build an ‘experience blueprint’. This is like a layer on the lifecycle, where the ideas we’re creating meet the needs we’ve identified. As the sprints progress we place the ideas on the blueprint – connecting them to the contexts and user needs we’ve identified.
This tool again helps us with ‘auditing’, plausibility and feasibility. We can document what we’ve already got, and add layers to describe the internal tools, technical architecture, content, partnerships we have in place to deliver and support the ideas. The experience blueprint can therefore become a tool for creating ideas and documenting them – complementing the product roadmaps that our product owners and managers create and maintain.
Although these two tools in particular might not be the kind of thing that IA is associated with, I think this is the sort of thing that we’ve always done. We’ve understood content, user needs and intentions and then made recommendations. I think as the structures we create become more dynamic, as the set people we need to talk to and convince becomes broader, as disciplines evolve, we’re going to need to adopt new tools and techniques.
So I’ve talked a bit about a design process, design thinking and the stages that an IA might be useful – and I hope you’re not asking yourselves – why? In fact, I hope you are. ‘Why?’ is the most challenging question we’re often faced with. We need to be able to handle it.
I think, if IAs are able to extend their sphere to influence and activity out of the professional practice and craft of IA into other areas and elements of the experience, our IA-thinking, our perspective and skills, the type of people we tend to be, can make the world a better place. I think this is both a challenge and an opportunity.
I think there’s sometimes a frustration amongst IAs that the discipline isn’t well understood. People ask ‘surely it’s not that complicated’ and ‘can’t you just do a sitemap and forget about the process’. Lot’s of our work is invisible – so we’re often going to be faced with that ‘why?’ question. It’s easy to try to answer just by saying ‘because it’s the right way to do it’, but that isn’t enough.
Experience design on the web aims to crafting meaningful and useful experiences through ‘information spaces’ – that’s why IA will make the world a better place, because if we can use our skills and mindset to influence and augment the creativity of other disciplines – we can make things that are more meaningful and more useful.
So if this presentation is about using an IA-mindset which can influence and enhance the various stages of the user experience, it’s also about ensuring that that mindset is focused on the user.
I think we can sometimes become hypnotised by complexity and we fetishise order and structure… but I find the most valuable moments when I’m thinking about IA is when I look up from the spreadsheet or the domain model and look at the world as it is – because only by looking at how the world is can we hope to improve it.
The thing that I love about the IA-mindset is that it often forces you to put the “what” and “why” before the “how” – we understand before we ideate. Understanding precedes making. The bits are always going to be important to the information architect – and after we’ve understood them, we get the joy of putting them together to power experiences our audiences will love.
I hope I’ve found the right level between the practice and theory. But as I said, I spend a lot of my time standing on train stations, waiting, and thinking – and I’m sure not done thinking about these issues. I really enjoyed presenting these ideas at World IA Day, and the feedback during and after the event. If you have any comments or questions about this or any other IA-related issues, please get in touch.
Leave a Reply