 Yn ymlaen, yna'n gweithio. OK, ddweud. Hefyd, wrth gwrs. Fawr i'n gweithio. Ddweud i'n gweithio. I'm Emma. I'm from the University of Edinburgh. I'm going to share with you today how to work with your editors, the co-design, a Drupal editorial interface that supports good content design and winning user experiences. So, here's an outline of my talk. I'm going to give you a bit of background context about me, what I do, and then I'm going to dive in to looking at editorial interfaces and what they do and how important they are in supporting good UX and content design. I'm going to think about reimagining the editorial interface and talk about co-designing that, working with editors, understanding what editors need and then prioritising features in the interface to support those needs. I'm then going to finish up with some tips and reflections working to align design and development within an agile framework, which supports co-design. As I go through my talk today, I've referenced quite a few different resources and books, so I'll provide a resource list at the end and then we'll go into Q&A. I'm a content designer, user researcher, stroke UX specialist, who's also really enthusiastic about service design. I work in a design and development team at the university. We're a central information services team at the university. The university's been around a while, it has heritage, founded 1583. These days we support 45,000 students, we have 15,000 staff and we have 21 what we call schools. These are subject areas, departments and three colleges and various other institutes and departments as well. I've been the UX lead on our upgrade project from Drupal 7 to Drupal 9 to migrate all the content on our site and to engage our editors and bring them along on this journey. Key to that was the editorial interface. Still is the editorial interface. Before diving into that, just to give you a flavour of the university web estate, we're looking at several million pages and we have more than 600 sub-sites and our editors are a devolved community, 300 plus editors. Many of them very highly intelligent, many of them with academic background so that's kind of what we're looking at and the content that they're creating across the web estate, who's looking at that? A key audience for us is prospective students because they're coming to the university website to do various tasks and this is why content design of our website and our web pages is so important because it's supporting students, prospective students making decisions like am I eligible to reply to the university, is it right for me? I want to fill in a form, I want to send in my application, I want to browse what the university has and understand if it's right for me. So typically how those web pages come into being is through this sort of model so those editors I talked about they plug in the text, the images of video into the CMS and out come the other end, the web pages and how we deliver our Drupal 7 offering to that editor group is typically the central team in which I work, produce the editorial interface we deliver that to them, we have a service management team that design a training course, they have to complete the training course to be able to use the editorial interface to publish content, after that they're kind of free to do that publishing themselves we have obviously support calls so if they get stuck they can come and contact us. So going into this project, this upgrade as the UX lead I could understand how important it was to bring editors along with this and I wanted to understand from their perspective how this process was working for them this was like in Drupal 7 and here's some of the things I've found so I was asking them about the training and they were going, there's just so much to remember I do the training one week I have to update content the next, I've forgotten everything when I was talking about asking them about the system they were going well it wants me to work in this way it is making me do this I would really rather work this way but it's making me work this way and talking about the support side of things a lot of the time they were saying I don't bother raising a support call I've got to work around and all this made me think they had quite a negative relationship with the interface and moving to Drupal 9 it made me think have we got an opportunity to do things differently and do things better here so could we get to a stage where we had an interface that supported editors in their natural workflows but also led to that kind of overarching goal of good content design and good UX so this is what I mean by reimagining the editorial interface what if instead of it was something we built for them we built it with them so what if instead of it was something we they felt restricted them it actually empowered them and what if it was something that they didn't have to learn how to use or feel it was a barrier to learn to use because they had already been invested in the development process and they knew the system well this is just a visual of that kind of reimagined editorial interface so as well as the text and images and videos going in there'd also be ideas and mechanisms going in and that would kind of I guess serve as the oil to lubricate the system keeping running and being more sustainable so you might say nice idea Emma how are you going to get there well how I thought about getting there was something I learned about in my service design learnings which is co-design so what's co-design so co-design recognizes that when you design a service or a system so in this case our editorial part of our CMS there's not only expertise to feed into that from the people who operate the service so people like me content designers developers and the team that I work the operators there's also expertise from the service users to be captured in this case the editors and being able to harness those two types of expertise in this case and put those together really helps to build a service that's got mutual benefits across the board and much of what I've learned about co-design comes from a book K.A. McCurch's book Beyond Sticky Notes it's a fantastic book and in it they outline these six co-design mindsets and there's two that really resonated with me in the work I've been doing which is elevating lived experiences and valuing many perspectives so thinking about elevating lived experiences that's what I wanted to get from editors understanding how they naturally worked with this interface and depending on where you are if this is something that's of interest to you if you want to do this you can go in at different levels and it obviously depends on this spectrum how well you know your editors from the beginning if you have a pretty dissociated relationship with them you'll need to reach out you'll need to kind of have ice breakers and one of the best ice breaker activities is a top task survey this has been devised by Jerry McGovern and it basically lists all the tasks you can do in this case with the CMS and it gets those people using it to go can you rate these can you tell me your priorities so from that you get a real clear picture of what the priorities are for those people within the system once you've broken the ice you can get into more active listening and this essentially means approaching editors and asking them to use the interface and find out how they work and get them to talk through like what they're doing and this really to get this to work really well you need to have an element of trust because you don't want them to tell you what they think you want to hear I read the manual and then I just complete the pages because you know that's not the truth so you really do want to get to a stage where you're listening to the hacks and the workarounds and hearing it all and yeah to kind of encourage that process you have to be quite open with your own work as well so from our perspective like within the team as we were going through this upgrade and making sure we're being open and inviting them in so maybe sharing our prototypes which was really scary but it was good because we got to see how they would naturally interact with them and we learned from that and we started to build that relationship and I'm not going to lie it felt like this when I started this project learning from editors like the head exploding emoji and many of them who knew what I was doing in the work with this upgrade they were ready with the features that they wanted to see in the interface so carousels, I kind of have accordions I want expanding feature boxes and you really do have to hold your nerve at that point I would say if this is something that interests you and you want to go through this process because it's achieving that deep understanding takes time and this trick time so this is a concept known as mental model mapping what this basically does is a task that you choose one that maybe all the editors are doing so in this case it was producing a page about a course standard thing that all our editors do across the university we have a degree program they want to put a course page together about it this breaks down every single task that's involved in that production so what you can see there, I'm going to zoom in on this in a minute, the yellow stickies are all those tasks stickies below are the opportunities for co-design so I guess the top level is the editor expertise the bottom level is like my expertise where that can come in so let's see how that plays out so here are four stickies a typical sequence of events of editors going through a process to produce that page clone an existing page take a bunch of text that they've probably got from an academic colleague so it's going to be hundreds and hundreds of words paste it in realise ah that's a really long page go to a accordions shorten it down and then think I need to get this page noticed I need to link it to that page I need a button here so that was something that's happening and they're doing so I looked at that and I was thinking okay so what the underlying needs here and this is a key part of co-design is understanding what's behind this so the cloning an existing page the reason for that is because a blank page is the scariest thing ever to some of our editors because that requires them having to think how they're going to structure it so maybe what they're looking for here is not a copy of a page it's actually a way to structure this particular sort of content they copy and paste things standard thing that you'd find in a CK editor but the way it works now is that they can just put they're creating more work because they're putting tons of words in and then they're having to retrofit that so what if the interface could be better configured to like maybe encourage them to chunk up the text so that they don't have that leg work later on and similarly with the buttons and the links that's a kind of retrofit reactive bit of work that they're having to do there so maybe is there a way that the interface can lead them through creating connected content better and talking about the other principle of co-design is valuing broad experiences and so before you start getting to features from that stage even you broaden it out again ok what's available in the Drupal community that could support how these features work what's available in terms of editor empowerment things that would control how features work because it's not just about putting a feature in an interface how that actually works and if it does the job that you intended it to do will depend on a lot more and I want to focus on editor empowerment because this is really crucial so if you put a feature into an interface if the editor uses that how they use it is going to depend on their behaviour towards it and every behaviour is underpinned by capability, opportunity and motivation this is a combi model from behavioural science so an editor would if they wanted to use a feature they'd need to feel familiar with it they'd need to know what it did they'd need to have some kind of idea of onboarding or maybe like through a how to guide that feel that they could actually use it they need to have the opportunity to use it so if it's sat there in the interface and it's buried beneath all the other paragraph options they might not and they don't really know what it does they might never actually think oh yeah I'm going to use that to structure my page so the interface can support that by choice architecture to put things in front of people and to actually describe them with labels that are meaningful to them there's also an element of motivation and this really comes the value of peer support and relationships with editors because editors will learn from other editors they'll listen to another editor way more than they'll listen to somebody like me saying this is the way to do it so you need to bear that in mind with every feature that was planned out in the roadmap for the interface there's an element of putting effort into this side of things as well yeah so just playing that out I guess like thinking back to that example of a program page a course page you could choose a content type for that say that's your feature that you're going with okay great but also tap into what's been known in the Drupal community about views because that could help make that feature work in the best way and also make sure that that content type is something that editors are going to recognise when they go to pick it in the interface similarly you could go for tags for the connected content problem make sure that there's an actual strategy for connected content for what that's all about and draw on expertise from the Drupal community in terms of taxonomies and groups so this is prioritising features this way hopefully gives you an idea of how this is a better way of doing it and I will say it's a slower way of doing it I'm working in a team with developers where you're asked about what they're to build and what editors want a lot it can be difficult to go through this methodical process but what I will say is what you end up with things that are prioritised have been built by the people for the people it's a more sustainable approach and it runs less risk of technical expertise I guess being put into building features that then don't get used or they don't hit the mark just touching on that aligning design and development within the agile framework because this is kind of crucial to this whole co-design process so how it typically will work is in an agile framework it'll have a series of sprints there'll be the UX and design work and that can be around particular features of the interface that are outlined on those top cycles there there'll also be development cycles it helps to acknowledge that these operate at different velocities and once that's known you can arrange things so that the UX and design is maybe feeding into the development there's always a two-way process of learning from each other but it helps if they're staggered slightly it also helps on that to respect each other's priorities and processes so developers' processes that matter to them will be things like documentation, user acceptance testing before merging any changes experimenting with functionality to learn about the potential from the design side of things it'll be convergent sorry divergent and convergent design process like the double diamond sketching prototyping out-user flows like ascertaining what needs to be in the UI and also disseminating user research findings once you know the differences and you know the different priorities you can look for common ground so from the design side of things when you're looking to converge when designers like me are looking to converge on what we need to focus on use that documentation that the developers have created learn about the capabilities and use that to think about how to focus the effort's best user research findings the UAT document is an ideal place to disseminate that information to pass it to developers so not only are things being checked for functionality they're also having a QA check or UX check as well and similarly the functionality experimentation with developers it can feel like a kind of closed wall to designers sometimes but similarly with the sketching and prototypers from the development side but try and get some common ground there and if the tools are blocking you because you're using different ones then go back to paper and pens and have a shared sandbox and just be kind of more open go to quick summary so we've kind of given you a vision of a sort of reimagined editor interface talked rapidly about co-design and not done it enough justice but really the crucial part is starting with relationships and mapping out and listening to editors and taking that on board thinking about features and how there are only one part of the solution that empowering editors is a crucial part of that as well as learning from the wider community given some ideas about alignment of design and development in Agile and that's all I have I'll go to my resource slide and say has anybody got any questions Any questions from the floor? Any questions from the floor? Yes I can hold it, wow Where are you in this project? You have done the research and now you're starting to design or you have finished the design? Because we're working Agile it's kind of an ongoing process so we're doing pockets of research and then we're doing some development and design so we're kind of working incrementally but I can say every feature that we have in the interface now it's been rooted in an editor need which is like a huge win for UX and content design because it's really aligning with what our editors have wanted and it's a slow process but we can see the benefits of having tested this with our editors just now so we have a long way to go I think well until March we have to until we are turning off the Drupal 7 offering so it's ages right? Next question is Are you using paragraph or layout builder or are you customising everything? Sorry what was that again? For the UI you're creating Is it a customisation of layout builder or is it a customisation? We haven't used layout builder we've been looking at paragraphs so that's where we are Thank you Anyone else? Anyone else? Please just show the resources page Sure Sorry Yes Because you said editors so often do you deal with anyone from marketing or anything else around that? So I've used editors as a kind of general term some of these are marketeers some of them are it works differently at the university so the editors will be anybody that has access to the CMS to publish content so that could be for marketing purposes it could be across our web estate we publish a lot of content for researchers as well as much of the marketing content will be aimed at prospective students we also publish content aimed at students who are currently studying more information and then we also have university as a huge research goal and initiative so a lot of the content we publish is aimed at growing that so I've used editors quite widely because it's a devolved community everybody has different reasons for publishing content but it still needs to be designed with the end user in mind of course Do you have any screenshots or can you share any screenshots with us like how the interface currently looks like? I would have to not quickly I can definitely get that available but not just now I would need to log into our environment and forget my password and do all that that normally happens but I can definitely get that available for you I can maybe make this available to a resource pack at the end so I can definitely do that would be cool, thank you Anyone else? I recognise editors going like I want to copy and paste a picture in this field and stuff like that Do you just go to them and say I'm sorry but that's not possible or did you find a solution to it So you have to I think with the copy and pasting you have to understand where the stuff is coming from that they're getting and the format that it's in because one of the things with the copy and pasting is because it's so easy in 7 certainly the way we have it configured you can paste 500 words in and then they publish it they see a preview and they realise this is not great content so they go back and they use the tools that are available accordions are something that people use a lot because they want to shorten a page so it's understanding how much first of all how much control they have over that content and who is providing it and could they perhaps provide a template to the person that's providing the content so that it comes to them in a chunked way so that then when they get it into the interface if that could marry up with particular text fields to insert it so that it's already chunked up so it's sometimes it doesn't rest in a particular feature in a configuration that will be part of it but then it will be putting the tools in place so that the person feels able to kind of control it if that makes sense so with co-design you try and not restrict people from doing things in a particular way you try and understand why they're doing that and understand the consequences and then maybe provide them with other solutions that will work for them more sustainably and save them work in the long run because editing the content within the interface is a lot harder to do than preparing the content so that it's ready outside of the interface and they have more control of sharing versions and so on and the people that they're working with rather than when they're on their own in the interface and they have that responsibility to publish I hope that answers your question a bit And that's why you use paragraphs Yeah paragraphs are great for obviously modular content and for kind of suggesting headings and that kind of just chunking it up to avoid the wall of words that have been kind of permitted previously with 7 Yeah Would you be able to give an example of how to incorporate a UX check into development user acceptance testing? Yeah so obviously it will depend on the structure of your UAT document the ones that we've dealt with will tend to step by step go through to check that a thing works in a particular way and then there'll be a yes at each one of those The way we did it was we included a kind of comment is this working as intended and if the answer was no first of all by saying is it working as intended that relied on the person completing the UAT to go back through the JIRA backlog and find out what the definition of done was for this feature and that would have an editor need attached to it that was something that we really tried to, well I tried to get into every thing that was built where's the research and there's a ticket for that so that would involve a check and then they would have to go back and look at that criteria and assess yes it's doing this or actually so an example of when we passed our CK editor we implemented the CK editor and it all got checked and then when it went through the UAT they had included a box for a strike through on the text which we couldn't allow people to use because strike through text on our website is inaccessible so that was something that came through it passed functionality but on the UAT on the UX section of their why is there strike through because that's the whole goal of this the definition of done said it would create accessible content so it takes a bit of time and obviously a UAT document can be quite long anyway one thing we did do was pass it through more than one person so we'd maybe get a technical person to complete it and then it would also go to a non-technical person to go through the same process and have another set of eyes on it so we were cross checking it on that point to what degree do you restrict the formatting options that content editors have like for example like you say the strike through for accessibility reasons but what happens when you restrict character count because I notice that the more formatting options they have the more they can break the designer at loads of content there's a balance obviously and we try and note the character count would be a way of reducing the amount of text however it doesn't acknowledge that there are it can be difficult and I think with a character count where we are going to have to restrict it is moving from 7 to 9 we had vertical menus for example in 7 and we have horizontal in 9 so character count will have to be restricted because it will wrap and look awful but I think if you can it's a balance to strike but what we try to do is like offer templates or content types to kind of show how the content can be structured and then to kind of like inform that with the and with the paragraphs I think a lot of the time we took away stuff and then if editors said where is this then we would question ok why do you want it and why can you not do what you want to do with what we provided because it was trying to avoid choice overload because choice overload can lead to inconsistencies because some people will choose one thing some people and there's a degree of interpretation about what one particular paragraph does somebody else will use it differently so yeah we tried to like start less is more I guess and then if yeah test it and if editors were asking for a particular thing ok why do you actually need that can you show me an instance of how that works actually let's get to the underlying need and maybe there's a different way to do it to kind of keep that consistency of content keeping in mind the end user experience which is they don't know the internal structure of the university whoever is reading the pages they need to see the kind of similar patterns to avoid excess cognitive load trying to make sense of it so it's a bit of an education piece as well I think right anyone else going once yep and so you know you said you don't use layout builder not yet but you are so wondering because why is it a choice or it wasn't a choice I think it's we've gone with what we know so we paragraphs was new everything has been new because it's from 7 to 9 so paragraphs was new so we're starting to learn what we can do with paragraphs and I guess if we find we can't you know layout builder becomes more appealing for particular reasons then we haven't ruled that out but we haven't started it yet and it's I think it must be the same in every team there's limited development resource and we've tried to put it to use kind of intelligently and do it incrementally layout builder would be possibly beneficial but we wouldn't know until we did maybe some tech discovery into that so I'm sure it's on the roadmap when it comes to sort of solutionising and thinking about potential but but yeah it wasn't a conscious choice to not use it versus paragraphs it's just we were learning so all right going once going twice yep that's it for our last session thank you thank you very much