Live Q&A | Why Oxfam switched from Sitecore to Wagtail CMS

Speaker 1: Good morning everybody. Thank you for joining us. I'm Lisa and I am responsible for the market. at Torchbox which includes organising and planning our events and I am particularly excited about this one because we do have a very special guest join Joining us, who is Theo Ratcliffe, the head of website at Oxfam. So hello Theo.

Speaker 2: Hello.

Speaker 1: And also we have Katie today, who is your hostess with the most S in her role as Parking. and Katie is a product director at TorchBox. So hello Katie.

Speaker 3: Morning everybody.

Speaker 1: Theo and Katie worked really closely together on the replatforming of Opsclub 's flagship website. And so they're going to be sharing their experiences and their learnings with you and they're keen to answer any questions that you have so please do use the Q<unk>A facility or the chat that you should be able to See at the bottom of the screen. We're going to be answering any questions at the end of the session. We also have Tom Dyson joining us today. You can see now, but he's not actually presenting this morning. He is here to answer any particularly techie questions that we might have at the end of the session. So hi Tom.

Speaker 2: Hi everyone.

Speaker 1: So as Tom was just saying, in terms of the format, this is a webinar. So you can see us but we can't see you. And we've got 60 minutes and quite a lot to get through. So if we do miss any questions that you've asked, then I will send the answers in a follow-up email afterwards. And I think that's about it. So I'm going to hand over to Katie now to get things

Speaker 3: Thank you very much for the introduction, Lisa. Well, hello and welcome everybody. Great to see so many of you here. And I know from sort of personal experience the decision to redesign and replatform can be quite daunting and often sort of fraught with complexities, particularly in larger organisations. And in a landscape where budgets are really tight, particularly in the year that we've had to date, and user expectations are sky high. It's really crucial to make the right decisions and for the process to run smoothly so ultimately you can achieve your goals as an organization. So as Lisa says, what we wanted to do today was just share some of the learnings and insights from Theo based on

Speaker 3: Oxfam's recent experience of replatforming. So Theo, welcome, welcome. Great to have you here. Could you just start us off by telling us a little bit more about your role at Oxfam and and in as part of the recent um redesign.

Speaker 2: Yes, so um I've worked for Oxfam for about 18 years uh since kind of before we had much of a website speak of. I remember in the like when I first started, if we had to put up an appeal form for an emergency, we'd have to phone British Telecom to publish it. I don't can't quite remember why we had to do that. But hopefully we've come a long way since then. So when I first started, I was um the senior web producer, which meant I kind of built campaigns and ran the web production team. But for the last Uh 18 months or two years, I've been the head of website. So I'm now looking at the direction of it and overseeing the technology we use. And I think from like the first week of taking on that role

Speaker 2: I kicked off the prod the project to replace our existing system, which I think gives you an insight into the kind of relationship I had with it. So yeah, that's me, but thank you very much for having me. I think it'll be a therapeutic session for me quite cathartical.

Speaker 3: And could you just tell us a little bit about um the situation you were in before on your previous sites?

Speaker 2: Yes, so we used uh We used Sitecore, we used it for about 10 years. But it was a very heavily customized version of Sitecore. And Sidecore, if people don't know, Sitecore is an enterprise level kind of proprietary CMS. So it's It's um powerful but does come with a price tag. And as I say, we built a like heavily modified version of it because Oxfam I think felt it had some quite hard requirements. a lot of which seem to revolve around a CRM, the internal database. So we had the agency we worked with kind of throw the box away, dismantle it and glue it back together again as a kind of Frankenstein's content management system. To the extent that I remember going on a training course at Sitecore HQ and about halfway through the day

Speaker 2: putting my hand up completely bewildered because it looked like but didn't bear any resemblance to the tools I was using at work. But we so we used this kind of diabolical creation to run our our main website, our online shop, and a small uh website of research papers called Policy and Practice. And I think the rationale for for them all using the same tool was good. in that it would obviously save money potentially, but with the idea the idea was that we'd all become a kind of uh greater than the sum of our parts. But In fact, it ended up that each each site, and they were all very different sites, they had dependencies on each other. So when there was an issue with one, they kind of all had problems. So

Speaker 2: they became, we had a lot of stability problems. So in a kind of entirely predictable flock twist, we uh we found the number of bugs were increasing. Uh we ended up spending very little of our time introducing new features and more and more time kind of negotiating with each other about whose website should be fixed first. new hardware requirements, quite expensive ones would would appear and we had more and more technical debt technical debt grew, support became difficult, and it just became untenable. But that the headline issue with that is that it was wasn't a sustainable technology in the sense that it was just too expensive to change anything. and uh it and it became very unstable

Speaker 2: as I said. Um and we need to change, we need to innovate and we need to change all the time and we just couldn't do it. So we ended up using other systems, often often open source systems, we use WordPress a lot to kind of plug gaps in it and we injected code in it to to fill gaps. And yeah, we have a lot of if you look at our if you looked at our website previously, you'd find yourself going from one platform to another, perhaps not. Perhaps unwittingly because we don't tie these things together just to get the job done. But yeah. So it wasn't great.

Speaker 3: Does sound like a pretty challenging situation to find yourself in. But was there a particular sort of event or point in time where you decided that you needed to to make a move and make that change

Speaker 2: Yeah, so my I think my team felt the writing was on the wall for the system for quite some time. We were having to kind of employ ever more curious workarounds. Uh I remember one occasion when there was a, I think it was a typhoon somewhere about in probably early 2019 when um we found that we just couldn't we couldn't publish anything. I can't remember if it was where we when we couldn't log in or whether it was just when anything we published made everything fall over. So we had to do things like to respond to that emergency we had to use A-B testing software, set up a a kind of set up an ex a mock experiment, crank one of the variants up to 100% and kind of superimpose the content on our site. And that went on for about

Speaker 2: 10 days And I think the for the wider organization, I think minds became focused by an issue we had with an upgrade. So um We'd already kind of started a ball rolling on a r investigating replacements, but we found there were there were we were trying to get this like Frankenstein's monster um that had been built to up go on its its uh defined upgrade path and we just couldn't do it. There was too too too much complaining. We couldn't get cycle zone MVPs to come and fix it. So it just became a real issue. And that meant that gave us a lot, actually a lot of impetus to move on And we had to do it very speedily. But I think an interesting thing is that the some of the issues we had with it were kind of baked in.

Speaker 2: from the start, just from the way it was conceived. So this idea that you do a big launch, you heavy on business requirements, you big investment, and then You have a big launch party, and the moment you my finger is showing you how much money you're spending, by the way. You have a big launch party, and as soon as you launch, your money's dried up, but and only then do you start to learn what how people interact with it. So your site is in a perpetual state of decay and you end up with these boom and bust redesign cycles and your site is is always operating. uh is always underperforming. And I think we recognized that and I think we tried to the way we approached the new website was in such a way that we would

Speaker 2: kind of avoid some of those mistakes. So we worked off a roadmap. We did very short sprints picking off one thing at a time, had a big discovery phase and a phase launch, I think, to kind of yeah avoid some of the mistakes that Perhaps ten years ago were more common.

Speaker 3: Yeah, no, it makes a lot of sense. Um and I guess as m most people um who've joined today are aware, you know, compared to five, ten years ago, the the content management system market is you know a lot more crowded. Um so it'd be interesting to hear just a little bit more about um how you started your evaluation and what sort of criteria you use

Speaker 2: So I we started with a kind of framework of four key principles that I just ripped off the government, the GDS web. Sorry. So these I kind of rattled them off all the time actually. So here we go. Number one is that any system we use needs to allow us to like constantly iterate, which is the pompous way of saying we need to be able to make changes obviously uh number two was that it should have a low cost of ownership so low running costs so that we can afford to make the changes we we need to make. And that also kind of hints towards it's going to probably be open source, which will which means your code becomes portable. You can uh use numbers of different third third parties and develop quite interesting relationships.

Speaker 2: Number three was that it should be managed by the team who operates it, which sounds like obvious, but I think sometimes in a complex organization like Oxfam or when your tools don't necessarily work properly. Decision making can sometimes fall to IT departments or senior budget holders. But I think web teams need to make decisions on web teams. sites and then there's a whole other webinar involved in the role of web teams. But yeah, that's for another day. Number four is that your tool should allow you to develop relationships with third parties who have a culture of collaboration. So for some people that might be pair programming. For us, we've we um learned a lot from Torchbox about different user testing techniques.

Speaker 2: And I kind of think it's important not just to think about the technology, we're trying to think about the partnerships around it and doors it would open. So but all those four principles, basically the overarching theme is that we need to be able to react. We need to be able to react to changes in the environment, screen sizes, or um, you know, user behavior changes. And because the only I think that's the key attribute of a good website is just how it reacts to change. That's the only thing we know it's going to happen is that change, and we all know that now. now change and was it was it I don't know if it's known unknowns or unknown unknowns. It was one of them. We have to react to events all the time. So we might launch uh last week we launched a petition.

Speaker 2: In response to the government's 0. 7 % paid budget cut, we've had um we've had a pandemic, so all our shops shut. I mean no way we could have anticipated that. So uh yeah, we need these are the sort of things we need to be able to react to. And I apologize for quoting Donald Grant's But I um I did find myself when we were doing this in 2019, uh Brexit was at its zenith, and I was I found myself going around Oxfam talking about taking control of our website and unleashing our potential, which just parroting some of the things I heard. But actually that that is like another bit we need control of our tools and which we didn't have. So any new tool we'd have to you know we'd have to be able to bend

Speaker 2: it to our will basically

Speaker 3: okay and with these these four principles in mind it'd be interesting just hear a bit more about um which CMSs in particular you you homed in on in the early stages and sort of who made it onto the shortlist.

Speaker 2: Yeah so that that gave us a shortlist of um WordPress , Drupal, Umbraco or Umbraco, I don't know how to pronounce it, and Wagtail. And so if a CMS met sort of fell into the framework of four principles, we then had five new criteria, which the five S's were security, support. speed, something, no, uh simplicity, which is very important, and Salesforce integration.

Speaker 3: Okay.

Speaker 2: So we were moving towards Salesforce there at that point. So integration with Salesforce was a big selling point. Now I think at this point it's quite hard to articulate the pressure we were under to move fast. So we um because our system was collapsing around our ears. So um sorry, uh what we chose to do was to rank the CMSs in in in order and then pick on and then we wanted to um we so we luckily we had experience of all of these and we did some research and we installed them all so we ranked them and then we chose to run a proof of concept on the favorite and kind of work down on the understanding that if it didn't work, we go down to the next one. So what we definitely wanted to do was to try before we buy.

Speaker 2: And The clear favorite in that list was Wagtail. And I know this isn't a sales pitch for Wagtail, but I I should tell you the reason, I'll list the reasons why we liked it. So it's very strong on security. It has a very good UI, which I think we're going to show later. It's lightweight, which makes it really fast, and it doesn't see it doesn't have any redundancy, like for example, WordPress and those redundant database calls, whatever. the place. And it was just refreshing to see something that was completely unopinionated and flexible. It's like basically when you first install Wagtail, you don't see very much, but it's like you're But very quickly you can get it something quite exciting to happen. So it's like you're opening a huge box of potential. And it gives us a very high ceiling.

Speaker 2: And I I really I I just need the CMS to get out of the way because I think our content is what we need, what makes our site a winning site. And I'm probably not going to be seduced by fancy. features and bells and whistles. So uh so yeah so we embarked upon this project where we we picked off part of our website uh which I think we're going to talk about later. Yeah, so I I can't really tell with people which tools are the best for them. It's up to their individual circumstances. But my one piece of advice would be that If it is possible, try before you buy and work on a genuine project. So pick off part of your website that isn't working very well because you're not you don't just want to replace like for like. Try and improve part of your website.

Speaker 2: What I didn't want to do was invite sales teams in to pitch, potentially overpromise and not deliver, because like we've done that before. really work. I just don't think traditional procurement processes are suitable for websites because websites aren't commodities and this is quite an important point which I've some I fail to communicate I'm gonna try and do it succinctly. Um when we're building our website, don't think of it as a capital asset, think of it as an operational thing. So we're not really building a thing at all, we're not launching a thing, we're kind of building a way of working and the content management system needs to just oil the wheels really. Another draw quickly was the quality, another draw of Wagtail was the quality of

Speaker 2: contributions from the community. So there's a community of sites with quite similar requirements to Oxfam. websites of a similar ilk, so often public sector or charity, and it it just seems to be that because it's quite niche, it has a kind of high bar for the code. And um We already, for example, have started uh we've benefited already from some of those contributions and actually Oxheim America I forgot to mention this, we're using Wagtail at this time and they are the people who first put us onto them. So onto it. So it came with a very strong recommendation.

Speaker 3: We actually have a question from Oxfam America from Bill Tacaso. So thank you for sending this ahead of the session. And he's just curious to know how their project, how the Oxfam America project and its results influenced the Oxfam GB process.

Speaker 2: So what time is it in America? That's a pre -written question.

Speaker 1: Yeah, he's not actually on it today. He just sent it ahead. of time. I'll send them the recording.

Speaker 2: Because that means I can s I can reveal I've got a sort of secret NGO Cross Rocks on America. I think I've coveted their website for quite a long time. But that so what so Oxfam, I should explain, is a confederation of lots of Oxfams. Oxfam GB is obviously the biggest one, but Oxfam America is is um is it's obviously big in America. So what happened was we luckily share a look and fear. We have like a global brand. well we did have so Oxime America were able to just hand over their code base or give us access to their GitHub repository which meant we gave us a head start on the design sprint we ran, which was a proof of concept for Wagtail. And that was obviously very helpful and very thankful to them, but it also proved the point

Speaker 2: that open source code can reduce running costs. So that was free to us and we were very lucky they did it for us. But it got us up and running and it meant that we didn't have to jump through so many kind of administrative hoops within Oxfam. And we could get something done very quickly without getting stuck in the machine. But it also kind of opens the door potentially to sharing code further down the line between Oxfams. There isn't really a plan to have a central Oxfam website that. kind of supports individual oxides but you could see that if we were all using the same system and it was an open source system that could be potentially something that we might do in 10 years or so So yeah, that was great.

Speaker 3: And you mentioned open source there and a few sort of benefits it brings with it, but particular reasons that you were leaning towards open source

Speaker 2: Apologies. Yes, so I work for a charity obviously, and we obviously need to keep running costs down. And I often find myself creating pages that say things like £30 can buy a shelter. And I don't and because we want to keep our running costs down, we want to make sure as much of the money that uh our generous donors give to us helps people who are vulnerable. And I don't I just don't think I I personally find it quite hard to justify that money going on a license which is just purely for the privilege of using someone's software unless there is a very good reason to do it. And I just can't think for a website like mine of a requirement that is so crazy that it needs um proprietary systems.

Speaker 2: So I would at least default to a first look at open source and if nothing worked then pot potentially use a proprietary system. But I just think it's just It's just I'm on a very high moral horse here, but um and I don't mean to be. But I do remember once going to a um another training session at a large content management systems offices and looking out of the window in the coffee break and seeing the yacht which the CEO who was a few offices up used to commute to work and that that kind of gave me pause for thought. But it's it's not just about cost, it's about the many other benefits you have. So as I said before, your code it becomes portable. You can um work with a number of different partners. You could recruit your own agency , your own um developers.

Speaker 2: You could have a hackathon if that's your fashion thing um but again as i said before benefiting from the community so we we have benefited from something Mozilla have already done so that's in the first two months of of the of using wagtail. We we also had a very painful upgrade with cyclore as I mentioned before. The upgrade process for Wagtail is like poles apart. So I get invited to a webinar like this where new features are announced and they're carefully curated and tested by experts in the community. And then the upgrade involves no downtime and has meaningful enhancements. So it might be an accessibility toolbar, might be the last one I think had the collections for images that became hierarchical.

Speaker 2: It's good. It's like a Christmas present. great um and when we talk about open source it also gives me a chance to use the words false dichotomy because makes it sound very clever But it is a false dichotomy. You can't put all in 2020 all the open source tools in the same basket because they're all very different. And I would encourage people to look at them. before looking at very expensive tools that do the same thing. There. I've got to get off my moral high horse now.

Speaker 3: Um and did did the sort of um the open source um you know the decision to sort of uh move in that direction present any challenges at all?

Speaker 2: Yeah. Yeah, so the obvious one is security. So people have traditionally have concerns about security of open source systems. And we've got quite a strong security team at Oxfam. um and uh to be fair they're quite open-minded uh but obviously rightly cautious about using a content management system that they to be honest that never heard of. So I had to reassure them and we spent quite a long time uh building a case which involved um I did it in a number of ways. So I I remember ringing round the community getting um getting uh testimonies from people, for example, from the I think it's the Electoral Commission of America and I wrote to the National Cybersecurity Agency.

Speaker 2: as well. But another thing was to kind of explain that Wagtail is underpinned by a quite a robust framework, the Django framework has built-in protections, for example, against cross-site scripting attacks. They 're not an expert in this by now, have access a lot of acronyms, CR, CSRF, XSS, all these things. Anyway, it's great. And there are also many very various like impartial directories of security vulnerabilities logged against different systems. I think it's called the CVE database. And Django comes out of that very well indeed. You can compare the history of different systems. And that's so that gave us some independent metrics of how secure it was.

Speaker 2: But obviously security is an ongoing concern. So we have to had to, we brought Torchbox's developers in to have a kind of any question on answered session. So to make sure that code practices were adhered to and that we were comfortable with the code that we were going to add on top of Django within Wagtail. So we had this kind of open invite within Oxfam Any questions answered and then that was followed I think by a security interview as well. We've also done pen tests, we've done two pen tests, one on our pilot that we ran, which had a couple of minor um issues which is to be expected, but then the did a pen test on the large on the wider websites, which which included the donation system, and there were no errors at all, which is unprecedented, at least for Oxfam.

Speaker 2: And um I think we thought that there was a problem with the pen test. test but it was so good. But we we regularly run scans on on a monthly basis we run scans and We recently had a PCI audit uh and that went very well as well. So I think we've pretty much covered security off. But it did it does it did take some time. But I think we demonstrated that we've I think made the right. choice. So

Speaker 3: quite a few sort of steps to work through, but it sounds like they did the trick in alleviating those concerns and sort of giving the wider team the confidence to move forwards. Cool. And then I know you mentioned as part of the sort of decision-making process, one of the first things you did was take part in a design sprint. And for anybody joining who's not familiar with design sprints, they're an absolutely fantastic and sort of tried and tested way of validating product ideas in a really short amount of time, usually about five days. And the concept came out of Google Ventures championed by Jake Knapp. And basically you start on day one on the Monday where you establish your goal. And as a sort of as a team, usually sort of bringing in Waiber

Speaker 3: members of the organisation, you map out your path to achieving that goal. And then going into the second day, you sketch out a ton of ideas, everybody's sketching, it's loads of fun. And then you start to as a group home in on which of the ideas you want to take forwards. And then you actually create a prototype, usually a sort of interactive prototype, and then on the final day you test that with real users. to sort of come back and validate your idea. So Theo, it'd be great if you could just tell us what you chose to focus on for your sprint.

Speaker 2: Yeah, so the the subject of our sprint was our volunteer recruitment process for Oxfam shops. So Oxfam has about 600 high street shops around the country More than Sainsbury's. Well at one point it was more than Sainsbury's. And previously, although online, the the um The shops are all run by volunteers and the the process to recruit volunteers was involved people going to our website, downloading a Word document, filling it in, printing it, going to the shop. Queuing up, probably being told by the manager to do it again because they've done it wrong. It was like the worst user experience you could design So we thought that that, as I mentioned before, was the area of the website we would pick off and improve with this

Speaker 2: to try on a system. But so the design spirit was to rectify that, but there was a hidden agenda which was to test not just the technology but the relationship and ways of working with TorchBots. So for Ox it was really good and for Oxfam it I think And this is a bit of a caricature, but it is a very different way of working because we often, if we've got an issue like that, we do a very top-down project where we'll have a creative brainstorm, come up with a slogan and then a photo shoot and do more advertising. But this in contrast was kind of a bottom-up thing where we had we focused on user requirements. So we I remember we'd our office had had a horrendous flood and we were out in the office for several months and I'd spent I've taken advantage of that and done a little tour of Oxfam shops, interviewing shop managers and volunteers in backrooms.

Speaker 2: And we also had, we invited to the first day of the sprint someone who'd worked in our Batsley Batley hub, which is a distribution centre. So we kind of built personas , went through several steps, storyboarding and prototyping, and then rented a cafe because we still didn't have an office and did some user testing And that went very well. And I remember actually quite distinctly that on the next day, the last day of the sprints, we were going through the videos of the user testing, looking at how we might refine it. and how we might refine the form we bill. And I was thinking we were gonna come up with a list of jobs to do for maybe to take it forward in the future. But I hadn't appreciated that there was a like a speakerphone in the middle of the table and then in the next room someone was listening to our meeting and um

Speaker 2: making the edits live as we as we spoke and it was it was just we'd refresh the page and the changes we made it was amazing. Like, yeah. Anyway, so uh the the the I should also mention the finished prototype did connect to a Salesforce sandbox. So that was the first time I'd actually seen Salesforce in action and that was one of the top criteria for trialing CMS. So that was brilliant. It was one of the best things I've done actually, this design sprint in all my time. working in the web.

Speaker 3: That's great to hear. And what did you then decide to do based on the outcomes of the sprint?

Speaker 2: Uh yeah, sorry. So um we what was good about it is it gave us a ready-made thing. It was demonstrably good. It wasn't quite live, but it it clearly had great promise And it's very likely not just to recruit more people, but potentially lower our budget, our spend on advertising So, and that kind of proof of concept is something I would definitely recommend because it lets you apply UX principles to like management decisions. So if you think, what does my manager value? He values money, which makes him sound like a Ray Craven person. My manager is amazing, lovely chap. And But he does care about money. So saving money is something he likes.

Speaker 2: And this meant that I could go to him rather than with a request or something, but with something he he really wanted. So the next steps were then to like build a case to make it production ready. We did all the security stuff, ran a pen test, as I mentioned before. And then we did a launch as a kind of pilot and within the first month we had had around a thousand applications, which is amazing for us and uh we were able to not just reduce the advertising but turn it off and it's like the you know best conversation I've had with my manager It's marvelous. So yeah, really good. But that gave us a lot more momentum to build the wider, to go all in and do the full website. It's

Speaker 3: a fantastic result coming from the sprint and just to be able to bring such value to your volunteers and the organisation. So it's great to hear So then I guess as the title of this webinar rather gives away, decided the plunge and migrate to Wagtail. I know over a year ago now we started working together on your new website. And we're just so, so excited to see the first iteration go live in September. But sort of casting casting wines back to the early stage of the project, and we spent a ton of time um getting to know your supporters and really trying to understand and home in on on on what they're looking for.

Speaker 3: So it'd be good to just sort of hear a bit more about how that these sort of insights and and research help to shape the direction of the new site.

Speaker 2: Yeah, so in the past the site was, and I think this is quite common, that the website was a reflection of the organisation's internal structure. So every team would have a page It became a like a directory of Oxa. And I think we kind of understood in you know 2020 that was wasn't the way to do things. So we we did embrace a user-focused approach here. So we did a long discovery phase, as you mentioned. And the first thing we did was to establish a user-defined site map, so the information architecture. So this is to involve avoid like the endless debate about what goes where and conversations about X can't find Y, where can you move it here and there? Anyway, so um this is based on the premise that every user of our website, every single person who comes

Speaker 2: has a task in mind when they arrive. So it might be to hopefully donate, it might be to complain or to find their local shop, but it's it's probably not going to be read Oxen's latest news or, you know So we went through this process of establishing what those tasks were. This is the top tasks process, the Jerry McGovern thing, but we did it ourselves. So we did lots of interviews with public-facing teams. We did we've got supporter panel. We kind of used that. We I remember sitting in cafes in Oxford just surveying opinion, trying to find out why people would come to our site. So we ended up with a list of about 150 tasks which we whittled down and then we did lots of closed and open card sorting sessions and uh

Speaker 2: We came up with quite a robust navigation system that I think reflects not Oxfam but the needs of its users. And I think building A website around users is a good thing to do, but a great thing to do is to involve users in creating it. And I think that gives you it kind of future proofs it. So another good thing was we had the corresponding people on each side. So on the agency side and our side. So we had um because Well, it became very useful with pandemics, etc. Everyone being working remotely, but we had a delivery manager on both sides. Ours predominantly was wrangling people trying to get the right people in the room which was good. There was yourself product director and myself product owner.

Speaker 2: And we have a technical design architect as well who works with Torchbox developers because we do the hosting. So there's a lot, it was a real team effort. and work really well. We also had senior buy in from the head of Oxfam, Danny, who is our leader, another mashing chap and um uh so he gave us kind of the vision for the character of the site early on which is very human trying to get the Oxfam voice out so we've got a lot of first hand accounts from people we work with on the ground and that so you're kind of greeted by um people rather than the kind of corporate voice that was great

Speaker 3: Was there anything else that you think worked particularly well? And then also on the flip side, with the benefit of hindsight, anything that you would change if you were to be starting again next week?

Speaker 2: Yeah. This is a job interview question where I'm going to talk about the thing, the mistakes, and present them as challenges that we overcame. But we had uh so the whole thing was beset by challenges. So even from the very first day of the the um design sprints, as I said, we had a flood. So we were out of the office remote working before it became fashionable. And now we all are. So one of the key issues there was that I I went on furlough, uh crucial point, which as did a number of my colleagues and that exposed I think a lack of documentation on my part which actually I don't I don't think that's quite the case I think it was a lack of telling people where the documentation was But thankfully we'd established kind of principles to work through early on.

Speaker 2: So we have design sprint principles. we've got the sustainable technology principles I mentioned. We've got OKRs objectives and key results which were success metrics that were established early on and that kind of meant we could carry on without disruption even though there was quite a lot of uncertainty. But you know, if we're talking about actual mistakes, I don't think there were any clangers because we built on a quite a solid foundation of user requirements, as I said And we we the way we broke the project up mitigated a lot of the risk. I remember so a website is about making mistakes, it's about ironing out wrinkles because we're optimizing. So that is the business of a running a good website. And that, yeah, so we're we're not treating it as a monolithic

Speaker 2: project with a beginning and middle and an end, then we have to have the flex to make mistakes. Mistakes are inevitable. We're building a way of working, not a thing. So that's my job interview on

Speaker 3: Got the job, perfect. Um no, and I would just agree, I think having Um to your point, I think having yourself, and I'm not just saying this because you uh agreed to do this webinar, um having yourself as a sort of highly engaged product owner um from the Oxfam team. um was hugely important I think um to the success of the process and um just in terms of being able to feedback really quickly make decisions um while sort of involving you know the the relevant stakeholders and teams um at at the right points And this also meant that we were able to run a pretty intense jaw track schedule where we had design and discovery sprints running for a period of time alongside the build sprints.

Speaker 3: which you know ultimately it gave us you know a great deal of flexibility but meant that we were launch ready much much sooner um which was you know I think I think worked well I know we're running out of time a little bit, so we'll we'll just rush through the the last couple of questions and then hopefully still have time for you to show us around the site quickly. So I think As um, you know, a lot of uh product people find it can be really tough to define the MVP, even you know, with the research at your fingertips and The term MVP itself can can be a bit contentious at times, but could you just talk us quickly through this sort of approach that you took to prioritisation?

Speaker 2: Yes. So the quick answer in interest of time is that our priorities now become user requirements. So the user's priorities become our priorities. And at the top tasks we mentioned should form the basis of our work. So we found in the top task thing quickly that people are very interested, and there was a clear winner in this. um process. People are more interested in oxams like bread and butter work, the impact of our work in in the world. Whereas we tend to focus a lot internally on marketing campaigns. things people just want to know the basics um and so we kind of wove that into our business requirements and into our donation journey So that will continue, I hope, to be the

Speaker 2: underpin the prioritization process when we look at what people really want. So we have a we have a public engagement strategy that actually is very helpful in that is user focused. It talks about tailoring our communications to the needs of people and allowing people to get involved with Oxam in any way they like. So we have a lottery, we've got lots of events. etc um but crudely these fall into three categories time money and voice so time is volunteering voice is campaigning but um the kind of first among equals is money, obviously. So we uh yeah so refinements to our donation forms have already actually happened um and so they they they tend to be the priority but um I think it's helpful to launch an MVP just because it can

Speaker 2: helps communicate with my colleagues that we are growing a website. We don't launch websites, we grow websites the sound bike for you.

Speaker 3: And so lastly then um now you've sort of launched your first iteration and uh continuing to enhance and then grow and build the site. Just be good to hear how it's going and how you're tracking against some of the key goals that you established that you wanted to achieve.

Speaker 2: Yes, uh very quickly. So all the feedback I had actually when the site went live is 100% of it is about what it looks like, which is not what we report. It'd be great if I could report on how much more beautiful I've made it that month, but that isn't our case. KPIs are tend to be conversion. So we have our initial conversion rates went up like big spike as soon as we launched. But since uh since we launched we've We've improved them more by we looked at the postcode validation on iPhones and that pushed it up by about two or three percent again. Um we used to have a lot of manual processing behind the scenes for donations, and that's now modernized, that's gone. We've found that integrating in memory donations, where you where you give a gift on in memory of someone you love

Speaker 2: who may have died, we found that has gone up. But and that I think is because we've now integrated it into our form, whereas before it was like an in its own little silo. The the challenge for us now is that to in order to be GDPR compliant, we now have a consent, a cookie consent banner, and we found that only about 30% of people are opting in to analytics cookies, which is lower than I think we anticipated. And so, but now we're quite relaxed about it. Well, I'm quite relaxed about it because I consider it as a we're now sampling our audience. So we're not talking about volumes. We can get that kind of stuff from the CRM, the volumes of donations and interact in engagements but uh yes it was just sampling but that that is a challenge at the moment

Speaker 3: That's amazing. Thank you, Theo. Would you be happy to just dive into a really quick demo and show us your site in action and then hopefully we'll still have the last 10 minutes or so to address the many questions I've seen bubbling up as we've gone along.

Speaker 2: Let me um log in quickly.

Speaker 3: Thanks.

Speaker 2: Hope this goes well. Hang on, where have you gone? Uh share screen. Can you see my screen? Is that working?

Speaker 3: We can.

Speaker 4: Yep, we'll be right.

Speaker 2: Here we go. So this is uh one of our Donation forms. Previously we had our donations lived in a separate kind of platform, but we've brought them in, which as I mentioned has improved our conversion rate already. We uh we find we found what we did in the past, our approach tended to be to it put as much information in these pages as possible, um, but we've slimmed that down because we found that people uh People get their news from somewhere else. The user already knows there's a coronavirus issue and wants to come here to give money. So this is a thing about people arriving with a task in mind, and we need to recognise that. So I'm just going to show you the the um The

Speaker 2: back end of this. So I'm going to click the little bird here. That gives me access to my cut tail and it lands me on the right page. And this is the behind the scenes. So we have We've commissioned these tabs, so we've these are built for our to our requirements. And the the little form widget you see at the top is controlled by this tab. And I'll just quickly add something thing and just show you how quick it is. So I'm going to add the ability to give uh regular like a monthly direct debit as well as a credit card payment. I'm just going to make up some amounts. And then I'll save that. And I'm gonna preview it. So you can now see we've got a monthly option

Speaker 2: has appeared, and we can now within like what was that, 20 seconds, I can now. Do this. I don't know how long that would have taken before. I could also show you something else which I think is a a big um is a really great feature of Wagtail is something called Stream Field. So If I want to add a component, I've got lots of options. And again, a lot of these are commissioned by us. And you can build pretty much anything you want. So there's some standard ones, power brows, headings, images, etc. but there are also some more complex ones. So this one is a donate widget. I'm just going to put in. You can then choose what's called a snippet. These are reusable items that we've built elsewhere we can use across the site. And I'll I'll pick this one, it's probably the wrong one, but

Speaker 2: not want to go live, so it's fine. And I'll just show you what the this this snippet contains so here I've got um I've got uh all the details I need to populate all the content I need to populate that and I'll I'll now show you what it looks like So we've got the monthly thing still there. And we've now got this donate widget. So we can use this, we probably wouldn't use it in this page, but we we can use this throughout the website. To allow people to kind of jump into the donation process. And if you fill this in, you would end up on like page two of the four. So that kind of makes the user journey much more efficient. And these this uh we can

Speaker 2: we can it's it's brilliant. We can just if we want something, we can have it. It's just so flexible, it's marvelous. Um There you go, I'm gonna stop sharing now.

Speaker 3: That's great. Thanks, Theo. Um and also just thank you so much for sharing um such great insight into the journey you've been on. over the past year or so. So Lisa, looks like we've got some questions. Where do you want us to start?

Speaker 1: We do have some questions. Let me so like I said before, any that we don't get to answer, I will follow up in an email with them because we have had quite a few which is great. So the first question we have is from Stephanie at Beet Eating Disorders. What have been the key benefits that you've seen since moving to Wagtail? Um better engagement, speed, flexibility What would you say?

Speaker 2: Uh well one of the top um top ones is running costs. So running costs uh before as i mentioned before we need technology that's sustainable and we can really afford to do anything other than try and keep up with bugs before So now running costs to write down. And when we launched the website, here's a little insight into my life. It was my birthday. Haven't told anyone that. So I went to get my lunch and I upgraded to Sainsbury. Not Sainsbury's Waitrose. Upgraded to Waitrose. And on that day, that was the first day ever that my lunch had cost more than our website. So the running costs have done the opposite of skyrocketing. We've gone right down. That's the one thing. The other is the speed at which I can make pages. Previously

Speaker 2: it would just take it would be very arduous to create a page and now it's super fast. So I know I can I can even do it within in like a team's meeting. I can be kind of people can describe what they want and it will be ready by the end of the meeting. People are amazed. I think also the It is a struggle sometimes to get the organizational rituals to change to kind of focus on users as opposed to business requirements, but I think we are getting there. But in terms of like analytics, the conversion rates are up. So it's ever in we've got more people going from our homepage to our online shop than we had in the past. which is a key thing, despite the redesign maybe making the online shop less prominent, it's now clearer and it kind of makes more sense in the position it's in.

Speaker 2: So Yes, they're the key things. But if you I mean we just drop me an email and we can chat more if you want to talk more about it.

Speaker 1: Thanks, Leo. And we've got a question from Claire at the Marine Conservation Society. Society who said, was it difficult to persuade the board not to go down the traditional procurement process route?

Speaker 2: Yes. Yes it was. I think it does help though that the tool is open source because it doesn't cart the tool itself doesn't cost anything. So you kind of there's you know That helps. Also it helps I've got a very supportive uh management team. But yes, it is hard, but it's well worth it.

Speaker 1: Brilliant. I'm glad to hear it. We also have a question from Nina who asked, how long had you been using Sitecall before?

Speaker 2: I think it's very nearly 10 years. So we did in pre prior to cycle we didn't have a content management system at all, which is I think was even then a bit odd. Yeah. So Yeah, it was about 10 years off I think that was quite a lot. Many years too long.

Speaker 1: And how did you handle migration from the old site to the new website? Said at diabetes UK?

Speaker 2: Uh yeah, so I think it's listen to a good question. So we didn't migrate. I think that's important. So websites do tend to grow organically over time. Um and I just don't I think if you're going to launch a new website. it it it's time to have a good look at your content see if it's it's unlikely I think to to still work so I think it's time to take a fresh look at what you're doing So we didn't really migrate. Our site used to have about 5,000 pages and now it's got in the low hundreds. I think we need to make the funnel a bit smaller, funnel people to their you know to their goals more easily

Speaker 1: Brilliant, thank you. You ready for another? Sorry, it's like quick fire questions actually. Handling them well, you're batting them all back, which is uh we've got one from Will Churchill at the Esme Fairbown Fairbairn Foundation And he says we've recently gone from a. NET framework site to Wagtail, which has been great for us in terms of usability. What was the biggest benefit of Wagtail that your team has taken advantage of? Did you answer that one already before? Is that something?

Speaker 2: Um the team's taking advantage of is I think my team is have found just the speed, speed of building pages is a relief. That's it really. So we had I could my team uh is made up of three people and we've kind of There's an editor and two kind of producers. So we in the past would have created WordPress sites, HTML, JavaScript. etc but we're not fully fledged developers so we use uh torchbox for development but the plan is that we will be um we'll be training and potentially recruiting our own developers when this uh horrendous

Speaker 2: world event has has stopped and our shops are open again. Yeah, so but for for us at the moment it's speed of creating pages

Speaker 1: Brilliant. You kind of answered two questions there as well because there's been a few queries about your internal team and how you manage the development between Torchbox and Oxfam as well. But I might follow up with that one. We've got one who has asked about could you explain open source technology versus proprietary for the benefit of non-techie people?

Speaker 2: Uh Tom might be better to explain than that. He's probably done it many times.

Speaker 4: Sure, so Uh I mean open source means a few things. Perhaps most importantly for uh for some people is that it's free. So open source software is is software that has uh has a particular kind of license, and there are a few different open source licenses, but the the things that make that they will have in common are that they are free uh to and uh that uh you can adapt them So um anyone could can take Wagtail and build their own site on it or even build their own service using it and call it something else. And in fact, that's already happened and uh they don't have to to to pay the creators. And um that also means the the openness of it means that although it's not always the case, it usually is the case, and this is true with Wagtail, that uh you have many contributors.

Speaker 4: So instead of having one agency that's in charge. um like uh Adobe or the people who make Sitecore or something like that, then uh you have this wide community with people contributing and and making it better from all around the world. Probably things like Drupal and WordPress are probably the most famous examples of open source content management systems.

Speaker 2: Yeah, and kind of the knee jerk. reaction to that to hearing that maybe for the first time is that oh it can't be secure because everyone's got access to it. But actually the fact that many eyes are on it means that bringing like significant security issues just aren't a problem because they've got so many people kind of Is that right? I hope so.

Speaker 4: I think it is right, and it is a bit counterintuitive at first, and it's something that people might feel nervous about because uh because the code for the platform that's the that's underlying your site is is open source. But generally the the outcome is that more eyes means more security. And in fact, something I'd encourage And at Oxford, I'm not ready to do this yet, but I I do try and encourage our clients this to open source their actual websites so that the the whole the code for the whole site is available. And um that means partly it's kind of good for the community because it means other people can can take the bits that of of your site that that are gonna you know, help them speed it up as well. But also the you may even get other people contributing to your to your own site. And we've seen that quite a lot in other cases.

Speaker 1: Thank you, Tom and Theo. I think we've got time just for one more. I'm going to squeeze one more in for you. So um based on the top-down evaluation approach with Wagtail at the top, did you not then evaluate any other platforms due to Wagtail ticking all the boxes.

Speaker 2: So we had well the we had kind of some experience with the others already but um And we kind of and we'd also worked with a number of agencies because we'd had this issue with Sitecore , we had this approach where lots of um lots of small things loosely joined. So we'd we used WordPress, members of my team had used Drupal before, and we worked with a number of agencies, as I said. So we kind of felt that by proxy we'd run trials already and so we did a little bit of a post hoc kind of uh review um but but um speed was of the essence at the time and wagtail was a clear favorite um and to have the architects of wagtail just down the road was also great. Um

Speaker 2: so yeah, so we didn't have very long.

Speaker 1: I've just got one more. I'm just going to squeeze one more in, sorry. We've got one from Andrew Holgate, who is from the World Food Programme, who said how much of the success of the project was due to Wagtail itself and how much was the vendor chosen for the project? is design, development and implement implementation implementation. Uh

Speaker 2: I kinda think it's hard to separate them. Yeah, I don't think we can. I think I don't know. I can't say. I'd like to think I was involved as well. It wasn't just at all in the agency. But no, I think it's hard to hard to um separate them. I do think uh yeah, I can't. I can't say.

Speaker 1: You can just say both that's fine.

Speaker 2: Both, yeah, both. So yeah.

Speaker 1: So we're at 11 o'clock. So thank you everybody for coming and joining us. Um hope you've enjoyed it and found it useful. And as I say, I will follow up with an email as well for anything we've referenced and any outstanding questions as well. And thank you, Theo.

Speaker 2: Oh no, thank you.

Speaker 4: Thank you, Theo. Thanks, everybody. Thanks for coming.

Speaker 3: Thank you very much.

Speaker 2: Cheers.