 Hi everyone, my name is Krishnan Lagas and I'm a freelance user experience designer And I wanted to start off today with you know, just a bit of a story not of the content migration itself But just a project that I worked on prior to that so in 2011 and 2012 I was working at a large telco and You know at the time we were tasked with building a customer support knowledge Knowledge space and you know, we're creating it using responsive web design techniques And so you know at the time this was actually quite new and exciting because the only things or the only major sites that Were that were responsive were was the Barack Obama site and the Boston Globe And so we spent several weeks learning about you know responsive web design Trying to be you know mobile first and just generally breaking down our desktop-centric thinking And so our deadline was tight and many compromises were made You know as is typical of many projects. We're actually quite literally locked into a room So there was about six of us given six weeks to produce this thing And so you can imagine how tight the deadline was and so launch day came and The system that we designed you know was going to be put in front of users and so both the editors sorry, not in It was going to be put in front of users so both the editors who would be creating the content and our customers and You know it all really fell apart and it was all because of one word well, it was actually two words and What we failed to realize that our content editors were just simply copying and pasting from word documents You know they were bypassing our carefully crafted HTML templates. So what we ended up with was you know About 200 support articles with malformed HTML broken content and no mobile version and What happened was basically the project team so everyone from say the designers up into the project leaders So my boss was Sort of on the ground floor in the CMS hand editing those HTML pages just to get it working So why am I bringing this up? well for starters, I became a real expert in you know, regex syntax and Just had to tell someone but but more importantly We were so focused on how amazing the experience would be for the end user that you know We neglected to think about the real users, you know, I eat the content editors and the producers So you might be thinking you know, this is this could all have easily been solved with a single button But I think it goes much deeper than that, you know, like why would people actively avoiding the tools that we created? You know that we created specifically to help them do their job so I've been working as a front-end developer for a couple of years and more recently as a UX designer and In my experience, you know implementing a new CMS has always really been about you know Technology first and less about the poor suckers who have to use the damn thing every day I know personally I have a tendency to design things from the outside in you know Just I often catch myself building a solution in my head You know rather than spending time and thinking about the underlying problem that I'm trying to solve And also the people that I'm trying to solve it for So I'm also equally guilty of putting together wireframes and Photoshop comps, you know Just filled with Laura Mipson I'm always assuming that you know someone else will take care of this They'll just fill in the boxes and I don't have to worry about it So all of this was just really front and center in my head as we moved on to our next project Which was the content migration that I'll get to and I'm hoping that you know if you're a designer Developer a BA a strategist, you know, whoever and if you've got some influence or any input into, you know Similar projects that today will give you some things to think about so regardless of the CMS that you use And I also wanted to share this as an example of you know It was changed that wasn't necessarily grand or ambitious or even overly transformative You know our reasons at the time went necessarily to redo the entire website provided brand new experience But it was simply to just move away from the system that we were on because we didn't like it we didn't want to pay for it and You know despite all of that we were still able to create meaningful change and improvements to both content producers and editors and also our end customers So let's talk about the project So what was involved was you know, it was approximately a thousand pages that had to be manually moved over It was multiple visual styles Some dating back from about 2006 there was outdated content and there was about there was a disorganized IA Just from years of sort of neglect and just any real lack of structure The core team was comprised of You know one UX designer visual designer a couple of front-end developers a back-end developers or two some producers one tester and a business analyst and Towards the end of the project, you know as the actual migration of pages was ramping up We added a bunch of visual designers and about ten more editors And the project itself was broken down into roughly three phases over seven months So we had the content audit That ran from January to March there was a design and development phase from about March to May and the migration the actual migration from April to July and It's probably important to note that there was a lot of overlap between the phases So you know design work would often bleed into the migration phase now guiding principle so we knew that this was a great opportunity for us to improve what was on the website because It was it was a bit of a shemozel So there was there was things that we knew we could tackle and also You know just things to improve because we had customer testing done over the years You know we had this raw set of data of how people sort of thought of the website but The underlying Motivation for this was you know, it was just a straight-up migration We were moving from one system to another, but we couldn't ignore how You know the opportunity that we had so we established this guiding principle of you know, what must be migrated? Should be equal to or better than the current experience So we knew that a lot of people stakeholders product managers and so on would see this as their opportunity to get a new website So we had to manage this and basically manage their expectations So what were the challenges? Well, we had many but I'll just pick out a couple and talk through and in a little bit more detail question How do you design for a system that you've never seen let alone use now? This might sound very strange But so we didn't actually get our hands on a sandboxed environment until about three months into the project And we had to fight for it We you know, but we're building all these things We're designing all these things without actually knowing where it would land and how it would be implemented and so, you know, we were pushing to basically, you know Get these things what we're pushing to to get these things life and and where we started with was Seeking feedback from the users. So, you know, we were talking to the producer team and Given the way that the internal team is structured meant that me as a UX designer You know, I had zero exposure to the actual CMS So I was designing all these things, you know modules pages sites and so on without really fully understanding how they would be implemented and So we talked to them about their experience what their workflow was like, you know, where their pain points were and In short the overall feedback that we got from them was so Our content producers had a tough job, you know, I have to hand it to them They were editing raw HTML to make content updates So it wasn't exactly, you know a dream weaver style of editing, but it was more like Windows notepad You know, it was a process that really could be described as inefficient You know requiring a certain skill set and very prone to mistakes So we started looking at different ways of building these pages and just really addressing the producer pain points And you know because everything was being moved over manually. We had to stop and ask how do we build this and You know, we would start with the producers and often the answer would be Well, I would just get the HTML code from the developers and we just chuck it into the CMS So what we've got here is the most recent version of pricing tables This is the nice version what we had previous to that was just inconsistent and generally a mess So it was a prime candidate for us to improve To improve this particular piece of content during the migration. We didn't want to just move it over one for one But we had some things to consider For starters, you know, this content would be reused across multiple pages We had to account for the different types of content that this module would display We also didn't want to spook the product managers So the product managers and the marketing team had very little exposure to our migration project so our thought was if we started coming in and just sort of Waving our fancy new redesigns in their face and saying, this is what's gonna. This is what's gonna happen You know, we get pulled into this endless loop of feedback cycles and approval chains we also had legal implications because Telco as an industry is very heavily regulated, you know, so we had to tread carefully So this is a bit of a failure story on my part But hear me out So when thinking about the different Interfaces that we could build for the CMS my first thought was Hey, let's use a spreadsheet You know Close enough You know things are being presented in table format. We could you know Do up a couple of spreadsheets for all the different pricing tables that we had and just import them, you know, quite quickly and easily So I went ahead and started designing a tool that would take a spreadsheet of pricing information sort of added to the CMS Did work? The idea really didn't resonate with our editors For a couple of reasons for starters None of the content producers could use Excel in their day-to-day work or rather they weren't using Excel in their day-to-day work They were using Photoshop. They were using this got off or CMS editor, but it's not acts not Excel So if we forced them to change the behaviors, we'd get a lot of resistance Second of all we could get the content in very quickly no dramas, but it was impossible for us to get it out You know if we made a mistake or we needed to modify the data structure or so on it became really impossible and Lastly while it worked for numerical content It really didn't work for anything else. So Any other text content like legal terms and conditions and so on just didn't fly So in the end what we ended up doing and apologies for the rough sketch But I think this was the standard of the documentation that we were producing as part of this process I can show you my sketchbook But in the end what we ended up going down with was you know relatively simple and structured set of data But we broke it down into smaller more atomic bits. So for example the features were sort of their own thing you know individual fields and You know you could apply those to a certain number of plans With a bit of extra data on top and if you wanted to combine them into multiple plans to say you had a variation of the 12 months or 24 months you could combine multiple plans onto a page So you would get this particular layout and we also had rules around the module that if there was say more than four being displayed at one time We would have this fancy Sort of scrolling mechanism that would just cut off the fifth and sixth and seventh elements Just so that we would indicate that there was actually more there so it wasn't the prettiest but it worked and You know as I said we had to stay true to what had already been there Because if we started redesigning this in in you know from scratch we would we wouldn't get anywhere because We have the product guys to deal with basically so this got me thinking about other examples of you know content editing tools and I Came across this one for the ITV news which is the news service for a British Channel and In 2012 you know they launched their news service and it was fundamentally different from typical news sites So without going into too much detail The site was structured more around issues and events rather than just publishing news articles on a given day So for example, you could follow the Egyptian uprising Over time from its inception right through to you know the aftermath with tweets photos and so on The agency that was responsible for this redesign. I think they're a British mob called made by many they spent a lot of time thinking about how journalists worked and Crafted the tools to suit how they worked They shadowed the journalists in the newsroom and even ran their own test fees for a while They prototyped and tested these tools with the people who would be using them and the tools that they created were designed to allow Journalists to focus more on finding and creating content rather than fighting the CMS So what we've got there is just a very basic post editor with very basic styling so you can only do bold italic and links What you see underneath is just sort of more structured data So you can include multiple posts tweets quotes and whatnot. You can also drag and drop and rearrange them So if you wanted to include a range of tweets or reactions, you could do so This is a prototype of their their picture editor So instead of having to find an image, you know find out what the editorial size would be Because you know, they don't have that on hands crop the image Save it in an appropriate format make sure it's compressed nicely Find out where they save the file Upload it check it to see on-screen Reupload it if it doesn't look right, you know this tool took care of a lot of this so they didn't have to And they also realized that people who are out in the field didn't necessarily have access to a laptop They often just had their smartphone on them And so the designers created this tool to allow journalists to quickly send content to the newsroom Where the web team could collate and curate streams of content coming in so there was this idea of you know Allowing the journalists to go out there and just worry about Gathering while the guys back at home base would put everything together into a sort of coherent picture So a couple of thoughts For us as part of this project understanding how your users worked became really fundamental for us to make any progress You know, we sat with them talked with them sometimes had a beer several You know we and As a result, you know, we were creating new tools and processes And we were trying to change how they work often for the better But you know if we were pushing too hard or if we were pushing them in ways which you know They weren't used to or it just didn't sit, you know, we would get resistance So we had to find out where the edges were and I think that came down to just listening to how they You know what their frustrations were finally You know, you're creating sorry these content creation tools, you know, can we make them more interesting compelling? Efficient, you know, can we do other things and just simply filling out a form? question So with many stakeholders, you know, how could we keep everyone focused and moving in the same direction? so This project was a bit of a bastard Actually, it was it was it was a mess, but you know, I think it goes without saying that, you know It was a really highly political project We had people in multiple parts of the business with a vested interest in in the success sometimes a failure But this also affected people's day-to-day work and you know, there was also legal implications to consider So given the far-reaching nature of this project now, how could we make sure that? Everything or rather every one, you know that needed to be kept in a loop was being done. So for us physical space was Really effective in not only getting the core team to focus on what needed to be done in anyone given sprints But also getting external stakeholders and even the greater online team on board with what we were doing How we've typically done things this may seem familiar to you guys But you know the UX designers would come up with a bunch of wireframes We'd throw it over to the design guys to make it pretty we throw it over to the dev guys to build the thing and then the back-end guys would get involved and Make it happen Testing guys would jump in there and then the production guys would make it live You know your standard waterfall process given what we had Which was three months during the development phase Just out of sheer necessity, you know collaboration between designer developer to the tester and producer became very important You know we had UX designers working with back-end designers sketching out potential solutions The visual designers were working with producers to try and understand how to upload images into the CMS all of this was actually quite new for us and and Typically how we didn't sorry it wasn't how we did things in the past We really couldn't afford to have instances where designers or developers would basically say you know I'm not gonna start work until I see wireframes Sometimes a sketch should be all you need to get people to start working And if there was another level of detail that was needed so for instance the testers needed You know functional specs and so on it was called out early and often It also really didn't hurt that we were sitting in the same area rather than it being siloed out This became a bit of a mantra for us So we used a cam-band board to kind of keep track of who was responsible for each bit of functionality So if you're not familiar with this, it's just basically a whiteboard split up into you know the steps UX design dev going down the track and using User cards or user stories to basically identify what stage of the process certain things were So at the start of any given sprint we would prioritize these user cards We were we would identify the goals that we wanted to hit And we'd use daily stand-ups to identify any potential blockers and you know We had many conversations outside of that to kind of collectively reach agreements on where we would do things So it was it wasn't uncommon for us to you know if I was working on a particular module say a Twitter feed I would say you know pull in the the design guys and dev guys and say look here is what I've got sketched out What do you think and? They would say no that's bullshit that won't work or they would say okay Let's go with that and they themselves would get started on the work that they needed to do so that when it came to them They were already ahead We also set up design walls and other spaces and we use these to get buy-in from external stakeholders We use it also to keep everyone up to date with our progress We sort of use this as a finish line for everyone We printed ias we stuck designs on the wall sketches everything We printed out every page that we were moving over and use this to talk managers through how the migration would affect their content so It wasn't uncommon for us to invite a couple of Product managers over and we basically walk them through the current version of their site and also what we were proposing as the new ia for their site and What became apparent was you know as soon as we talked them through as soon as you know They saw these these pages in front of them. They start immediately saying Wow that stuff's out of date and And these they were responsible for these sorts of things like this was their content this was their product and They had no idea on on what their site or their product looked to users and You know we found this is a little bit more effective than just sending over us a bunch of Spreadsheets kind of hoping that they would respond and it really also helped that we were only just a level or two above them Physically so we use this as clear agreement on where we would improve things and where we would leave things as is We also use this as a way of you know promoting the project internally as there wasn't a lot of visibility outwards So, you know, we were trying to be transparent create a greater sense of ownership across the online team You know it was it was a project that was you know, it was just working the core team was just working on this and so What we found was having this awareness Having this in a public place. So this was actually in the main sort of kitchen area You know it created a greater sense of ownership across the online team and People were having conversations around it, you know, they were working out how this affected their work you know people could see the potential improvements and Sort of how dramatic it was compared to the old version, you know, there was real excitement and Often, you know, they would have conversations outside of the team, which was great because they didn't need to talk to me And when it came down to the tail end of the project when, you know We were getting the migration and we're just pumping out pages. It was all hands-on deck So we weren't necessarily trying to be agile with the capital A. You know what we were doing made sense to us. I Admit I'm really not To sort of I don't know a lot about agile methodology. I appreciate some of the things that it promotes. So things like, you know Interactions over over rigid specs, you know being adaptable adaptable and You know just the greater focus on communication and By the same token You know we instilled this culture of you know communicating to others So if someone needed something from me about what I need so what I needed to produce to get their job done They would call it out early and often And finally, you know using physical space to reach consensus and buy-in was also a big one for us question You know, what's the best way to get a team of new producers up to speed on a project? So as I mentioned earlier the project started off with two producers But would ramp up over time with more producers being brought in So these producers wouldn't have the tacit knowledge that the core team had and often they were just contractors being brought in specifically for this project So how do we get them up to speed in a short time? For us it was wireframes and a patent library So Because the core team had to understand how content producers were putting these pages together and as much as I dislike wireframing You know every page that we moved over was had it had a an associated wireframe Because so so much of the source content was so different We saw this as the only way we couldn't get the produce guys to basically look at The original file because they often couldn't work out how it would be built with a new system So we created a patent library of reusable elements So things like content modules baseline grids and page types Which meant the producers didn't have to think about it how each page would be built So just to quickly run through the benefits of establishing a patent library Shared vocabulary When you say link box and I say link box, you know, we know we're talking about the same thing Consistency of experience when I hover my mouse over a link box. It's operates in the same way Rapidly train new people here's how to create a new link box avoid reinventing the wheel What if the link box has multiple links? What if it has no image? And finally empowering content producers, which is sort of a little bit at odds with what I just said previously But what we found was again because the content was so varied Premigration, you know, we basically established this framework so that we could let the producers make their own Decisions about how something could be built and if it was 80 80% of the way, you know And it didn't look horribly broken, you know, we were okay with that and often this would be applied to say lower level pages or Stuff that was generally considered a low priority as far as How useful it was to customers? so this is an example of Patent library that I put together So this style is generally a little bit more sort of casual in tone You know, I tried to make it less like a piece of statute and more You know, just a set of recommendations. I tried to keep it succinct I also wanted to include examples in line So people could see when I talk about hover states and you know clickable label elements, you know, they could see how they worked so a couple of other examples the BBC gel was For me the inspiration for the patent library. So when I sort of put this thing together I looked to the BBC gel and You know when I saw it I thought yes, brilliant. This is exactly what I want. This is how I want to communicate You know, they're solving the same problems that I'm trying to you know It was a focus less on actual code, but more defining the overall language For things like carousels typography other core page elements No, it also defined how things should work across different contexts, you know mobile and TV and When you drill down to the individual components, you know, they gave you variations based on you know If you were doing a carousel with no images and just text This is how it works if you're doing them with just images This is how it works and so on and they weren't sort of being so Rigid in there in their designs which made sense because they had so many so many different types of sites to deal with So compare this with the Starbucks stargine Which is a little bit more developer centric So you can see different page configurations, you know drill down into specific CSS show the grid overlay and Demonstrate how things would reshape on different screens. Just a reminder You know, don't just set and forget invest effort in maintaining the library, you know, if you set one of these up Work out who's going to be the patent librarian, you know, who's going to maintain this over time You know start thinking about how decisions are made as far as putting new things into the patent library And you can bet that already established patents may break with either new types of content or even new devices So you need to be prepared for that And also keep it in a centralized and visible place So whether or not it's a public URL or a place that is say on the internet or even just you know Hand like printed documents that you give to a new person when they start You know, it needs to be visible. It needs to be sort of reinforced over time And also never stop selling the benefits of the patent library to stakeholders. So we found this really useful when again I'd love them are dealing with marketing people and the product guys So they would often come to us with you know, we need this campaign up immediately. So we'd say yeah, sure absolutely But you should really follow it in this format and you know, we can take care of that for you So for things like, you know, competition pages and sales and so on It really helps like, you know, just repetitive content that is maybe just created every couple of weeks and so on you know, it really saved us time and Yeah, and finally How can we make things future friendly? So the company I worked for we sold mobile phones. So It was a bit mind-boggling that, you know, our content wasn't really optimized for the devices that we were trying to sell to people, you know, all we had was It was just some shitty, I guess, website that was probably built for Nokia phones. So At the start of the project, you know, we had high hopes that, you know, we could work in a mobile version of the site You know, we could develop this in tandem make things responsive. However, however you see it But, you know, unfortunately, it was the scope at the very start of the project Which was a bit discouraging for us, you know, given the previous work that we'd done But what we could do was lay the foundations for future mobile work So just a quick reminder, mobile does not equal lights You know, we shouldn't assume intent based solely on the device that we use and as a result, hide content accordingly Laptops often run off 3G connections and smartphones, you know, they're commonly connected to Wi-Fi So I'm not going to belabor the point because there's many other, far smarter people who have already spoken about this at great length But what I will talk about is how we approach the project. Sorry, how we approach this during the project So for us, we limited HTML usage, or rather, WYSIWYG, HTML usage, and we structured content and we started identifying page types So, we made the decision that we wanted to basically avoid WYSIWYG where we could For a couple of reasons, you know, the visual designers were worried about the wrong styling, the wrong look being applied at the time of production The developer guys were worried about code bloat and performance And I was worried about, you know, this ruining our chances for any sort of mobile version So, you know, we were happy that everyone was on the same page and, you know, I was quite happy to get rid of the inline CK editor The second thing we did was look for patterns in content We identified pages that didn't need anything beyond a simple edit box, so we called these flex boxes We started looking at landing pages, you know, bespoke pages that had a lot of custom HTML And this allowed us to understand, you know, just how much work was involved, what areas of the site might need mobile specific templates Or where we could just use responsive styling And it also gave us sort of a list of pages that we could just start giving to the production guys just to start moving them over And the last thing we did was sort of dive deeper into certain page types and create content rules around them So this is almost a functional spec of the pricing table that I showed you earlier And we used this to communicate to the developers and the producers, you know, just how content would be used in certain areas So for example, we used it to define link states, what could be edited, what remains static, you know, and what happened in certain situations And our hope was that when a mobile version was to be developed, you know, whoever was taken care of that We didn't need to second guess the kind of data that they were working with So how did we do? It wasn't too bad So of the four development sprints that we had, you know, we managed to hit the targets that we set out in each sprint The site went live in about August last year and, you know, there's been considerable improvements to the internal processes And the site itself is a little less bloated and a little more robust And as I understand it, the patent library is being actively maintained And, you know, the beginnings of a mobile optimized version is already live And it's drawing from the same pool of content as the desktop website So this is good news And to reflect on, you know, what's happened over the last few years, I'm really quite proud of what we were able to achieve You know, this experience challenged the way I worked It got me thinking less about specific deliverables and more about, you know, the relationships that I had with the people around me You know, a lot of the challenges that we faced as a team were more about communication and less about technical challenges And we skipped the typical waterfall approach in favor of, you know, more cross-discipline collaboration And type feedback loops with the end users So not only did we test our ideas and concepts with the producers, we also did usability testing on the new and improved pricing tables that we put out We created and established a design vocabulary and enshrined them in a resource that was to be used across the team We also tried to ensure that our content was created and stored in a way that could be reusable and adaptable And finally, you know, working in an organization like I did on such a project meant that as a designer, you very quickly learn to become very pragmatic And take the wins where you can get them You know, if you always reach for best practice, you're going to be very disappointed Only because, you know, there's so many other factors involved and, you know, you need to know when to push and when to yield Assets in total So I don't know specific assets, so if you mean things like PDF files and so on We have that in the spreadsheet somewhere But it was, yeah, so for every page there often had to be like specific Items About a thousand But that also included, yeah, it also included things like the, yeah, images, PDFs and things like that So what do you mean by that? It wasn't a Drupal site Gotcha No, yeah, it wasn't, we basically, we had to move things over manually So it effectively recreating each page in the new system We couldn't use anything like, you know, a database drop, you know, lift and drop Which at the very start of the project was what everyone had thought this project would be It was just simply carrying a database over to the new system and just putting the CMS on top But no, it was, we had to manually recreate everything Which sort of amplified the complexity of the project so much Sure, so the question was, why didn't we know what the CMS was? We knew what the system was, it just wasn't up and operational So we knew that we were working on this system It's, we went from Stelland to Fatwire So, yeah, it was funny because we went from an earlier version of Fatwire over to Stelland And then back to a newer version of Fatwire So as far as the rationale, I don't know But the bottom line is we didn't have access to it Sure, so the question was, when talking to the product managers How did we describe the project to them? Whether or not it was a straight up migration or something like a brand new website We were trying to be strategic in how we were framing this So for the most part, we said it was a straight up migration And what we said was, like, your content will generally be moved over one for one In particular areas where there was actually more changes So, for instance, where someone had an old version of, say, the pricing table We were a little bit different in how we approached it So we said, you and I both know that this content is really old Hey, we've got this really fantastic new module to display all this Wouldn't you like something like that? So, yeah, it just depended on, I guess, the state of the content that we were moving over So the question was, did we get any resistance in using the physical space? No, generally speaking, it was pretty great The developers themselves, they didn't necessarily need to use that But they always use that as a reference So for us, it was primarily, say, myself and the visual designer So we would throw up our stuff all over the place What was really effective was, I think, back here there was a giant IA That we printed up So if you just see in the corner That was sort of a blown-up A0 version of the IA that we put together And basically the producers used that as their reference point So they would often just get together in the morning and say Okay, you take this section, you take this section, et cetera, et cetera So, no, it was generally well received Sure, I guess, we were fortunate that the people editing the content were the producers So it wasn't the end, sorry, it wasn't the product managers and the marketing guys Making the changes, so we had a little bit of control in that sense But also, I guess, I think the people sort of heading up the project at a high level Were really concerned about performance And so the guys basically said, if you put in WYSIWYG, you'll get all of this blow And because we were so mindful of how things were previously Yeah, it was just, we knew we didn't want to go down that path Because it was almost a step towards enabling source mode And then we would just have the same problem all over again Yes, they were just using straight-up source code So, just to make sure I've got the question right How do we prevent the decay of the content? As part of the project, did we start educating the people? So product managers and so on about data structures and things like that Yeah, at a very basic level, it was to get this off-stellent And I guess the way that the processes tended to work was The product managers and so on, they interfaced with updates to the website through the online team And so they didn't care how it was done, often they just wanted it done So we had to, I think the education part wasn't really a high priority for us It was just we needed to tell them whatever we needed to tell them just to get the job done And also let them know of the benefits, but often they weren't necessarily directly involved in the process Time for a beer