 My name's Diana Campbell and today I'm going to be talking to you about beyond plain language techniques for communicating complex concepts and processes. A bit about me so I'm content lead at an agency called Oxide Interactive which is based in Canberra and Melbourne and there's a smattering of us who work remotely as well and I'm one of those people I actually live just up the road at the sunny coast. So at Oxide we work mainly with government and industry clients and I really love the work that we do. The clients that we work with are doing really important work which has a positive impact on society and it's a real privilege to help them. So I first got a job in digital during the dot-com boom when it's fair to say that content was an emerging practice and actually I don't think we even use the word content at that point in time. So my title was Internet Reporter and we had company uniforms and company car and we spent a lot of money and had a lot of fun and the company folded pretty quickly but that was fine that got me my start and since since then I've gone on to work in lots of roles in digital in the UK and Australia and a lot of those have been large organisations and all of them in one way or another have had to communicate complex concepts and processes with content. So today I'm going to talk to you about first of all we're going to define content and then we're going to define complex concepts and processes and then I'm going to take you through ten tips. So first of all content means different things to different people in different organisations. Adoxide and in the work that I do content means the pixels that appear inside the frame of a website and those pixels make and prize words, images, forms and more. Content is more than just words. Next slide. And great great content is not created by writers alone. The skills to create great content are many. Writing and content design, information architecture, user research, user experience design, user interface design, visual design, not to forget development, the whole team. If you are communicating a complex concept or process, all of these people need to be working together from the start of a project in order to achieve the best possible outcome. You will not achieve a great outcome when a team designs a website without actually reading the words that are going to go on there. And yet this is something that I've seen happen time and time again. You will not achieve a great outcome when you treat the website like a bucket that one team designs and then hands to the writers to fill with words. Sure the bucket may look shiny and attractive enough, but I can 100% guarantee you that it won't be sophisticated enough to do a good job of communicating complex concepts and processes. Another analogy I like to use is the kit home. When you design a website without understanding exactly what is going to fit inside it, you are essentially designing a kit home. Sure it's got room for a standard dining table, standard bed, standard sofa in digital terms, those might be your four headings, some bullet points and a contact form, but with complex concepts that won't cut it. When you involve content writers and designers right from the start of a project, the people who are actually going to read your content and understand exactly what is going to go on your site and how best to communicate that, your website is going to have the custom elements it needs to communicate those complex concepts and processes. It's going to have calculators, diagrams and decision trees. So now let's define complex concepts and processes. So as I said, we work with government and industry clients and they're trying to solve really difficult problems. So they're trying to persuade people to take action in relation to an issue that is hard to understand, hard to take action on and sometimes even controversial, or they're trying to make it easy for people to understand if they're eligible to access a service, but there are lots of ifs, buts and maybes. These are some of the tricky processes and concepts we've had to communicate with content in the last 12 months at Oxide. Persuading the general public that low emissions technologies will help Australia achieve net zero emissions. Persuading health managers to invest in integrating SNOMED CTAU into their software to benefit the health of all Australians. Making it easy for prospective nursing and midwifery skilled migrants to apply for a skills assessment as part of their visa application. And making it easy for individuals looking for a job to understand which government payments and programs they are eligible for. I believe there's one thing that fundamentally separates the complex and the simple, and that is patterns. So this is a recipe that I've been making for about eight years now. Healthy homemade granola from a very popular recipe blog called Recipe Tin Eats. So I eat this basically every single weekday with Jalana Coconut Yogurt and it's amazing, I highly recommend it. So even though I've made this recipe countless times, I have never read the words that appear at the top of the page. And so for the purposes of this presentation, I counted them up and there are actually 612 words on that page that I have never read. I always just skip to the ingredients and the method and I use those because that's what's going to help me complete my task. So recipes follow a very recognisable pattern, which means that users can skip straight to the content that matters and ignore the rest. With complex concepts and processes, there usually isn't a pattern to base your content on, which is what is making it complex. So when your content doesn't follow a pattern, your users do not know what they can skip in order to complete their task. They're easily overwhelmed and overwhelmed is a word that we hear time and time again when we do testing with users. And there at a very high risk of giving up and leaving, bouncing off your website never to return or of just picking up the phone and emailing and failing to self serve. So what can you do when there's no pattern to base your content on? Ruthlessly minimise words. So for every additional word that you include on a website, you are increasing the effort that you're asking the user to put in to consume that content. With every extra word, you're increasing the chances that they will disengage. So these are some simple strategies that you can use for minimising words. Think of word count as an effort score. So this is just a simple strategy for keeping you mindful about how many words you're using and to focus on reducing them. Use character limits, especially in summary text, the couple of little sentences that appear underneath the heading and especially in cards on landing pages and remove those FAQ pages because they are generally duplicating content that is elsewhere on the site. So this is a quote from Mick, name change to protect his privacy. So sometimes users come out with really blunt statements which sort of perfectly sum up what we as the project team have been trying to very sensitively say to the client. So Mick's not there for a read. So have you, are you publishing in government or industry content? If so, your users probably aren't there for a read either. So don't make them read anything that they don't have to. Minimising not creating content is most helpful within a complex process. So what else can you do to communicate complex concepts and processes? Break it up. So you need to break the content up into manageable chunks so that you're not overwhelming your users. This, by doing this, you might be creating more clicks and that's okay. Next one. So this is a form that we've developed for the Australian Nursing and Midwifery Council. It's currently a PDF form on their website, a single PDF form, but rather than turning it into one single, a single page digital form, we've broken it up into six steps. So what that, what that's done is minimised the amount of content on each screen. And it has created more clicks, but it's made it look more simple. And because it's more simple, people are going to be more likely to engage with it. Use different content styles. So I'm not sure why, but American websites tend to use more words than Australian websites. So when I was looking for an example of what not to do, I thought I'm pretty sure I'll find an example on an American government website. So hopefully no one here has worked on this and I'm not going to offend anyone. I think the chances are pretty small. So this is a page from the US government's Ticket to Work website. So Ticket to Work is a government program that helps people with disabilities find longer term employment. So I haven't actually read the content on this page. I'm overwhelmed by it. I don't want to waste my life reading it. And it doesn't look like a lot of love has gone into developing it. But what I can tell you about it is it has 882 words or an effort score of 882. It has a readability score of grade 13 measured using Hemingway. Has anyone else here use Hemingway? Excellent. We'll talk more about that later. And to break up these 882 words, there's only two styles that have been used. Headings and bullet points. So this is what the content looks like when you copy it into Hemingway. For people who haven't seen it before, what Hemingway does is highlight sentences that are very hard to read in red. And so as a content writer or designer, what you're aiming for is all white sentences. So there's quite a bit to be done here to make this more readable. And the effect of consuming this content or being asked to consume it feels a bit like being asked to consume this steak. No, thank you. I'll pass. So you need to break the content up using the different styles and in doing that, you're going to make it easier for the user to process and much more palatable as well. So these are some of the styles that I like to use to break up content. Summary text and anchor links. Video. Call to action panel. Highlight bullet points because not all bullet points are created equal. Tables. Tick unordered list style to show what you can do or what you should do. Cross unordered list style to show what you can't do or what you shouldn't do. A project snapshot. So there's a common misconception that if you're talking about or publishing content about a project that it has to be comprehensive. But if the project is simply there to show that there's lots of activity happening in a particular area, for example, in relation to low emissions technology projects, it doesn't have to be comprehensive. It can just be a really engaging little snapshot. And the same goes for case studies. They don't have to be exhaustive either. If they're simply there to persuade the user that there are organizations that are taking action, they can be short and snappy like a testimonial as well. And numbers and facts panels. Love those ones. So the effect of presenting content using all of these different styles is like presenting the user with a degustation menu rather than a massive steak. infinitely more palatable. And not only are you breaking the content up and you know, making it look nicer, you're actually presenting that content in a way that is going to make that make it much easier for the user to process. So this is a page on the we can't see it very well, but the National Clinical terminology service website. And it uses eight styles. That's in comparison to the ticket to work page, which used two styles. And just to return to an earlier point to create content like this can't be done by a writer alone. You know, it involves all of the team members that we mentioned earlier. You choose a preferred term and use it consistently. So for the National Clinical terminology service project, one of the most challenging parts of that was fittingly the terminology. So these were some of the terms that were seemingly to me as an outsider used to describe the same thing. Clinical terminology, terminology, snow med CT, snow med CTAU classification scheme, health code set reference set ontology semantic network. So as a content designer, it was my job to go. Okay, which of these terms do we need to use? Which ones actually make sense to the audience of non technical clinicians and health managers? And so my advice, if you are trying to work out an approach to using terminology to communicate something complex is to choose a preferred term. And to identify that preferred term, analyze Google find out what people what term people are mostly using to search. I would say avoid using lots of different terms to refer to the same thing is simply for SEO. It's hard enough to help people understand, you know, whatever concept you're trying to communicate. Anyway, without, you know, using all sorts of different words to refer to it. And if it makes sense to use an alternative term like we have here, we're referring to snow med being a code set, use the preferred term alongside it as well, so that you're always linking it back to that sort of core definition. Sometimes it's not so much the terminology that's difficult. It's lots of complicated criteria relating to different options. And if you're, if you've got that situation, consider using a decision tree. So here's a decision tree that we've created for the Australian Nursing and Midwifery Council. So the purpose of this decision tree is to help prospective skilled migrants who have English as a second language to understand which which skills assessment is most relevant to them. So each step asks a simple a single simple question. And after answering one simple question per screen, the user receives their answer. So clients tend to find the idea of somebody outside their team, editing or touching their content, very frightening. And, and that's totally understandable. But I find that when we explain our methodology to them, that they're generally put at ease. So at Oxide, part of our methodology is to develop content guidelines for every page that we're rewriting or refreshing. And those content guidelines cover business goal, a description of the users, the user story, and we'll come come to that again in a second, plain language, the style and the target readability score, call to action, and then acceptance criteria. User stories. So who here is familiar with user stories? Probably everybody who here uses user stories to develop content? No, look, I know that there's a lot of people out there who have very strong opinions about user stories and appropriate ways to use them. And if you're one of those people, you might want to look away now. Because this is, this is not traditional use of user stories as they're defined in the agile framework. But I find that they're the most useful tool for communicating complex concepts and processes. So as you would know, this is the structure of a user story. As an X, I want to Y, so that I can Z. For example, as a decision maker clinician or developer who is new to the Australian Medicines terminology, I want to know why I should adopt the AMT so that I can understand whether to invest in implementing it in my organization. Here's something else that is controversial. We ask the client to express their business goal by following the same format as X, we want to Y, so that we can Z. As the Australian Digital Health Agency, we want to clearly explain the benefits of adopting the Australian Medicines terminology, so that more organizations adopt or develop software that incorporates the AMT, leading to better health care for all Australians. So by by doing this by structuring the business goal and the user story in the same way, you're putting the business's needs on a par with the user's needs. So this is a bit of a generalization, but in a lot of the teams that I've worked in, we're always talking about users, uses this, user-centered design. And that's, you know, that's absolutely valid, absolutely what we should be doing. But the business needs are just as important. And I find that when you show that you value the business needs by through simple strategies like this, where you're making them equal to each other, that it's very effective at building trust with with your stakeholders. And actually developing the user stories and the business goals is my favorite part of the content development process, because it gets to the heart in just two sentences of exactly what the content needs to achieve. And after that, it's just very easy to see what the content is needed, and what you can ditch. So don't tell. So who here has struggled to explain the concept of plain language to their stakeholders? Yeah. So we're getting more and more RFQs or requests for quote coming through now, which are asking for plain language editing. And that's really good. But there's still lots of people out there who just don't get it. And that's okay, because we're here to teach them. So we've recently had a client who was was very difficult to engage very, very busy. She couldn't come to any of the workshops that we ran in the discovery phase. And so we engaged with her colleagues instead. Anyway, so we got to present our insights and recommendations as a result of the discovery phase. And one of the recommendations was our insight was that most of their content had a readability score of grade 10 to postgraduate. Our recommendation was to edit it so that it was that grade seven, or that grade nine was acceptable for their content. And she said, we definitely need at least grade nine, the audience are all at least bachelor prepared. So I thought, okay, she doesn't get it. So I was like, for a long time, I had been curious to see what a client's reaction would be if I showed them what their content looked like in Hemingway. So I decided that it was time for the experiment. So I copied her content. Actually, I should clarify, it wasn't her team's content. It was content from their from a different part of their website from the about section. But it was at a grade 13 readability score. So it was comparable to this content which I showed you earlier. So I showed her what it looked like. And she said, I do take your point. It sounds like it's being read out in court or something. So maybe maybe when it comes to explaining plain language to your stakeholders, it's better to show rather than tell. Finally, so I love all of the tools that have been developed to make our lives easier when we create content tools like Hemingway, readable, gather content. But I'm not in fear that I'm going to be replaced by a platform or a robot anytime soon. And that is because while those platforms will tell you how to simplify your writing and help you collaborate on content, they won't tell you whether or not it makes sense. So this content actually exceeds Australian government readability standards. But it doesn't make sense. And as a content writer or a content designer, the greatest value that you can bring when communicating complex concepts and processes is to relentlessly say when it doesn't make sense or that you don't get it. Because the client or the stakeholder is just too close to it to see that. And yeah, if 20 years experience has taught me anything, it's that if I don't get it 99 times out of 100, the user doesn't get it either. So be that person in the meeting or on the team's call or on the Zoom call who is not afraid to say, I don't get it. Because that's that's the greatest value that you can bring when communicating complex concepts and processes. So in summary, 10 tips involve content people from the start, understand patterns, ruthlessly minimize words, break the content up, use different content styles, choose a preferred term, use decision trees, show your methodology, show don't tell and relentlessly call out what doesn't make sense. The end. Any questions? Yeah, we've been using forms to build decision trees. I'm just wondering if there are any cool, fruitful plug in the things that I wish I could recommend some. To be honest, with that one, we've we've tested it multiple times using tree jack. And now we've we've created the designs, but we haven't built it yet. So I'll let you know. Anybody else? Yeah, thanks for the presentation. One of the points was ruthlessly minimize words. But then it comes to the point where it doesn't make sense. Then you have to compromise which then makes it not ruthless, right? So yeah, well, you know, minimize them to a point. But if they all need to be there, you know, to explain something, you've got to work out how to present them in a way so it doesn't look like a giant stake, you know, you've got to break it up, or you've got to hide some you've got to put some in a tool tip. What you know, what does every person need to know? Display that on the page for like the people who need a bit of extra support to understand if they're eligible, you know, it can go in a tool tip or it can go in a I do not love accordions because they're so misused. But you know, yeah, just break it up. And yeah, really just need to test it to work out what needs to be there. Earlier in the presentation, you showed an example of like that content from an American website. And I'm pretty sure I've seen content like that on our website in many places. But also, did you have an example of that content rewritten to be clearer? Not that particular content. But yeah, the content that we've written for the National Clinical Terminology Service, most of that, I guess, follows a lot of the principles that I've talked about today. So I'd love to get stuck into that page and make it nice and easy to read. But yeah, I'd recommend having a look at the National Clinical Terminology Service. And you can see that the strategies for for breaking it, breaking it up, summary text, more headings, bullet points, it looks like it just needs to be cut cut, you know, define what the user story is for that content. And I bet 80% of it would probably fall away because it just sounds like somebody talking about that particular program from their organisational perspective, which the user probably doesn't need to know that level of detail. We have an organisation that's really addicted to FAQs. And we're constantly trying to get them out of it. Got any tips for doing that? I think it comes about when they've got to get something out in a hurry. And the easiest way is to stick it all in an FAQ. Yeah. So do they know that there's too much content or that people are overwhelmed by content? Not really. What I find that you can, I haven't told clients that they can't have FAQs at all, but don't have an FAQ page. So you can still have like a question and an answer format on the bottom of the page or within a page, which is a topic based page because that's actually at the heart of so many problems with content is that they're arranged or unlabeled according to the content type, whether it's a it's an FAQ, or it's a resource, or it's a publication, or it's a toolkit, whereas users don't want to explore content in that way, they want to explore it by topic. So you can encourage them to incorporate their FAQs into the relevant topic page as long as they don't cover the same content that's already there.