Speaker - Mallory O'Connor

Well, hello. Thank you everyone for coming to Vancouver if you've never been here before. My name is Mallory. I'm super excited to be here. I'm so overwhelmed by Sarah's talk and I'm going to be so boring in comparison, but I really want to get to know you a little bit over the course of the next couple of days. I'll give you a little preview so you can talk to me about trail running and my happy place when I see the mountains, being in the trails and that's where I get my joy and refreshing sort of energy when I'm not looking at a screen. So my previous career before user experience was in psychology. I’ve always been really interested in what motivates people and why they do what they do, online and offline. So as Steve mentioned. I work with Habanero, which is a local company that’s been around for about 20 years and I started -- I couldn't believe this, I said this to someone the other day, nine years ago and they were like, nobody works anywhere for nine years.

[laughter]

And but I've had three jobs there. I started as a senior information architect so I really like working on structures for websites and intranets, I then did user experience consulting and strategy, a little bit more broadly across the organization and then for the past three years I've been the practice lead for all of Habanero’s public fasing websites and extranet work. before habanero, I was a user experience consultant, freelancer, for agencies, startups, mostly enterprise organizations.

So as Steve was mentioning, back in 2003, I actually worked with a couple of colleagues and we started up the Vancouver User Experience group. Sort of getting people to come out in the course of their careers in Vancouver and it's actually how I got to know the folks at habanero is they were our first sponsor. Last year was our first year putting together the Vancouver user experience awards. It was an incredible event and we're working on the 2015 version so if you're from Vancouver or if you want to make the trip, we have an event, and the submissions will be opening in the fall, and that will be coming up in November.

So enough about my background. Today I really wanted to start by sharing with you what my presentation is about. It's really not about that first up-front content strategy and setting the vision for a project. Which is why I said maybe it would be boring to some of you, I don't know. For me it's about this scary moment, the moment of maybe panic or reality, whatever it might be, where you’re working on a project and the vision is established and you're maybe, working on a website or an internet or app or whatever it might be and you have that moment where you go we need to deliver on that strategy and holy shit, when is that due? So the focus is less about the development of the strategy deliverables and more focused on the execution of them. So my goal today is to share some advice about some tried and true ways that we've been able to deliver on some of our projects, so that your team can successfully deliver content in amongst the challenges and constraints of the real world.

At habanero we call that moment crossing the killer content chasm, because we've managed to do it a few times and so I want to share these ways to offset that panic, and so that you can calmly craft amazing content, in the context of those maybe seemly impossible parameters.

Here's a project that we worked on for CP, one of the national railways in Canada and this is an example of how we were able to use some of these techniques I'll share today to create a fully responsive, enterprise multilingual customer portal and we did it in 90 days. So I'm going to share some of the processes with you that contributed to that success and hopefully this will help you cross the chasm, too.

I love structure so let me break it down for you. I'm going to cover four major areas today. One of the foundational building blocks is forming a really awesome team. I’ll cover some of the commitments you'll need from that team once you've identified who they are, and also some of the support you'll need to probably negotiate in order to protect that team throughout the course of your project. The next thing I'd really like to focus on is once you've got the team, you have to get them prepared and so to do that you really need to give them some context about the strategy. You need to help them build their skills so that they can actually deliver and provide them with all the training that they need before they even sit down to write. And here's the piece that I'm probably most excited about. It's about using an agile inspired process to really drive better collaboration and ultimately content delivery on your project. And then looking forward. And lastly, what are the things that we need to prepare for in maybe the not too distant future. We're seeing content showing up in this increasingly complex, personalized and targeted way and this is a more complex world than it once was. So those are the areas I'd like to dig into.

So building a team may not be as easy as sort of just selecting a few people who maybe want to work for your project and so when you create your team I'd like to start with a piece of dead obvious advice. This may seem totally obvious, but the earlier you'll start, the better. I don't know how else to say that. Otherwise you just run out of runway. So 90 days isn't a long time for content execution, especially for this detailed content, multilingual process. So let's assume that on your project you're following best practices and you've got a content strategist, you've got a UX designer, developer, you're all working together, collaboratively, and you create this awesome, rock-solid content strategy. Maybe you've got prototype, you've got a great design, you're ready to go, but even with all of that stuff in place, you ultimately need a ton of brute force from your content delivery team, especially in enterprise projects.

I think this really relies on a content team that's on task right from the beginning, because if you don't, and you leave that detailed content execution too late, you're going to have to some sacrifices, right? Timelines, quality, and probably the engagement of that team that you've been working with. So without that early start there just won't be enough days in the calendar without that sacrifice.

Let’s say you’ve got your team, and assuming that you've started early, you really need to figure out what the scale of your team needs to be. So depending on the size of the project, and your organization, you might have a team of 2 or 5 or 20 people on it and there's a bunch of roles that need to be covered off.

The content strategist. They have done all the research, they hold the established the strategy, the structure, the guidelines, can answer all the questions. Then you're likely going to have a content lead. The content lead would be someone who sometimes we call them an Editor in Chief, to borrow from publishing, sometimes they're called the web editor, or they're just like the content wrangler. They need to make sure the content happens on time, on schedule and they reprioritize things on the fly. So they are the get-shit-done person. And then there are going to be the content owners, the people who are responsible for the accuracy and the consistency of content across the entire operation. And you'll also be consulting with subject matter experts.

You also have a team of people who are content authors, so those are the people who actually write according to the content authoring guidelines, HTML guidelines, the style guides, and they will create the content in whatever method is appropriate for your project, be it Word documents, you know, they're dirty but they work. It could be in a prototype, it could be in an external tool. Whatever works for the project. But you'll have people who are actually crafting the content.

And then depending on the size and scale of your project, for CP, we had years and years of performance data that we actually had to lift and map and move from one system to the other, so content migrators are there for that process. So you might, like I said at the beginning, have a small team or a large team, but these roles ultimately all need to be represented.

So the next step in forming an awesome team is being incredibly clear about what you expect from them. You're going to have to use all of your powers of persuasion -- I’m not going to say bullying, but you really do need to use charm and this is the most charming persuasive person I could think of. And you're going to need to be really up front with them. How much time are you going to need from them? You need to tell the team are they going to expect to spend 50% of their day? 75? 100, what do you need from them? They need to know. How long will that project be? It could be a 90-day project or it might be a 6 month or a one year project. Your team needs to know before they can commit.

And here's the fun part: how many meetings do they have attend? You know, are they going to have a daily stand up? Are they going to communicate, collaborate with the development team, with the design team? What does that all look like together? And here's my favorite one. What about my vacation? I already have a ticket booked.

[laughter]

So sometimes we have to have, you know, a tough conversation, say you have a corporate priority and that person -- is the only person who can create and write that content. You might need move things around in priority. Or maybe that person needs to adjust their expectations for when vacations happen. That's terrible. But it's not just about communicating your expectations with the team. They're going to get it. But it’s also managers, project sponsors, so that they play a role, too, in protecting that team and making sure that they have the dedicated time and opportunity to live up to the expectations that are from required from them for the project.

I think sometimes in large organizations we don't recognize that. Part of helping the team understand expectations is demonstrating a little bit of shock and awe about what's coming down the pike. Here's Andrew. He's one of our content strategists, he's a huge advocate for scaring the hell out of people and saying, you know, this is a real deadline, you need to make the deadline real, the commitment real and also the workload. Here's what you need to expect. And while it may be a scary message up front, the other thing about it is if you pretend it won't be hard work at some point it's going to snap back at you. So it will be hard work but it's better to be up-front.

And it kind of looks sometimes like this. The language that they're going to speak is going to be Excel, content maps, this is the language that they need to get familiar with and that's part of setting expectations. If they know what's coming, they'll be prepared for what they have to do.

In creating a team I think the key success factor here is communicating what your expectations are so that they can live up to them. That's the content team, that's the other stakeholders in the project, the project owners and that shared expectation will help build a solid foundation for your project. Without it, you'll struggle to deliver.

It's quite possible that you know you've got these members of your team. Maybe they've never, ever worked on a project like this before. Maybe they've never written for the web before. Maybe they've never even used a CMS before. You never know what you're going to get and if they've had an experience maybe it was a really terrible one. So you really need to create an environment where you can build up your team skills before they've even crafted a word.

It's really important to share the context and provide the team with a solid understanding of the strategy. Because they're on the hook to deliver it. You need to share the why. And so by briefing the team on all of these components of the strategy, you will actually bridge the gap between what's been approved and validated and circulated amongst the business, and what their job is to do.

By going through all of this, you have the opportunity to demonstrate and explain, to be peppered with questions and address them and you have this opportunity if you do this up front to save a ton of time, especially when you have tight constraints around delivery time and you also ultimately, you're creating the team and giving them the opportunity to become this army of advocates for the strategy. Because they're going out into the world and they're collaborating, the immediate team will be familiar with it but as they go into the business, they will be advocates for the strategy and be able to answer about the process.

So now you got the team, they should know what they need to create and why, now they need to under the process and what the how is. So they need to know everything. They need to know the schedule. What's assigned to me. What is the creative editing feedback process going to look like. It's not enough to just say here's how it's done and off you go. It's kind of more of a -- I don't know to be successful, I think you need to sit down and you need to be side by side with the team as helping them and coaching them along. As they gain the confidence and are able to understand and navigate the process, eventually you'll be able to step back as they get their mojo and they'll be completely independent and they'll be alone on the later phases. It kind of reminds minds me of parenting actually. So there's a bunch of tactical skills that you're going to have to do with your folks. Like I said, some of them have never written from the web before. How to teach them best practices. Scannability, accessibility, tone is everything. So making sure they're up to speed on that.

There's also the matter of the CMS. It could be that this new project you've got a brand new CMS or it's an upgrade from an old one. Regardless you're going to have a team with varied skills and a one size fits all training methodology might not work. You need to assess where people are at in terms of their technical skills and you need to provide training that's appropriate to them. There's also going to be style guides so that authors can write sort of consistent and semantically marked up correct content and so your UX designers and your front end developers can create a live and current version of each component in the style guide throughout the process so that authors are always referencing the most up-to-date information. Content migration is kind of a nasty little secret, right? if migration is a component of your project you're going to have to decide whether it's going to be automated or manual or a combination of the two. Whatever approach that you take will be determined by the complexity of the path of migration, and whatever approach that you take, the team needs to be trained on how it's going to happen. And ultimately all of these skill builders that I've mentioned, they're really there to train the team. You can see that I talked about a lot of things they need to do before they even start writing so that means in your timeline you have to put some time aside for this process, otherwise ultimately it's a time-saver up front so you can deliver more effectively and efficiently throughout the process.

The third area I wanted to talk about is agile. I'm not a developer so I'm not an expert on agile development. But my team does agile work and relies on agile development. A lot of it I would say deals with the complexity of scope and dealing with aggressive timelines so the concept of prioritization that comes from agile is really interesting. And the idea was that we've seen how effective this had been in development and it helped us meet our commitments and get there really quick and we wondered if it could work from a content perspective. So we tried it and it turns out it actually works. What were the things about agile that we loved?

Focus on light documentation. And we liked the visibility and team's accountability and insights into challenges, priorities and communication. And lastly it really helps deal with those fixed timelines. So if we apply those to the content process, we set the stage for this highly collaborative team.

On CP, we have daily standups. We always had them at 9, people would be calling from home or their cars or whatever, but it was set in stone that we had them at 9. We aligned the content cycles with the development with the entire team. The extended team was entirely in synch. We empowered the team to resolve challenges right at the moment that they happened and to shift effort and resolve issues. We focused on the 80/20 rule and basically made sure that we focused on the highest priority for effort. And we also used tools to surface insight into our daily priorities, highlight progress, our status, and any of the issues that were emerging.

So who's the gather content tool here? Thank you gather content is all I'd like to say. If you haven't used this tool I highly recommend it. The important thing on this screen to note is that the sort of status bar in the top area there, and what it shows is hundreds of pages in the different status. You've got pages pending review, where are they in the translation and migration process and everybody had access to this and it reflected all of the work that we needed to do and it was accurate every day so it's just an incredible tool for an agile content team.

Agile became an essential part of our process, so highly recommend it. So in this a key success factor in this agile approach to content is focusing on trust. It seems like a lot of effort to go through this level of communication and it may be -- I just want to write in my office and do my thing, it feels counterintuitive to take time away and communicate, but we all know the benefit of that level of communication, so once they work with it, once your team is engaged with it, I don't think they would want to work any other way.

And so the last area I want to talk about is preparing for the content future. Our approach to content over time has changed from pages on desktop, and pages on desktop and mobile and then to responsive content, content components and really breaking it down in really great ways to adapt to the great device landscape that we have to deal with. I think we've done a pretty good job in meeting the needs or the challenges of today. But are what the next things on the horizon that we need to think about? I wanted to put out a few things for you to consider.

I think the most important thing is we can take this agile process further. Stepping away and going, whoa, we did that, and really starting to think in the process of releases and continuous releases and continuous evolution, these are best practices for content. Build, measure, learn, works really really well for features and for products, and it works really well for content, as well.

Content teams should be at the table with developers and designers in the business, and really collaborating and gaining insight from testing and learning through things like A/B testing, analytics, listening labs and be part of what the release planning cycle looks like. Together with more traditional sort of content management and content scheduling, content life cycle reviews, I think all of these pieces can really elevate the role of the content team in the ongoing governance and ownership of your solutions.

And so content is getting much much more complex, right? Content that's based on sort of time of day, where you're located, your geography, your IP, the various -- user behavior, like when I've been on a site, what have I done, the language that you speak, and maybe even your affinity with a different like an entire customer segment. So these are all adding new dimensions to the content that we create and match.

So a couple of examples I wanted to share. Imagine a restaurant that sort of is prioritizing the content on their website based on the time of day. You know, it's not an altogether crazy thought. You know, lunchtime I'll present a lunch menu and information about the lunch content and then at dinnertime we'll switch it off. A site that maybe displays content differently the first time that you go to it and the third team speaks to you like a friend. A site that knows that you're in Vancouver and so all of the content and the imagery is regional and so even though it's a national campaign, or a national site, it feels local. So all or some of these states can really affect all or some of the content components on a page. And so these many to many relationships have a multiplier effect for your content team. With all of this complexity, comes a need to increase actual content volume, content complexity and then you're going to need to manage it and it's probably going to mean some more spreadsheets but some consciousness about what that's going to look like.

I came across this the other day about a data scientists and a researcher and her perspective is these changes in content allow us to create a delightful experience. So how do we actually identify what the opportunities are for this multidimensional content? And for your website, your internet, your app, whatever it might be. And I think we can really borrow from the tools and techniques of service design, because they're looking at how content can be different across many touch points and over time and so the content elements within those are what we can identify and so it also helped us to remind us and our content team that content is really is a journey and it reinforces that content is not a page.

The key take away for this area is I think it can be overwhelming to think about this sort of explosion of complexity shifting to new models of continuous evolution and doing it all at once. So like any change, I think, it's helpful to start small, and explore these new models in sort of contained experimentation, build your capacity for your team, build your confidence, share your stories, share with your stakeholders, and develop these small wins and over time, you'll find that the team is managing, scaling to the complexity, and you'll be able to share and push your own boundaries.

So my goal today was really just to share some practical advice, to help you and your content team offset that panic and you know, efficiently, calmly be able to create the content that you have to create in the face of these crazy parameters. I hope that you'll be able to pull some ideas from these things that I talked about today and that you can apply them across your own chasm.

[applause]