Our Work

 

Content Strategy: It's Everybody's Job

By Gwen Daniels on January 06, 2016

Next week, I am co-presenting a session on "Next Generation Content Strategy for Statewide Websites" at the 2016 LSC Technology Initiative Grant conference. More than once our Executive Director has asked, "Why are you (ILAO's Technical Director) doing that panel and not our Content Director?" It's a fair question. Content strategy is one of those terms that changes meaning depending on who you ask. I'm partial to Kevin Nichols' definition: "Getting the right content to the right user at the right time." It includes not only what content we create and how we produce it, but also the experience and delivery mechanisms. In other words, content strategy requires more than just expertise in "the right content" but also expertise in UX and technology.

There are a number of components in our content strategy that have little or no impact on technical development. Whether our editorial guidelines require title case or sentence case for content titles or whether we have content on topics like the legality of fireworks or not, or how often the content is changed doesn't really matter to the development workstream.

But there are a number of instances where content, tech and UX intersect. In some cases, it has taken us a while to understand that intersection and develop solutions that better integrate all 3 components and allow us to move forward more industriously than if we'd only looked at one side of the puzzle. Some of these issues include:

  • How is our legal content structured? We have struggled trying to figure out how best to transform our content in ways that reduces duplication but still deliver a complete picture to the end user. We've swung from an initial idea of "everything has to stand alone, answer a single question, and can't duplicate anything else" back to "we still want to bundle that in some way for the user." After Dina and I having our own conversations about how the content should be delivered on the website and the content team working through a number of issues, we all finally got together in a room for a couple of half-day meetings. The result? On the content side, we are still writing primarily standalone articles, but we're adding into the CMS the ability to create a "bundle" made up of these artices, organized with a menu, and with the ability to re-use the articles across bundles. For example, nearly every bundle talks about fee waivers for court. We can have 1 fee waiver article and embed it in each of our bundles. This reduces the number of articles the content team has to manage, while also enhancing the overall content experience for our end users by using bundles.
  • Can we improve how content editors edit content? I've been to at least 2 sessions at separate Drupal camps that have made the same point: don't forget that the most frequent user of the new website is your content managers and editors. The user experience for them is just as important as it is for our end users. One of the chief things that came out of our 2013 BPA process for me was that our content team had been hacking their own non-technical solutions to get around the technical issues of our current platform. Once those issues were identified, we could fix them in the new system. In one of our earliest sprints, Dennis and I sat down to map out the "dream translation workflow" and identify all the problems in the current process. This process helped ensure that what we're building works for our Content Managers.
  • Can we provide tools to enforce editorial policy? One of the stories this sprint involved the content and UX teams working out how to document what will become a style guide. This is a key piece of documentation to ensure that as staff and external editors change and as we open the system up, we maintain consistent standards. How do we take that documentation and ensure it is easily accessible to editors on demand? What role does it play in help text on form elements? What can we do on the technical side to enforce the policy? For example, if the policy limits titles to 60 characters, shouldn't our forms validate that?
  • How do we determine who the right users and the right time are? This is one that probably impacts how we produce content least but has major implications for what we produce and how we deliver it. It requires us to be thoughtful in how we set up data collection. Is "out of the box" Google Analytics enough? Do we need to be tracking more? How do we tag content by location and do we ask users where they are or rely on geolocation tools or both? What types of reports do we need to generate so that our Content Team can better set its overall priorities? What does having all this user data mean for how we deliver content? This is one area where there are still many unknowns an it is one in which I suspect we will continue to focus even after launch.
  • How do users get to our content? This has been a huge question mark for us. Do we list individual articles in navigation or as part of a bundle? Do we list articles in search? Do we want articles to be sequenced? We recently completed the legal taxonomy that will drive both our navigation menus and our triage systems. It is a critical part of both our overall information architecture and of our content strategy. And it required expertise from all of us to create. On the UX side: Can users bucket their legal problem within our taxonomy? Do they know that an Order of Protection will fall under Family & Safety or that having their utilities cut off would fall under House & Apartment? Is there consistency in language, style, and tone? On the content side: Are the categories comprehensive? Are they appropriately segmented? Are topics that should be listed in multiple categories marked as such? And on the technical side: Is the taxonomy structured in a way that we can implement? Is it expandable and translatable? Does it have an exit path for each user (for example is their an Other option)? Does it work for all the use cases we've defined? Have we defined how it will be implemented?

At the end of the day, we need all three components working together to create a truly fantastic product. The content will always be the heart of the website--it is why users come to the site. It gives them what they need. And tech and UX have significant supporting roles in ensuring that that content is created and delivered in the best possible ways on a platform that is robust and provides for easy content management. One of the biggest benefits of our Scrum process has been the increased communication between the three separate "teams" of the program team. Especially over the last few months, we've become more aware of when content, tech, and UX need to come together to more quickly resolve an issue and I hope that in 2016 this trend will continue; that UX will be something we all think about in our work; that content asks "is there a technical way to solve a problem?" more often and that tech & UX are always thinking "how can we make the content experience better?" We've got a great team at ILAO, with a lot of different perspectives and expertise that has allowed us to do something I think is going to be pretty damn special.

[image attribution: http://www.hubspot.com/inbound-marketing] 

Comments

(0)