 So this session is about communication during redesign. You don't need to follow the other sessions. So I'm Mike Kirby. I work at University of Maine. I've been working on websites since before there were websites. My first website was a big yes in the 1980s that people were dialogue into and actually read text and not look at papers. And then through some redesigns it went well and others that did not. And the common theme with the ones that went well is good communication. And the ones that did not, they were trying to work in a vacuum. So a little bit about University of Maine's website. We are a multi-site. We have two multi-site environments that are public at the moment. We're looking at spinning up a third one. The primary one that we work on is umane.edu. There's about 350 public websites in it. 425 actual websites, some of them are in progress. Decentralized content management. We support a team of 900 or so different users of one sort or another that are in there with other websites. But we centralize the application management. So we don't let anybody install their own plugins. And we now just have the one theme that people use. Public extension, which is our statewide outreach to the community. That is on another multi-site network that has about 40 to 60 websites. And it's separate for a variety of needs, but here's the code base. So I'm not going to go too much forward into this. Our digital communications team, we're a team of three. Brandi's in the room here. All three of us are down here at WordCAP today. And we support a campus of 12,000 with focusing on training and communications as opposed to actually doing the content work for folks. So the detail is not to go over the project itself, but to talk about the communications. So this is just a quick timeline of the redesign. We started in the summer fall of 2014 with pre-planning. Winter-Spring was the communications piece. And then summer to fall in 2015, we launched. And then there was some post-launch communication. And of course that was several years ago. So I've updated a little bit for this talk. As an opportunity to migrate to a modernized WordPress implementation, we eliminated legacy plugins and audited every website for web accessibility at the time it was migrated. This process was just completed for the main websites last spring. Our follow-up to extension websites continued to be migrated. That project's managed by their communications team, our support. And some migrating sites were using specialized WordPress themes. Our goal was to get everybody into a single theme, not even have child themes offer that. And that was achieved. At times we added options to the theme's customizer so that we were only available to super-admin. So we can tweak the site a little bit for sites like University of Maine, using the art, over the library, et cetera. But individual users don't have access to that kind of high-level changing of the theme. Positive word of mouth about how this went has gotten a lot of outlined sites into our theme. So we had the Climate Change Institute, the Marine Sciences School, other sites that were large that were outside of WordPress altogether. They had their own content management systems. And they didn't want to come into WordPress before we started this project because they saw it as restrictive and not up to stuff for what they wanted. They came on board because they saw how well the project went and built a great thing for it. So, pre-project communication. This is where you really have to start is taking stock. Get to know the land of the land. It's important to reach out to your stakeholders, obviously, but that's hard to do because you want to even get a earful from them when they, especially if you have a site that you aren't grousing about, determine what the pain points are. That's important. That's what you're doing to reach out before us to address these pain points. But it's also important to look at what's working well because you don't want to just throw something out that you didn't think people were using and they were using. Our big example was the A to Z directory that we had on a website. I thought, oh, this is silly. If the site's well-designed and has good search, who needs to go to A to Z directory? But no, that was consistently the top thing people said they liked about our website and to go to a directory and not just rely on search to tell them where the student records department website was. At UMain, we have some of the web advisory group. We brought in to the table constituents from administration, IT, resources, education. It's challenging sometimes because some of these groups are going to be very busy and they don't have time to give you time. So it's good to find proxies for those faculty. We didn't really have faculty at the table for the redesign. Instead, we found people that had the same mix of needs that did have time. So people that were in professional development groups at UMain came in and they filled the same needs but they were able to make time for these meetings. This group that we have continues to meet six times a year. As I said, a lot of special pain points help us understand what should be addressed. It's equally important to understand what's working well. Sending scope, that's the key with this. Let people know what they're going to be expected to try to get on and also let them know what you're doing. Because when you say a redesign, people insert their own opinion as to what that means. And then when you don't meet that, then to them you fail. You never intended to address that. So begin with your end in mind. Stick to the scope you set and make sure the project is clearly communicated as the project is finished, approved, and kicked off. You don't want to pitch a redesign project and people will say, yeah, we'll pay for that. And then they say, what do you mean search wasn't included? Or what do you mean e-commerce? We don't have e-commerce with us. So make sure that at UMain, we made it very clear we are not changing from WordPress. WordPress was working for us. We just needed to take it to the next level. We made it clear that we weren't going to adopt a new search engine. We were using Google Custom Search Engine. That would stay the same. If we decided later that we needed a better search engine, we would do that as a separate project. E-commerce, we weren't going to spin up world e-commerce into our theme all of a sudden, because that would be a little bit too much for this project. We're now working on coming to orders.umain.edu, a multi-site environment that's going to be a separate project that will help for workshop registrations or minor e-commerce forwarding campaigns. Most importantly, yeah, we determined that we shouldn't try to launch everything at once. With UMain, we had a large multi-site environment. We decided it was an opportunity to migrate to a better WordPress stack altogether. So we identified a set of key sites that would help us shake out any shortcomings in our solution. And we followed up with a course launch project to migrate the hundreds of sites into the new theme. So we had a set of about 20 or so sites. So our core news, calendar, home page, admissions, those types of sites, we brought them over all of once and then reached out to the community and started a migration project. That might not be possible with every redesign. If you're a small shop, then do the whole thing at once. But if you're in a large, if it's daunting to even think about launching your whole site into a new design at once, see if there's an opportunity to do that a pace at a time. So during the project, this is where you loop back in those people that helped you discover what you needed to do and make sure that you're hitting what they needed. You're designing with your audience in mind. Ensure that you're addressing their pain points. For UMain, decisions were on the design remain within our broader department, marketing communications. And we had to run it on the flagpole stuff, the senior leadership. We were actually at a great point there where senior leadership really wasn't interested in micromanaging the website. So we didn't have to show them. Here's the three different directions. We're going to go pick one. We chose that. And then it was later that we said, this is the one we chose. And then they said, yeah, that looks good. Also, the web advisory group that we set up, we made it clear that we weren't going to be expecting them to chime in on every little decision about the project. We just were going to give them status updates. And that status update was an opportunity for them to say, you know, I have concerns that I don't see being met. But you get into analysis paralysis if you make people think that they have to chime in. At a previous job, I had a co-worker who shared that whenever she's given something to review, like a document, she always finds something to change to show that she looked at it. And if you have somebody like that, then you're going to just be getting somebody that's going to focus on this one little thing that they may not even care about, but they wanted to show that they were paying attention and looking at what you guys were looking at. So yeah, our web advisory group is going to be regularly for progress reports updates on the emerging look of the site, but on the occasion, occasionally, where they asked to go in on a site basis. The communication plan for the general internal audience outside of our core folks. That's, you know, when your developers are working on actually building the new theme, usually your communicators are not having to do as much about deciding what to do. So this is your opportunity to take this thought and tell everybody what the developers are doing and share the excitement that the new site is coming. This is a great time. Yeah, map out the key dates in this plan and ensure you have adequate time to prepare and present so the community has time to digest and accept the coming changes. Really, with our project, we kicked it off in earnest in February of 2015 and it was by June of 2015 that we had all the design choices made pretty much, so July was when we really started that push out to tell people this is what's coming. And by then you had screenshots, hopefully, of what it was going to look like. So yeah, map out your key dates and then plan an informational session, something like this, where take all commerce to come and sit and listen to you talk. That's, you know, we did that in mid-July. We sent out invitations to the campus community. It was a great time during the summer. Students aren't here. Faculty actually have some doubt. They'll argue that they never have downtime. But at least they weren't having to convene classes usually. So that informational session, that's, you know, start with why. People are going to wonder, why are you doing this? So tell them this is why we have to redesign. For us, it was very clear. We had to redesign it because mobile. We had a website that started organically in 2009 in WordPress. And by 2015, it was just, we couldn't just shoehorn mobile into the game so we wanted to start fresh. Share screenshots. Don't try to do a live demo of the site if you can at all help it. Not just because Murphy's Law, if you do a demo of a product, that's when the errors are going to pop up and it's going to look like they're always there, even if they weren't. So just use screenshots. But even more important, if you're using screenshots, folks are going to look at the screen and they'll realize that they can't click to go in deeper and they'll just say, okay, I'll look at it later when I can click and go deeper. If they see you can click and go deeper, they'll say, I want to see what that is. And then all of a sudden, you're a whole talk of derail as everybody starts to wonder why is this page doing this instead of that? It's like, well, that's because we had to flush that out there because this is just a demo. Yeah, give them a handout to take away. That's very important. It helps structure what you're going to say. And then it gives them something to take back with them so that they're not relying on their own interpretation of what you said. If you just give a talk and somebody takes notes, they'll write down something and then they'll get back to, and they'll be asked, what wouldn't they talk about? And they'll see what they wrote as a note and they'll suddenly expand on that. And when they expand on what they wrote notes on, they might not be accurate at all in what you meant. But if they have a take, a handout, they can put a copy of the handout or even better point you to, point their co-workers to a website to get their own copy of the handout and you have control of that message. At least they're going to say, see the handout, that's what we said we were doing. Also, you want to make sure that you give them kind of a nice structure to that handout. Tell them what's changing, tell them what's staying the same, tell them when it's happening and then end with what they need to do because that's probably why they were there in the first place. So communication during the project, post-communication plan once you're launched. As the launch approaches, you want to alert your audience. Update your home page, home pages of science effective, because we have these full sites that we're watching and we want to make sure that people that were entering the site for those sub-sites were aware that something was going to be changing soon. To communicate that the coming change is going to be there for your frequent visitors. If your whole site's flipping at once, then you probably want to look at Google Analytics and identify your entry points to the website, the most common ones. If you're anything like a campus like this, I know some of the people at WordCamp came in through the door that was open that had the vendors and all that, and somebody came through another door and had to wander through and find their way over here. Well, your website's the same way. Not everybody's going to come through the home page. They're going to come through the page that they got to their Google. Google Analytics will tell you what those pages are, so you can put alerts on them so that even if they didn't come to your home page, they're still aware that the change is coming. It's a lunch day. That's clear your calendar if you have a wonderful website, but you're not the developer guy because you're going to be hearing from others. You announce the launch to your campus community. Do not assume they're going to open the home page and notice the update on their own. We actually had somebody a year and a half after we launched, and we were doing this migration. And I contacted them and said, hey, would you like to get your site migrating to the new design? I said, who's the new design? And we assume that everybody always goes to the home page, but there's lots of constituents that only open their page. Involve your campus news team if you have one. This talk was originally for the university, but any company that has public relations, press releases, or whatever, involve those folks. They're your communicators. They'll have a good hand on getting the word out. Keep them up to date with the site's migrating from what we think to new. For us, we made announcements on campus news as each site was getting launched to kind of help show these sites were changing. To a degree, after the first year of migrating sites, we'd gotten all the big ones and we stopped doing that because it seemed a little silly to say, hey, the Black Bear Marathon website has now changed into a new thing. And expected, expected. And we launched the site went up, new site, and immediately crashed because we had tested the new stack, but we hadn't tested the new stack totally with the live traffic. And we set up the old site again while we did some fine tuning of microcaching and all sorts of technical things that I had nothing about. And we got it back up. So that was the other thing, making sure that your communicators are out there. And now the press release, the moment you set out the new site, that might not be the best idea. Wait till you've got it up. It's been up for a few hours. It looks stable. Then you can get the word out. You can watch the new site. But if it went up, came down, and then goes up later in the day, later in the day is the time you want to send that word out. So post-watch, support and training. Which project results in the redesigned site will all swoop. Post-launch communications are going to be focused on support and for the training support. It's not a web publication that's pushed out the door on a deadline and you work out other initiatives. It's a communication channel that must be constantly fed and managed. Visible ongoing training and updates on the success of the website will reinforce this perception among those who are not as focused on the web as you are and your media team. So site migrations, that's what for us, if you didn't go all at once, this is not pertaining to you, but you'll be launching new sites perhaps in your multi-site environment. So if you did not flip the entire website's private screen design, you'll have more sites to migrate to. Managing the migration process involves communication pieces. Develop templates for emails we'll be sending out as part of the process. So we'll be sending out as part of the process. So migration kickoff, proposed timeline, status updates, check-ins, approvals. Develop a training website to showcase the new features and things so that as you're training people you have a training website that you can throw content in and show how these different features work without affecting live content. As you review sites that are ready for relaunch, they'll be helpful to have for site improvements. Pre-launch review kits so that if you find yourself telling everybody over and over again you need to put all the text on your images, have a canned response for that so you're making sure you're saying the same thing. And that canned response gets better and better over time as you find it. So the migration process that you made was lengthy. The 80-20 rule comes to mind. 80% of the site migrations took 20% of our overall time and sites making up a majority of our web traffic were migrated into this design by the start of the fall semester 2017 one year after 2016. One year after initial launch. In comparison, our last year migrations focused on niche sites that made up less than 5% of our overall traffic. We finally kind of set a line in the sand and said, we've got to shut off this old WordPress server and we actually had some sites that disappeared because either people couldn't be bothered to get in touch with us or it turned out that the site was no longer needed because everybody that had worked on it went away. So some of these sites were migrated into our new design and still haven't been launched. You may. We had a number of notable websites outside of work I see. I mentioned the Graduate School, Climate Change Institute, Center for Aging, and Sciences. All of these were proactively contacted by our team to migrate into our design. They contacted us. Each was its own project where we drew upon the communications framework to ensure we could accommodate the site into our theme. Climate Change Institute website was launched in August of this year as the fall semester began. So we now have really everything that is you may.edu So where to go next? If you may, we can see a whole week of WordPress training. That's been a game changer for us. Previously we would have a series of these, like six times a year we would do WordPress training. But by doing it weekly and on the same time every week it just, you know, I go places now at campus and they'll say, oh yeah, you're famous WordPress training. Word has gotten out that it happens on Thursdays at 10 a.m. And we take walk-ins. We like people to tell us they're coming but people just show up. It helps the community see digital communications as a resource. And each team member has had the opportunity now to be seen as a subject matter expert in matters pertaining to the web. It gets us visibly out there that you see that you're the people that they go to for web. That isn't WordPress. They'll still want us to chime in on it. We now, just at the beginning of this year send out a monthly email newsletter to all administrators on our multi-site network. We use MailChimp for free. And my server administrator sends me an updated list of administrators every month which I use to automatically add new subscribers. We have a big board at the very top of the newsletter that says you are receiving this because you are an administrator of our WordPress website. There is an unsubscribed button and people can, but we ask if you don't want to receive this newsletter basically we don't say if you don't want to receive this newsletter anymore. We say if you don't want to be a WordPress administrator any longer click here and we'll take you out of WordPress and you won't get this newsletter anymore. And we've had people do that. It's been great. Seriously we have 900 people in our WordPress environment we used to have about 1200 people all sorts of administrators. When we first started this process I got bounced backs from people who were no longer on campus and nobody had told us that they were still an administrator in the system. They could have gone and logged in using their credentials and done who knows what to that website. It's just, you know, just has security talk. You just, you know, we're lucky that it's a very ethical community that doesn't do that. Now we get announced we get bounced backs with people and we can take them out. And, yeah, we get we hear from users that no longer need access and keeps us up to date on that. So that's the spiel it's going to be about 25 minutes I've got 10 minutes for questions so yeah. How easy or difficult was it to migrate the non-wordpress sites into the Humane WordPress community? Was there, did they come kicking and screaming or was it very easy? Or somewhere in between? I could say they some of them came big gradually but I wouldn't characterize it as taking and screaming. In all cases they came to us. Notably because they had all with one exception they had all been in another content management system by a company in Maine that was great when they came up, they built their sites in the mid-2000s and that company said, hey, WordPress is great we're not building our own CMS anymore. So finally in 2016 or 2017 they were told there's not going to be any more updates to this content management system we really should move to something else and touch with us to say, yeah, we got to move anyway so let's move to WordPress. We were able, our focus for those sites was to get their news into WordPress automatically so Climate Change Institute is an example where there were hundreds of news posts over the years and we made some changes to their content management system RSS feed so it was giving us everything from the beginning of time and then we used that RSS feed to create posts in WordPress and that worked out great we were able to save them a lot of time on stuff that was very low value for them to manually migrate Pages, we had them manually recreate because it was an opportunity for them to make sure they were moving things that actually they needed and that was part of our kind of archange feel for site migrations in general was before you move audit your site and pull down anything that's not needed you don't want to pack up something in a box to take it to a new house and then wonder why you packed it when we moved to Maine in 2000 I was opening up a box of kitchen stuff and there was a juice here an orange juice squeezer for oranges and I was like why did I pack this and bring it to Maine I don't care Of course, great in Florida, not so great in Maine so Thank you When you guys did the migration and launched this site, did you see a big dip in traffic or analytics in the site after launch? It's tough to answer that We kind of did but we're not sure how much of it was actual traffic changes due to the site moving and how we're measuring traffic and our old Maine theme had a Google analytics code hard coded into it every site was getting this one analytics code and it was an opportunity to put your own code in so we had some domain sites like english.umain.edu who had necessarily had their own analytics code but also getting our catch-all Google analytics code so an about us page for english.umain.edu and umain.edu we're getting counted as the same page so there were some traffic changes but I was just telling everyone that it's becoming more accurate I would say just in general we did see bounce break going down within your site we saw a much better experience we measured mobile users and our news site now we get a majority of traffic for mobile and that just wouldn't have been possible with the old theme because people would have come to us for mobile but not stuck around because it was a terrible mobile experience did the event with the internal communications that you've outlined as far as in the stakeholders involved there was that all? that was in our wheelhouse we were focused on coding and we picked a vendor that was specifically WordPress centric because we didn't want a higher vendor that would want to take us a step back to reinvent the wheels should you be using this content management system instead and that was really the key they went on to do their work they weren't really pinging us for input as much in that June time period which really gave us breathing room to really flesh out that communication plan I will say the vendor did do a great job of trading the trainers and we used that training session that they gave us in the new theme as the basis for our WordPress 101 training as to what order to do things in we really had a nice blow to it and we still use that framework today yes I find the hardest thing is that people to clean up their old site and all the content how did you manage that and how did you get people to do that on a timely manner and the other question I had was about redirections did you do a lot of that or like if they were getting rid of a pay did you make sure that they were being redirected or not so for the first part we had a batch process that we would have people in a timeline of week one you're going to prepare your site by legal content week two you attend our training we've migrated your snapshot and given you access to it in the new site and then we give you two weeks and we want to launch you that was wildly optimistic for the majority of sites small sites they were ready sooner and we launched them but other sites took maybe a year to my pay full can of words because they had been making changes to their live site that needed to be reflected in the in progress site we actually had one site that had to do a snapshot a couple of times to refresh before they could make that time to launch we really wanted to make sure that our point to them was we wanted it to be at worst a step sideways in other words we didn't want them to be feeling like they were taking a step backwards and how their site was functioning instead but at the same time we told them don't try to make this like it's going to be amazing that we're at the new design because look how much better our site is get your site in the new design and then work on the amazing part because that time period where you have two sites is really a headache as far as redirection a little bit but we didn't go crazy, what we would tell people for large sites in particular was that Google Analytics for entrance pages and the entrance pages we made sure that URLs would stay the same because they're migrating from WordPress to WordPress and we tell them don't change the names of your site pages arbitrarily if they're a good entrance page so we would make redirects for entrance pages that were changing but a lot of those we just let the search engine submit site maps to Google so that they knew where all the new pages were but we didn't make an exhaustive redirect list thank you did you have to chase people down for new content and people look at this as an opportunity to freshen their content because sometimes that's really such a bug of those trying to get the content from the client yeah so because we were migrating all your content as is it was a heavy lift but we did tell people we gave them some tools because back in the day we would tell you when pages were created you have to go into the page to see what was last updated and we exposed that last updated date into the page dashboard and it would tell people sort your pages by last modified date and that's where you start is the pages that haven't been modified since 2010 not that they were a page that was created in 2010 is fine if you're keeping it up to date take a look at it and decide oh my gosh this talks about president Kennedy you may have had a president Kennedy but instead of president 3D Mundi that was what we really geared people towards look at your oldest content and then we did really try to get them to do a good job with their home pages so that they were a better experience for those I have to get in here and