Greg Dunlap
A common pattern in modern web projects is the archipelago—a single organization whose “website” is really a loosely connected cluster of sites on a common platform. Each archipelago’s history is different, but their problems are the same: How do you implement modern content standards across these separate-but-same organizations? How do you bring coherence while accounting for the different needs that produced the islands in the first place?
This session offers tools for diagnosing common “archipelago problems,” and lessons learned from projects in government, education, and enterprise.
In this session, you’ll learn:
- How to use research to prioritize initiatives and find the sweet spots where stakeholder needs intersect
- A variety of editorial paradigms that make doing things right the easiest way rather than the hardest
- Ways to present metrics that motivate staff to write better and simpler content
What follows are the presenter notes from this talk, separated by a divider for each slide (including blank slides)
--------------------------
--------------------------
We design and build large-scale publishing primarily using Drupal. At Lullabot we manage a lot of re-platformings between CMSes or between versions of the same CMS, and the strategy team does a lot of work that would probably fall in the classification of “technical content strategy”. Building detailed content models, making sure it is represented within designs (and vice versa), translating it to authoring interfaces, that kind of thing.
--------------------------
Last year at Confab, my colleague Jeff Eaton and I received the news that we had landed the largest content strategy gig we had ever done, managing a re-platforming for the state of Georgia and the majority of their state agencies. Filled with the kind of confidence and joy that only a state of ignorance can bring, we traveled to Atlanta for our first meeting with the stakeholders.
--------------------------
They described a network of state agency websites that all ran on a common platform, which was currently around seven years old and feeling its age. Unfocused content, everything but the kitchen sink in the body field, the works. This was going to be redesigned from the ground up for a responsive, accessible, api-centric future.
--------------------------
The problem was that our stakeholders at digital services for the state did not manage these websites at all. They were all independently owned an operated by the agency staff, whose dedication to the web or content skills were all over the place. Some had multiple full time content editors overseen by a manager, some had a person who spent five hours a week on the site in between all their other work. They all had their own individual methods of governance within the common governance model of the state as a whole. The one commonality is that the state digital services team had zero ability to MAKE them do anything.
--------------------------
Even worse, there was not even any mandate that these agencies use this platform at all. Our stakeholders at state digital services were highly invested in this happening because it meant a responsive, accessible experience for all users of state services. However if the agencies didn’t get what they wanted out of it, they could just bail and launch their own thing anytime they wanted. This whole situation was best summed up by one of our stakeholders…
--------------------------
“All we have is carrots.
We don’t have any sticks”
– State of Georgia stakeholder
--------------------------
My colleague Jeff Eaton has been calling these “archipelago projects” - loosely coupled networks of sites that act as subsidiaries under an umbrella organization of some sort. These projects are interesting and really complicated, in part because there are so many more players involved, which makes the political dynamics are incredibly challenging.
--------------------------
In many normal product sites, you have two main classes of stakeholders - the organization and the users. However one of the central tenants of archipelago projects is that you have three - an umbrella org, its subsidaries, and the end users they both serve. That causes a lot of added tension. This is made worse by the fact that, in many cases, the subsidiaries actually hold a lot more sway over the umbrella org, which can lead to an inversion of incentives. The umbrella org is, day to day, responding to the subsidiary needs wayyyyyy more than the end users, which can cause them to lose focus on who their real audience is. Additionally, in most cases, some of those subsidiaries will hold way more political currency than others, adding another wrinkle into an already complicated mix. We’ve never had a university come to us with an RFP that says “We need to primarily design this site for tenured staff and the departments that bring in the most money from alumni” but that is certainly what we hear during site builds. Success in these projects often depends on meeting the needs of these internal users before you can even get to the business of serving the users actually visiting the sites.
Once we identified this model we started seeing it everywhere.
--------------------------
State Government
--------------------------
Higher Ed
--------------------------
Media
--------------------------
Sports Leagues
These are all examples of clients we have had with very similar conflicts despite the fact that their problem spaces were all very different.
Now, within this class of archipelago projects, you will typically see one of three governance models.
--------------------------
In a centralized model, the umbrella organization is strong and the subsidiaries are weak. The umbrella org holds sway on the technical platform *and* its implementation across all the subsidiary organizations. Everything from content model, branding, design, style guide … all of it flows from the top down. Typically in a centralized model, most of the staffing in terms of development, design, and strategy also lives in the umbrella organization. There will be subject matter experts acting as editors and content authors at the subsidiaries, but their content will often be subject to further review by editorial staff at the central organization to ensure consistency and adherence to standards. They can’t actually make those judgment calls or design changes themselves. An example of this kind of organization is the state of Massachusetts and mass.gov.
--------------------------
A de-centralized model is the opposite, typified by a very weak umbrella organization and very strong subsidiaries. Everyone owns their own properties, and there is no centralized authority whatsoever. The subsidiary organizations will have their own staffs, their own rules around content authoring, and even their own branding and design systems in some cases. An example of a de-centralized model is Harvard University, where the departments all run Drupal and share a small amount of common code, but otherwise harvard.edu is around 100 pages and everything else is a 100% autonomous separate site run by their own departments, all with their own look and feel, branding, and messaging.
--------------------------
Most common though, is a mixed model in which the umbrella org maintains some level of control and the subsidiaries maintain some level of independence. The most common way this manifests itself is with the umbrella organization owning the technology platform, and the subsidiaries wholly owning the content. In some cases the subsidiaries even have complete control of their branding and design system. NBC/Universal uses a model like this. The conglomerate owns the technology platform, and the networks use it with a lot of independence in how it is implemented. However it is more common that the subsidiaries have to conform to some level of consistency with the umbrella organization’s branding. This was the situation with the state of Georgia. The subsidiaries would have some freedom to adjust their site’s look and feel, but things like typefaces, colors, and the like would be set in stone by the platform.
On the face of it this model makes a lot of sense, because each player is owning the piece of the pie that falls within their area of expertise. The problem occurs, of course, when the umbrella organization want to have some kind of a coherent content strategy and consistency across all these sites without any ability to actually make it happen. This was especially touchy on Georgia, since the subsidiaries didn’t even *have* to use the platform, and could take their toys and go do their own thing if they wanted. And those agencies leaving the platform is a really big deal, because the platform is built from the ground up to be accessible and responsive, allowing it to more easily reach the state’s most vulnerable populations. Everyone involved considered these issues to be, at their core, a matter of social justice. We had an interview with an end user at one point, and when we asked what happened if she couldn’t access state services, she responded “Then I guess I don’t eat”. We wanted to entice as many agencies into the platform as possible, not give them excuses to leave. As we began thinking about the solutions we usually put together, we realized that this was going to be a real challenge.
--------------------------
--------------------------
In order to achieve success on these projects, you need to focus on the people in the middle and find that magical intersection where all their needs combined into one solution. At the same time, you can’t exclude the specific needs of any of the individual players. Then once you (hopefully) found that common ground, you needed to figure out how to turn that into actual implementable ideas. Much has been written about the relationship between an organization and its users, but in order to solve *that* problem an umbrella org first needs to manage the users at its subsidiaries, and we’re going to be talking about that aspect a lot today, and it basically breaks down into four problems.
--------------------------
Our task is to find commonality among a group of organizations with individual use cases, allowing them to work within the same system without excluding their unique aspects
Many of these groups are totally isolated, both as individuals (without web teams to support them) or as groups (feeling as if their needs aren’t met by the umbrella)
This leaves them feeling disempowered, and causes them to strike out on their own to find solutions either within or outside the system
Often even when new solutions are rolled out, they are used for a while and then fall apart over time to due to a lack of followup
-----
Do The Research
Build Bridges
Verify Solutions
Measure + Iterate
-----
The first step is to dig into the problem and find those patterns and commonalities you can grab and use to push the project forward. There are two main angles to come at this from: user research (both internal and external) and content analysis.
-----
There’s been a bit of a revolution in user research in the last decade, but most of that has been focused on the external users of a website. Your customers, however your organization might define that term. In an archipelago project it can be very useful to bring those same tactics to bear on your internal users. I saw several people tweet a slide that Kristina showed at the Intro To Content Strategy session on Tuesday which detailed why you need user research. One of the main things she mentions is that user research helps you prioritize your target audience, because otherwise you just try and do everything for everybody. For your external users, that manifests as dumping every piece of information out there “just in case” with no sense of how it should be prioritized, or even worse, everyone fighting over how it should be prioritized. For site editors, it manifests as just giving everyone HTML access and hoping for the best.
We often see user personas used as a way to bring focus to solutions for the customers of websites, but when you’re dealing with an internal user base this broad, the same tactics can be brought to bear on them with great success. The state of Georgia created very detailed user personas for their agency users, dividing them into the six most common personalities and laying out a variety of information that defines them including their motivations, frustrations, common software, goals and a host of other info. They also defined 7 common “verticals” for their agencies - Elected Officials, Law Enforcement, “G2G”, etc. Having these personas and verticals was immensely useful because we were able to target the people we wanted to talk to and focus our solutions on. Just like with your customers, it allows you to take a very broad base of people and narrow it down to the groups you really need to focus on.
-----
These artifacts will come in really useful when it comes time to actually go out and talk to those users about their use cases and pain points. Using that research as a base, you can reach out to a set of users who match those personas within the specific verticals you’ve defined, ensuring that the full range of your subsidiary use cases are represented. In those internal stakeholder interviews, you will hear a lot of complaining and cataloguing of needs, but behind all that is the question you’re really interested in.
-----
What you’re really interested in is the why. What motivates their use cases? What are they actually trying to accomplish when they hit road blocks? This can expose things that aren’t immediately obvious. Here’s an example.
-----
It will be a shock to learn that on the Georgia project, a lot of people had design issues they wanted addressed. They couldn’t do this on the page, or they didn’t have access to do such and such, or they needed to be able to make this photo bigger and float it over here and etc. These complaints are fairly common, but in this situation they were amplified because most of these design needs contradicted each other. There was no consensus on anything between the agencies other than everyone wanting some variation of “Just give me HTML access”
-----
Having heard this over and over, we went back and started digging in with them to get at what was behind their needs. Why did they need this specific design control or that one? What was the driver or business goal behind it? I had initially assumed that this was going to be heavily driven by internal politics or directives for agency directors, which would be difficult to fight. However, when pressed about it, it turned out that they were mostly not trying to achieve any specific design goal or implement a specific request. They didn’t actually have a “need” to place this photo just so. They just wanted to “break up the wall of text”. They thought their pages were “boring” and looked “dated”. Then more we pressed and asked why they had these requests, the more we heard this specific complaint from people. Having identified this problem, we now have something we can really design a solution around and take back to them for acceptance testing.
-----
So many users say *what* they want, and far too many people take it at face value, simply going off and doing what is asked. I strongly believe that one of our primary purposes on the projects we work in is to always be asking why. I’m sure many of you have heard the adage that you need to ask why five times before you really get the answer to the real heart of a problem. This really is true, and constantly pressing for answers to WHY is one of the greatest techniques that you can bring to bear on a project. This is especially true very early on when the problems may not even be completely defined, but also on a day to day basis. I’m sure we all do this, but I’m also sure that there are times when we’re slammed or otherwise engaged and we fall into “just do what you’re told” mode. When you understand user’s *motivations* you can design for them, and if you can design for them you have a way better chance of keeping these users happy.
-----
The second angle to come at this from is the content. Traditionally this has meant an inventory and audit, however at this scale that process can become really difficult. Simply gathering all the content is a challenge in and of itself, then you have to sift through it to find the useful pieces as they apply to all three of the stakeholders in this conversation. To some extent a lot of this is more art than science and dependent on the project at hand, but I like to use to at least get started.
-----
As is fairly common practice on a large-scale web project, we used a spider to crawl the sites and generate an inventory of what lived at every URL. Your initial instinct will be to limit what your spider crawls, because at scale you can end up with an enormous amount of data that can be fairly difficult to manage. This is the wrong instinct. Instead you want to make sure it crawls absolutely everything. Large data sets can be filtered and sliced and diced, but you can’t filter what you don’t have. We ended up going back to the well several times because we had limited our crawl too much and ended up needing more information down the road. Do it once, get it all, then work from there. (Also just forget about trying to do it in Google Sheets. Just get Excel and accept that that is what you’re going to have to work with.)
-----
Next I usually like to take this big spreadsheet, sort it by different properties, and see what kind of content lives at the extremes. This can reveal all sorts of interesting outliers that can provide a lot of insight into the organizations you’re working with and the content they generate. For instance, we used a spider called Screaming Frog to generate our intial inventory and it reports the page size of the HTML for every URL it crawls. Seeing what lives at both the highs and lows of this measure can be really interesting. Some of it will be obvious. Huge tables increase bloat, big surprise. Sometimes you do get interesting stuff out of it though.
-----
This is the page with the largest size in the entire network of Georgia sites. It took us quite a while to figure out why. What happened is that someone had base-64 encoded the image and embedded it into the page’s HTML using the WYSIWYG. Now, while this makes a great story to tell at conferences, it also told us a few things, the main thing being that users at the agencies were very crafty and would go to great lengths to do what they want to. This is really important information to have as we start thinking about authoring tools and the like.
In addition to large page sizes, the smallest page sizes were also interesting because they showed that there was an enormous number of pages that were nothing but “Here is a document of some sort uploaded into the WYSIWYG, with no context or surrounding information.” We already knew document management was a problem for content editors at the agencies, but this highlighted it in a way that surfaced those issues to end users without any of the metadata or context that would make the information useful. Having seen this, we knew we had to prioritize the problem from both angles.
-----
Other interesting things to check the edges around:
GA visits (SF can pull this in automatically. What information is sitting there useless with nobody looking at it? Why?)
H1 / TITLE size (Can have SEO implications, indicative of poor editorial practices, difficult migrations)
Text:HTML ratio
Custom Properties (Stuff you define yourself like number of embeds/tables/etc)
A lot of this stuff won’t pan out. There won’t be anything of particular interest there and you’ll just move onto the next thing. That is actually *good*. You don’t want to have all of the extremes being a total nightmare. The important thing is recognizing the outliers when they appear and figuring out what they mean.
-----
Another thing to do with these large-scale inventories is aggregate AND divide. In an archipelago, some information will be important in aggregate, some will be more important based on the islands, and sometimes both will be important in different ways. You shouldn’t ignore the importance of either, and always be looking at the data through both lenses.
-----
As an example, one pattern we noticed immediately was that there were far more PDF and DOC files on the sites than there were HTML pages. That was interesting as a network-wide statistic, and indicated that like many government organizations, there was an enormous amount of information silo’d into these documents that was worth getting out.
-----
However when you looked at it on a per-agency basis, there was actually a lot of difference. This chart showed us which sites had the greatest ratio of PDF:HTML content, and then we could look at them and see what trends there were. One thing we noticed immediately was that there were a lot of sites that actually did pretty well, PDF abuse was pretty silo’d. And even in those there were some outliers. For instance, it makes sense that DOR is PDF-heavy. They are providing printable forms in a format that makes no sense any other way. But we also had sites with PDF weekly meeting minutes going back ten years. In these cases the PDFs are more representative of problems around governance (how long do we need to keep things? are these minutes actually important to begin with? do we legally have to put them up?) and best practices (what could we do to motivate users to make these web pages rather than uploading PDFs to begin with?)
-----
I’m going to warrant a guess that this crowd doesn’t need to be sold on the value of research. However large-scale archipelago projects require some different approaches and different focus. By taking the user research tactics you normally use for yours end users and applying them to your internal ones, you get a better picture of your stakeholders at the subsidiary groups, and by constantly focusing on the “why” of their needs, you can start to put together their commonalities in order to gain real insights into their problem space.
On the content side, creating an aggregated inventory that contains all the content from across the site, researching the outliers, and dividing it into slices as necessary will give you different viewpoints into the content these sites are producing from a variety of viewpoints and areas of focus.
These two angles of attack brought together can provide powerful insights, and allow you to identify systematic issues to attack which benefit everyone both across the organization and within their individual islands.
-----
I think a lot of people in this room all agree that breaking down silos in an organization is important in order to create solutions that work. In a large-scale decentralized archipelago, that is even more true than ever. These solutions are complicated and you really need all hands on deck in order to help create something that will be functional for everyone involved. I think the question we tend to struggle with more is how? So many organizations are so silo’d, it seems impossible to overcome. How do we make sure everyone’s domain knowledge gets brought to the table?
-----
The great thing is that by doing the research with internal users, you’ve already started. Each one of those subsidiary groups is their own silo, and by bringing them to the table to talk you’re helping to bridge those gaps. The same thing can be done for your silos of expertise. While your org’s workflow may encourage functional silos, there’s nothing stopping us as individuals from reaching out between them, and (ideally) most people doing a job love talking about it. Are you interested in what your CMS is capable of so that you can optimally design content for it? Reach out to a developer and get a walkthrough. Bring lots of questions. The reality is that they are probably just as frustrated with being silo’d as you are. Frame it around wanting to make their life easier. Nobody likes being faced with solutions that someone else created which don’t bring your own expertise and needs into play, and if you are presenting a solution to that, people will generally be responsive to it.
-----
As you’re reaching across your silos, you will start to identify people who are just as interested in making solutions that work as you are. Grab these people and hold onto them for dear life, because they are the ones who can be your eyes, ears, and voice within their silos. Sometimes their motivations may not match up with yours precisely, but that’s OK. At Georgia there was an agency who was very reluctant to give up control of their website to join the common platform but they were eventually convinced. Shortly afterwards, the entire organization was sued over ADA compliance, and their website was one of the areas that passed 100% because of the work that had been done to make their platform compliant. Coming out of that, state digital services identified that this agency as a potential champion for other agencies that hadn’t come on board. Their motivation of accessibility as a human right didn’t necessarily align with theirs of simply not wanting to be sued, but finding champions who are willing to help you work towards common goals within their silos is enormously important.
At the same time, you need to be the voice for them within your groups. Breaking down silos goes both ways, and as this group of champions (I hesitate to call them Avengers but …) starts to bring everyone’s voice throughout the organization, over time the walls will crumble.
-----
Now that you have champions throughout your organization, you can collaborate with them on solutions to problems you couldn’t have solved yourself. A fairly standard thing for all of us coming into a new project, especially one historically plagued by unstructured content, is to come in and design a content model that fits their needs and structures their content as appropriate. In an archipelago project like this, you need to design a broad solution for multiple organizations that all have specific interests, and that makes creating a structured content model difficult. We did identify some common use cases like Organizations, Locations, and Public Records. However we also knew that a lot of the content was still going to end up in basic WYSIWYG page building content. What we ended up doing was reaching out to the dev team to see what kind of solutions we could come up with on the authoring side. If we were going to have a lot of unstructured content, we wanted to at least make it so that doing things the right way was easiest, and the wrong way was hardest (as opposed to the current system where it was the opposite.) In conjunction with the dev and front end teams, we came up with a set of guardrails for the WYSIWYG editor that included restricted photo placement and dimensions, the ability to embed micro content within the text with a variety of options, and advanced document management which made it much easier to use and list documents in a sane way.
-----
Breaking down silos is not easy or quick. Working against organizational inertia is always slow and hard. However the benefits you get out of it are immense. It enables everyone to craft much better solutions for your users, and to move your organization forward into a much more functional place.
-----
As you’re building out these networks of sites, you’re going to want to reach out to the internal users who will be using them, in order to verify that the solutions you’re coming up with make sense and work well for them, and there are kind of three angles you want to make sure that you hit as you’re going through these rounds of review.
-----
We’ve already touched on this quite a bit in other ways, but you want to verify any solutions you create with a broad cross-section of your users. You’ve likely already identified people you want to run through solutions with via your user research, but we usually like to expand from there when we’re putting forth solutions as well. Multiple attitudes: In addition to your champions and supporters, talk to your diehard critics, the ones you can never please. Multiple roles: Make sure that you’re bringing in some people who are actually doing the work of entering content, and not just their bosses or directors. Cut as broad a swath as you can, and you’ll have a higher likelihood of success. Additionally, the more people you talk to, the better chance you have of identifying future champions who can help you down the road as your project gets rolled out.
-----
Presenting users with information in multiple forms will trigger different response to them depending on what they’re looking at. A list of content types is read differently than an edit screen is read differently than how the page will render for the end user. For every different form you present, you’ll get more information that you can use to make better decisions. For instance, here are two of the ways we presented content types to users during different phases of the project. The one on the left shows an early draft of the types and their relationships, whereas the one on the right shows the screen editors would interact with when going to create content. These two presentations and the questions that went along with them garnered a lot of different insights on what is basically the same issue - Do these content types make sense, and can users figure out which ones are best to use in which use cases? As an example, in an attempt to break away from “News” as a content type which seemed a little too prescriptive in its use case, we had attempted to rename it to “Update”, referring to an update of any kind, which seemed a little more appropriate. In the first presentation, users seemed OK with this naming. However on the editorial screen, we immediately saw a pattern of users confused by the naming. They kept asking “What is it we are updating?” - in the context of an editorial interface, where they were actually making actions and doing things. they were interpreting the word as a verb instead of as a noun. We decided to change it back to new midstream and everyone suddenly “got it” again. I still don’t like “News” but getting the users to use the right type in the right scenarios was an important goal in our project, and spotting that problem was a really big win for something seemingly so simple. (Also, man, naming things i hard.)
-----
Finally you want to be coming through with things more than once to constantly be refining your solutions. Changes need to be re-verified as they go through, and while some of these modifications will be appear to be small and minor, they can actually have really major impact. The more times you can get things in front of users, the better your solutions will end up being in the end.
-----
Finally there is one other HUGE benefit to all of this. As you talk to your stakeholders over and over in a variety of different ways, what you are also hopefully doing is building trust. You trust them enough to come and talk to them about what they need and make sure you’re getting it right. In turn this (hopefully) pays off with greater buy-in and acceptance as your project rolls out, easier training as many of the large-scale stakeholders will already have some familiarity with what you’re doing, and if you’re lucky you’ll get a champion or two out of it as well which can be an amazing boon to the projects that follow.
-----
I think we all know that measuring results is important to the success of a large scale project. It helps you determine what is and isn’t working, and it helps you prioritize what you will work on next. However on a large scale archipelago project, you need to really stretch your definition of what it means to measure results, and if you’ve been paying attention so far it won’t surprise you to hear that this means adding some measurement of what your internal users are doing in addition to what pages your external users are hitting.
-----
As a content strategist, one of the goals of any major project, your entire job really, is to improve the content being delivered to end users so that it meets their needs and achieves the goals of our organizations. You can then use analytics tools to measure that usage, and help determine if your sites are working and iterate as necessary. Identifying which metrics are appropriate to your goals is one of the keys to ongoing success. However in these decentralized archipelagos, you have some different problems to deal with, the biggest one being that you have a lot less control to affect the content quality than you normally would. In some cases you may not even have enough leverage to force the subsidiaries to follow a style guide, or use a specific voice. One way to help alleviate that is to start expanding the scope of what it means to measure content success from beyond how your end users are browsing and reading it. As part of the content inventory for Georgia, we had run everything through a content analysis tool which returned some qualitative measurements for content that helps you identify which content is meeting your guidelines and which isn’t. This included reading time, grade level, and sentiment analysis among other things.
Lets also not forget non-digital metrics as well. How many calls are coming in to your call center? What are the most common topics and questions? Many large-scale networks like this have a wide variety of information coming in from non-digital sources. Find it and bring it to the table. Among all this though, the most important thing to keep in mind is that you should identify the information you need to collect in order to verify whether or not you are meeting the goals you have set for your content and your organization. I think it was Jared Spool who said that he always asks clients if they would trade a 10% drop in page views for a 10% increase in leads. You would be stupid not to right? So why is everyone so obsessed with page views? Yes it is an important metric, but you need to make sure you’re collecting information that actually ties back to your goals.
-----
Now that you have this qualitative data, you can bring it to play alongside your web analytics to verify assumptions. You can combine these things in really interesting ways that can often help to verify goals much better than basic analytics would allow. For instance, what is the relationship between time on page and time to read? If something has a 2 minute read time and a 20 second time on page, that could indicate a problem. What is the relationship between readability and page views? Are users spending less time on content that is written to a higher page level? Do agencies whose content averages a higher grade level get more calls to their call centers? Solving these problems may very well require busting some silos and working towards developing some champions, but the dividends they will pay off for you and your users will be massive.
-----
As you expand your view of what analytics are and how you’re going to bring them together, these new priorities need to be socialized throughout the rest of the organization. One way this can be done is in the audit process. Break out each site’s content from the inventory, and sit down with them to talk about it. As you meet with these subsidiary organizations, you can bring this data to the table and discuss how it can be brought to bear on decisions abut what content to keep, kill, or combine, getting them used to these metrics and understanding the role they play. Another way we socialized these important metrics on Georgia is by adding it to the content authoring process. Working with our dev and UX teams we designed a way for authors to see their reading time and grade level as they entered content, highlighting the importance of this data and keeping it top of mind. A lot of these subsidiary teams, especially the ones struggling with budget and staffing issues, lack the data and context to really understand how these metrics come into play, and socializing it throughout those organizations helps to reframe their thinking about content and how it is being measured and evaluated.
-----
Having collected the data we want and decided how we want to use it, the most powerful thing we can do is aggregate it into dashboards which can be sorted and examined as a set. Not only can this be done on per-site dashboards (which make a powerful tool for prioritizing content improvements) but those sets can themselves be aggregated into one network-wide dashboard, allowing the organization to see data network-wide. And not just the data itself, but trends. Where are improvements happening? Where are things backsliding? Which sites have the most accessibility issues? Being able to once again divide *and* aggregate this qualitative *and* quantitative information enables enormous insights and gives you the tools you need to create action plans and figure out which subsidiaries need the most attention and help.
-----
This is where, finally, we start to have a stick, because having aggregated all this data and brought it to bear against analytics, we can start to have real data about what the impact is of bad content, and we can start to surface that to leadership in a way that they will (hopefully) find difficult to ignore. This aggregated data points a bright light at where the subsidiaries are succeeding and failing at their missions, going beyond simple page views to measure how they are meeting their goals both within and without the website. If your umbrella organization can provide a solution to many of these problems, and surface the problems up the chain to people who really can exert some pressure, then those arguments start to become really compelling, especially if you have a champion or two on board to help you make them.
-----
So if we look back at where we started, we can see how we brought all these techniques to bear on the problem at hand.
-----
-----
One last thing. In most projects your goal is not to change the world. Scott Kubie has been pointing out in his recent talks that people come out of conference like this filled with these massive dreams and ready to change the world, and lets face it, it rarely ends up that way. The vast majority of the problems you encounter on these projects are organizational and political, and those things are almost always out of scope and can take decades to change. All we can do is hold on tight to the serenity prayer and move the needle forward wherever possible, even if its just a couple of inches here and there. Next thing you know you’ve moved a foot, then a yard, then a mile. Do what you can, figure out how to solve problems in a way that meets everyone’s needs, and don’t give up.
-----
-----
Mar 17, 2019
Feb 12, 2019
Feb 23, 2019
Oct 7, 2018
Nov 13, 2018
Jul 20, 2018
Jun 14, 2018
Jun 19, 2018
Jun 18, 2018
Jun 7, 2018
Jun 8, 2018
Jun 6, 2018