How to modernise digital services to support mental health needs

Open the transcript in a new tab

RICH BYRNE: OK, great, I can see some people coming in. Welcome everyone, welcome to our talk today on how to modernise digital services to support mental health needs. This is a project that was run in collaboration by Made Tech and Mason Menter and our good friends at NHS1 Gloucestershire as well.

We are primarily going to be talking about a project we did called the Children and Young People’s Mental Health Pathfinder, along with NHS1 Gloucestershire.

Just to introduce who is going to be talking on the panel today, if we could move to the next slide please, Anna. I’m Dr Richard Byrne, I am a Lead Engineer here at Made Tech. I was also Lead Engineer on delivery of the project that we’re mainly going to be discussing today. I’m mainly going to be Chairing. I’m going to run over a quick overview of the project before handing over to the other two panellists we have here today. Liam Miller being one, who is a Senior Engineer here at Made Tech, and was also one of the main Engineers on this NHS1 Gloucestershire project that we worked on. He will be talking about a lot of the technical considerations and things we put in place to deliver this project.

We are also joined by Kat Thackray, who is a consultant over at Mason Menter, who led on a lot of the amazing user research and design that helped made this delivery possible.

To give a quick overview of how the event is going to run, just a little bit of housekeeping, we are mainly going to be talking about the NHS1 Gloucester Children and Young People’s Mental Health Pathfinder project today. We would love to hear from you as we go. Once I finish my section, I will start to look at the questions and the chat box. If you have a look at the bottom of the screen, there is an area for questions to ask and there is also an area for chat comments. Please use the Q & A box to answer any questions you may have as we go. I will be keeping a close eye on that throughout the talk. I might interrupt Kat and Liam from time to time, to ask some of these questions. Or if not, we have dedicated time at the end for questions.

That box is super useful, you can also use it to ask anonymously, should you wish to. The chat box will come through to us, so please use that for any comments or suggestions you have, either about the project itself or ‘that’s really cool’, that kind of stuff.

We will be sending out a feedback link at the end, so any comments about either this project, the webinar itself, or any ideas for future ones that you would love to see, let us know when you get that link. Just a final reminder that this is being recorded so you will be able to watch it again, and share it with anyone that wasn’t able to make it today.

To cover the agenda, I’m going to talk about what the project is, give a high-level overview. Kat and Liam are going to go into way more detail as time goes on. Kat is then going to cover the user research and design aspects of the delivery. Liam is going to talk about how we actually do it. He’ll be talking about the what, Kat will be talking about the why, why it had to be this way. Then Liam will talk about how we managed to pull it all together.

Let’s start with what the project was. From a very brief overview point of view, we were asked to support mental health services for children and young people in Gloucestershire. The project took eight months, a very busy eight months. User research and design, as mentioned, was led by Mason Menter, who not only helped to map user journeys, but also to work out content design and other amazing bits and pieces that you will find out a bit more about from Kat shortly.

We ended up building not only a web service, but also an accessible SMS text messaging service, primarily running off the AWS technologies and backbone, to help young people find relevant mental health services.

There is a lot more info on our website. We will be sharing these slides as well, and you’ll get all these links in our case study that is linked there.

What was the goal of the system? Gloucestershire has a wide range of mental health services for children and young people. It covers all sorts of mental health concerns from things like depression, food and eating disorders, anxiety etcetera. So, it’s vitally important that these children and young people are directed to the relevant mental health services quickly, and as accurately as possible. Some services might only cater to children and young people of a certain age group, or they might specialise in one of these mental health concerns.

What you don’t want to happen is that somebody finds a service, gets up the courage to ask for the help and go down that route, and then find that actually, this place isn’t somewhere that can actually help them.

We were finding that the existing service that was in Gloucester was that the existing services were not really meeting user needs. There were long waiting times, and some professional services like the ones listed on the screen there, like CAMHS, had really long waiting times and needed you to be professionally referred to them. Which was just creating a huge, huge barrier to entry.

That meant that people were falling through the cracks, and sometimes the service that they got to might not actually be right.

We ended up creating a digital service that would help signpost children and young people to relevant mental health services, and essentially allow self-referrals to some of these services. Kat will talk a little bit more about how that works later on.

Just to point out really quickly that this wasn’t a diagnosing tool. This isn’t something you go on to, and it tells you or tries to diagnose what mental health concern you might have. This was very much about signposting and trying to find that help as quickly as possible.

We had a bunch of considerations to follow throughout the eight months of building this service. We primarily followed the advice that is in the Gov.uk service manual. Some of you probably know what this is, if not there are links on the other slides.

The Gov.uk service manual is great. There is also an NHS service manual as well, which really gives you a lot of information about certain design patterns to follow, the best user flow of a system. If you have ever been on a gov website, you will know that they all have the same sort of look and feel. Also how things should be asked and the cognitive capacity of only asking one question per page, or one question per screen.

It gave us a lot of great advice of how to not only build the system, but what phases to follow as we went through. I will talk about that a little bit in a second.

We also had to make the service as accessible as possible to the broadest audience. We also built an SMS text service as well as the digital service. One of the reasons for that is that there is a user group to consider of children and young people who might not have access to their own smartphone or their own personal computer at home. Perhaps they only have limited computer time at night, perhaps they only have access in the library. Perhaps their computer time is really closely monitored. So, we ended up building this SMS text service where you could go through exactly the same process as you could on the website but by texting instead. Just to try and reach a much broader audience.

The site and the services all had to be content manageable. Some services might need to be updated, waiting times or descriptions of what the service was. Maybe there were new services available, maybe other services had to be deprioritised because they were getting overwhelmed. We had to really consider what bits of the site could be content managed by the team at NHS1 Gloucester, and the clinical commissioning group there, the CCG, and work closely with them to make sure that we provided the ability for them to do that.

Additionally, we also had to follow clinical governance. This is a site that is talking about very sensitive bits and pieces. We had to make sure the language used wasn’t going to trigger anyone. Kat will talk about this a bit later.

As well as passing regular technology checks like pen tests and so on, we had to make sure we were passing clinical checks, like the digital technology assessment criteria there, as well.

So, really fun lessons learned about how to build these sorts of systems and what was involved in doing all of this.

Following the service manual, we took the agile approach you see there, of Discovery, Alpha, Beta, Live phases. Discovery had already been done by NHS1 Gloucester to a degree, so actually we came in primarily on the Alpha stage, taking the lessons learned, and building the service from there.

What that involved at each of the stages, taking it from the Discovery and the Alpha, we did a lot of user research and design during the Alpha stage. We explored the interoperability. We knew we needed to send text messages, we also needed to send emails. What would we connect to? How is that going to work?

We knew the site needed to be content managed to a degree. What might that look like? What would the site and the services actually look like? We started to build a lot of prototypes, and we leveraged something called the NHS Toolkit for that, the NHS playbook, which Liam is going to talk about a little bit later on. Super powerful, super quick to start pulling and building websites, and actually get that tested then with users. We did that process all through Alpha, constant feedback, constant loop-in on this process, which led to the Beta phase. Which essentially is more of the same, but all the decisions that were made, everything that happened in Alpha, we were able to build the site properly. This is when we were building the thing.

A constant repeat of building things, plugging things in, getting the content design signed off, testing with the users, getting that constant feedback, and repeating, repeating.

I’ve got a quick demo of what the site looks like as well. The link is there and you are able to go to the site yourself after this session, should you want to. It’s a video because it was easier than trying to share different screens.

This is the homepage, this is all content managed and can be updated by the CCG content design team. They can add videos, they can add more information if they want to.

We are going into the actual support finder service itself now. This is the crux of what this system is built to do. You can see this looks and feels very much like an NHS website. That all comes out of using that prototyping kit, and the tools they had available.

The way the system works is by going through and answering a series of questions. I am not putting anything specific in here, I’m just filling it in as I go. Every one of these questions, and every answer in there had to be signed off, to make sure that it was not triggering, and was correct and accurate.

We have to check certain things like are you in Gloucestershire, is your GP in Gloucestershire because some services are only available to people who live or attend school in Gloucestershire.

Certain questions might lead down different routes depending on what you’ve answered. It’s nothing ground-breaking, it is something that you will have seen a lot if you have ever used a wizard or filled in a questionnaire online, especially on a gov website.

When you have answered all the questions that are relevant to you, click ‘submit results’, you will be presented with a list of services that match the criteria and the answers that you have filled in.

You can see the ones at the top all have a little ‘get started’ link underneath. These are the ones that you can now self-refer to. You can go to another part of the process after this, if you think this is the right service for you, and actually start that referral. Where previously you would have had to go to a GP or another registered professional to do.

I’m just showing you the start of that journey here for CAMHS in particular. Again, this is content manageable. You can update things like the waiting time, and information about the services on this site. I don’t want to go on and do an actual referral because I don’t want to clog up their systems.

That’s a really whirlwind tour of what the project was and what it all looked like. I hope that made sense. I know I had to talk quite fast with it. Do go on the site and have a look at it yourself afterward.

To talk about why we had to build in that way and how we got to that point, I’m going to handover to Kat now, who is going to talk about all the amazing user research and design that went into this. So, Kat, over to you. I’m going to have a look at any questions as we go.

KAT THACKRAY: Thanks very much Rich. I’m just going to start off by talking super quickly about who we spoke to. We spoke to 12–25-year-olds, which is how we defined young people, closely working with the client in terms of who this service needs to be available to. Also, what parameters they were happy to conduct research within.

We spoke to the group that were going to be using this, and that formed the majority of our research because we felt it was so important to hear from those people. Not ground-breaking at all. We also spoke to mental health leads in schools. When we were developing that transition from Alpha into Beta, when we started to know what we were building, we wanted to know how we could build it really well.

We started to get a bit more of a – I hate this phrase, but a helicopter view. People who were aware of all sorts of different challenges that young people were experiencing, and were able to tell us a little bit about how that had changed after the pandemic. What sort of demand they were experiencing, and the challenges that they had in being able to refer young people to the right places was also really interesting to us.

Throughout, we spoke to children and young people’s mental health services. The client was the CCG, but they had partnered with Young Gloucs, and with a counselling service called Tick Plus that is local to Gloucs to provide a lot of these mental health services. We had all of these people with very different areas of expertise, who were able to really guide us about what language to use, where to find young people to speak to, what not to say, what to worry about. And to give us that clinical view of these young people. They are using a very different language and we really needed help to bridge that gap. What does that look like from a service perspective?

The next thing I’m going to talk about is when we spoke to them, as Rich very briefly touched upon, we did a lot of research during this project. We built on a discovery that had been conducted by NHSX. They had done some interviews and research mostly with parents. They had really struggled to get young people’s voices because it is hard. I’ll come to that in a minute.

They had done it nationally. We had a bunch of discovery stuff to build on but we wanted to check what about that would be most applicable in this context of Gloucestershire, and with the young people that we wanted to help.

We knew from that research that there were a bunch of areas that we could look at. What we wanted to do was just to see which ones would be most fruitful. So, we did different kinds of things throughout the project.

We started off with really early concept testing. We built a choose-your-own-adventure in type form, and asked people to tell us what they were choosing and why they were choosing it as they went through, and why they ignored what they ignored.

In that way, we managed to narrow down 34-ish different concepts. We got that down to about – we got rid of 14 and then we did some requirements, so we took ten or eleven into the next stage. We did some prioritisation with the young people there, and we played some games, pretending if you had some money, which ones would you buy. We made each of them more expensive depending on how expensive they would be to build in the real world.

From that, we got to the end of knowing what things we should build. You might have heard the term Alpha, which is where you figure out how to build the right thing, and then Beta is where you start to think about building the thing right. It was all about what we should do, what about this idea is interesting to you, during the Alpha. Then by the time we got to Beta it was lots of rounds of repeated testing.

We knew what we were building, we had to make sure we got the language right, we had to make sure we got the navigation right. We had to make sure we didn’t alarm young people by asking them really serious questions right at the beginning – or actually, is it better to get those difficult questions out of the way? So, we had to tackle those kinds of difficult, gnarly questions as we went through.

Throughout this process, some of the things that the team had thought would be really important turned out not to be so important, and some of the things that we hadn’t really considered turned out to be the most important. So that sort of early concept testing was really, really valuable. We went into it with an open mind.

I think the next slide is about why we built what we built, and how we got there.

Rich has covered this list here of what, but one of the big findings that we had was about that process of looking for help. The client had come to us with three problem areas. One of which was how might we support people while they waited for treatment, how might we help people get to support at the right time, and how might we help people feel more in control of their journey. I think the feeling was that supporting people while they wait for treatment would be the big thing to think about. Because waiting lists for NHS services particularly CAMHS are really long, and getting longer. Partly, that’s because that is the one that people have heard of. If your young person that you are responsible for is struggling, that is probably where you send them, even if it’s not quite right.

What we found, actually, is that a more useful intervention would be getting people to the right support at the right time. Our big ticket finding was that everyone in our early rounds of research that we have spoken to, didn’t start by talking to their friends or reading a book or Googling. The first thing they did before they started looking for help was to go and talk to an adult. That took a huge amount of courage, and quite often that adult was not appropriately equipped to give them, for example, the most relevant eating disorder clinic in the local area that they were in.

So, they sent them to CAMHS, and then they got put on the waiting list, and then they got rejected once they had been assessed because that wasn’t the right service for them. Obviously, that’s bad for young people, it’s bad for NHS services, it’s bad for their relationship with their adult.

We aimed to create something that filled that conversational need, that barrier to entry. You are building up the courage to go to your GP as a fourteen year old and say, ‘Can you help me, I don’t know what to do.’

We started with the hypothesis that it might work, and we were really pleased when it did. We had a lot of worries along the way, like is it okay if we are asking people to… We can’t get them to tell us, we can’t build a conversational text which is that clever, or a conversational interface that is that clever. They are going to have to say something like ‘2 – I am struggling with my body image’. They kind of really like that because it meant that they didn’t have to articulate the thing that was hard for them over and over again.

That is a little bit of the journey of how we got to where we got to.

There are a couple of other logistics bits which I will just touch on quickly. Number one is where we found people. This was hard, firstly. It was definitely worth it, but it was really difficult. This photo exemplifies some of the challenges we had. Boys get sad too, we know that young men have got mental health challenges in maybe not in exactly the same way as young women, but they also have them. But teenage boys do not want to talk to even very nice researchers about their mental health.

We had to be super-targeted. We did a lot of our recruitment through CAMHS, the NHS service, by clinicians asking people. That didn’t get us quite the mix that we were hoping for or the numbers that we were hoping for, so we supplemented it in various ways. We also went through the partner organisations that I mentioned earlier. We managed to go along to a youth group, and we took three researchers. We made some little mini groups and we asked them to do some content review because that was the stage we were at, at that point. We also had a big spreadsheet of mental health adjacent charities, places that teenage boys might be. This was in lockdown, or possibly again in lockdown by this point, so we couldn’t just go and hang out by the scout hut, or do some kind of poster in the locker room of kids football. We had to do it all very digitally. So, we just went through this list and phoned people and asked them, do you know anyone who we would benefit from hearing their perspectives of this potential service.

We also used the networks that we already knew. Does anyone know anyone who knows any teenagers? Through that, we managed to get some class time at Stroud High School for Girls. This was towards the end of the project. We used it as a participatory research session to evaluate what needed to change, if anything. In what ways would people like to be introduced to the work? What would feel the right way of talking about it? At that point, we weren’t asking people about their mental health in a classroom setting. We designed worksheets where they could choose to tell us what they thought about it.

The final thing on this is that it was absolutely worth it. Of course I’m going to say that, I’m a user researcher, but I think we would have built something really different if we hadn’t had all of those different conversations at all of those times throughout the project. But it was hard work, and it took a long time. So just plan for that.

This is the final thing I wanted to talk about. Just some notes on researching with vulnerable groups. There were two main things we needed to be aware of. One was not retraumatising our interviewees. There was a really interesting example of a talk I went to at a conference in March 2020. How can we do research in sexual assault with survivors. I thought, yes, how can you? That sounds really hard. What the team there said is – we talked to a bunch of experts and we just couldn’t justify talking to those people because that is some really hard questions you have got to talk about. The risk for the participants would just be too high.

So, we had a lot of conversations with the clinical team, and we used their experience and expertise to help shape a discussion guide that would not ask people to go over their pain or whatever has led to their struggles. For example, the first question we asked was, “Thinking about the time where you started looking for help, what did you do?”. We started at a point in the journey where they had some agency, where they could tell us about something that wasn’t what they were feeling, and why they were feeling it. They were aware of that. Then we left space for them to talk about what they wanted to do, and if they just wanted to focus on the journey then that was absolutely fine by us.

We got to the end of the interview and we never knew what their struggles had been, which bit of CAMHS they needed to be referred to. That didn’t matter. What we wanted to know about was their experience of looking for and getting help.

The second thing to be aware of is protecting researchers from vicarious trauma. These are quite hard topics. Quite a lot of people have had either a primary or a secondary experience of mental health struggles in their young days, if not now. There were some things we did to help out researchers as well. Things like not scheduling too many interviews in a day. They are mostly about time and relationships. Those are the things that we have within our control. We always do paired research because it’s just better. It’s better to not only have one person there because you can’t really argue with yourself very effectively.

We really encouraged making sure we’ve got some debrief time after the interviews. Did anything come up for you that has been hard? Are you all right to do the next one? Do we need to sub someone else in? Just being aware that hearing this stuff can bring a lot of things up.

Then another thing we did for this specific group, not so much about protecting interviewees, but how to get the best out of young people who are potentially struggling with anxiety, for example, or might be on the autism spectrum, who might not be very comfortable in a conversation with a stranger. We thought about the interview format in that way, as well. So, we offered SMS interviews or WhatsApp interviews, for people who didn’t feel comfortable in having a voice conversation. We managed to get some voices that we wouldn’t have heard otherwise. We also offered phone, for people who didn’t want a video, and we offered to do things like sharing the questions in advance, which makes me nervous as a researcher. But actually, for the teenagers that we spoke to it meant that we had much more focus, much more to the point conversations because they understood the process. When you are speaking to teenagers, assuming that they are going to have been sat in a room with an adult who is interested in their experience in quite an in-depth way, expecting them to navigate that conversation can be – you can have varying levels of success.

By the time you get to my age, you’ve had job interviews, you’ve been left alone in a room with your boyfriend’s parents, you’ve had to try and find some conversations to have. Thirteen- and fourteen-year-olds are still quite early in that process. Make it as easy for them as possible, was what we tried to do.

That is everything from me. If anyone wants to chat with me about research in vulnerable groups, then I’m very happy to do that. Feel free to reach out, I’ve got a lot more to say about it. I’m going to hand back to Rich, at this point.

RICH BYRNE: Wonderful, thank you very much, Kat. I’m just checking, there are no immediate questions that came in, but I did have one. You talked a little bit there about the challenges of vulnerable groups, and the content and the subject matter being quite difficult and tricky. What do you think was the most challenging thing about designing support for young people’s mental health?

KAT THACKRAY: That is a good question, Rich. I think the most challenging thing about designing the support was the clinical – the way the clinicians talk about things, and the way that young people talk about things, are very, very different. Clinicians are comfortable and safe with the subject. The way young people talk about things might be more flippant. It’s not been signed off. There has been no process that has happened when you are talking to a teenager about what is going on for them.

So, the real precision of the content design, was challenging in a new problem kind of way. It took a lot of time, it took a lot of conversations. The wording in the first question, where basically we just need to know, are you at immediate risk of suicide because if you are, you can’t use this service, you need to go to someone who can help you now – we had about four weeks’ worth of weekly conversations about what that could be. Going backwards and forwards to young people and them being like, I don’t really understand what you’re asking. Because the clinical way of talking about it was too soft. We would go back and say, how about this one? We can’t say that for x, y, z reason. That’s probably one of the more surprising challenges that came up.

RICH BYRNE: Yes. I definitely remember having some of those conversations. Wording some questions and thinking, this looks great, then all of a sudden, no, that’s not good. Or this is too harsh, surely! Then no, this is exactly what it needs to be. Yes, it was super interesting. Thank you, Kat.

Great, well we are going to move over to Liam. Before we do, just a quick reminder, do feel free if you have any questions as we go along, we don’t have the capacity to verbally ask questions during this webinar, so please do type them in the Q & A box at the bottom. We can keep better track of them, then any that we don’t answer during the session, if we run out of time for example, or if we need to look anything up, we can make sure that we collate them all and send them out in the update after this.

Yes, thank you so much for that, Kat, it was super interesting, and it was amazing being part of that journey with you as well.

To learn about the person who had to implement it all and make it work, I will hand over to Liam, who can dive into depth with that. Liam, over to you.

LIAM MILLER: Thank you very much Rich. So far, we’ve heard a lot about the incredible research that went into it, and the design that made it all possible. I just want to chat a bit more about the technical, the how, as Rich said. How did we actually get all this together?

To start with, I’ve produced this very simplified overview of the architecture diagram of the project that we ended up building. In brief, it was headless CMS content management service built using Wagtail. The UI was then created using NextPhase. We leveraged a wide array of AWS technologies, as well as making use of the .Gov Notify service. Hopefully, this diagram gives an idea of how that all came together.

It can be seen that we didn’t necessarily do anything ground-breaking or world changing. This isn’t a brand new idea from an infrastructure perspective. In terms of web applications, in this simple view we can almost see that Next.JS would be providing the business logic layers, with Wagtail providing some business logic, but mostly allowing for data access and control, and finally, an Aurora database existed to actually store our data within.

Beyond that, everything outside of the blue private sub-nav box is pretty much just empowering the application to be a secure, reliable service that provided the requirements that we needed. It could only be contacted by the correct locations. Just trying to remain efficient.

Where possible, we did leverage all of these pre-existing services. You can see here S3 allowing us to power the application, meanwhile using services such as AWS Wav, that’s the web firewall to help keep it secure. From here on out, I’m just going to go into a bit more detail about some of the technologies we actually used.

First I am going to talk about Wagtail. Rich has already talked about the need for interoperability and content management. We really did need a CMS. We went for the open source and Python based Wagtail because we [unclear] but in all seriousness, we just found it to be a great fit for us. It provided a clean and simple to use admin and UI, which was very helpful in being able to produce that separation between content and the UI itself for the website, whilst also remaining highly modifiable to engineers, without us needing to write verbose code. This was also assisted by there being familiarity with Wagtail within the 1Gloucs team. Content designers were already partially trained on how to use it, so we wanted to keep that pre-existing knowledge and really empower it.

Wagtail did provide a headless option which was very key to us. For those not familiar, when you go for a headless CMS, you are providing that separation. You will have the CMS take care of back-end work for storing and managing data, and then use a separate section of the stack to host the user interface.

There was also that wonderful joy of it being so light on code. You can see a small example of a code snippet on the right hand side of the screen. That is really all it takes to create a new content type which someone is able to work with. That was really helpful in making sure that we could get new content types created quickly, and test them with users quickly. We were also now able to test them via code, and ensure that we are getting correct content types, and we weren’t going to get any strange results from what was spat out.

Wagtail also provided an additional module called the NHS Playbook. This was designed creating content types, or allowing content types to be created in a way that could be consumed by an existing NHS Playbook. This will make a bit more sense on the next slide, but I just want to pull attention to that now. Having that module meant that it was easier for us to interpret our data and map what was being provided by the content editor to something that we actually wanted to use and consume on the front end.

From a content editor’s perspective then, it remained clean and simple. It focused more on content creation than managing, for example, menus and taxonomies that you may get in some alternative CMS. It keeps the access to content types very clean to a user, presenting a preview that they could quickly navigate through and get access of.

What was really helpful was it provided a feature known as stream fields, which allowed editors to dynamically place content blocks together within their content. So, not in a more dynamic field, it was structured. In the example on the screen, we have Subtitle, Introduction, Image. You could use a stream field to have three subtitles, two introductions and one image, in any order you provide. So, we were able to enrich this with the content blocks we had created to allow dynamic content to be produced that would be renderable by our UI in a predictable manner. It would not break the UI but it would still empower the content editors to produce content which they really wanted to ensure was top notch.

I would also like to just touch on very quickly, it did provide really great account and role administration, which was very key for us. It not only allowed for new accounts to be spun up quickly, but also worked with existing security measures with enforced MFA, but also meant that administrators could design their teams and apply permissions in a manner which was best for them.

For example, the person that uploads an image may need a specific role, but you do not want the person who is able to provide an image to be able to modify content in a specific group. For example, they might not be able to access the how to get help page of the application.

As the CMS grew, we were able to content manage the services which were provided. Thinking to the service results that Rich displayed much earlier in the demo, you had, for example, some which could get a referral. I believe you are actually able to toggle that on and off to say, ‘Don’t show a referral for this one.’ Others, you may have noticed, had links, where others did not. If you wanted your service to have a link, you could provide a link via the CMS, to say, ‘If someone sees this service, give them a link. Allow them to see this connected service.’

Others, such as speaking to an individual, maybe a school counsellor, didn’t need a link, so we didn’t have to provide that.

I think that is all I have for Wagtail.

Next I am going to talk about Next.JS. This is what we used to build that front end of the application, the UI.

As I previously mentioned, we wanted the headless CMS. We wanted also to be able to have the UI which could handle that. Also, this application needed to be able to be shared to other health boards. What was important there was trying to identify the technology that other teams were going to be more familiar with, which led us to Next.JS. Wagtail by default was used in the Ninja framework. We weren’t sure if that would be as common. Next.JS is built off the popular front-end library, React. Due to the popularity of React, we thought it would be a very safe assumption that the engineers would be familiar with it. If someone new was to pick this project up, if a new health board wanted to pick it up, they would probably have an easier time finding a React engineer who would be able to help with it.

Due to it being in React, we could leverage the React Playbook. This is what allowed us to achieve, as you can see on the example on the screen here, the UI that Rich has already demonstrated. We could inherit the React Playbook, to get the same look and feel as every other NHS website, and apply this to the content types we were passing back from our CMS. In such a way that you’ve got a new component, it slots in a random place, we are prepared for that and we can just provide the styling needed. So, there was less risk of us ever breaking tradition or breaking the stylistic guides of the NHS Playbook. Keeping it in line, whilst still being able to stay unique and informative.

One big joy about Next.JS is that it also allowed us to expose a rest end point, which used Express JS under the hood, I believe. This meant that we were also able to take responses from calls that weren’t necessarily our website, such as the .Gov notify service, which I will touch on in a moment.

What that meant is as soon as a message was received, we could start using the journey in a very similar way to how the web client user journey, so the web and text bot journeys would always go down a very similar or the same route, just from a different medium. We did not want somebody getting different responses because they opted to use the text service over the web service, or vice versa. That was very key to us. So Next.JS allowing us to intertwine those two services. Keeping them so close together and tightly coupled was key here.

That is all I’ve got for Next, so on to Gov.UK Notify next. Gov.UK Notify formed the backbone of our referral journey communications. Gov.UK Notify is a service provided by the government which allows you to send various communication methods through your own service. We had two major use cases. The first would be the sending and receiving of text messages, the text bot. How did it work? It was quite simple, as we’ve seen earlier in the diagram. You would text the number that was actually registered at the Gov.UK Notify. Gov.UK Notify was then able to take your message and send it over to our rest end point from Next.JS. That would then look at the message, process it as expected, maybe take it to the next step, maybe start a referral journey, handle the data. That would then return back to Gov.UK Notify, which would then text the user back. They would see their response and then they would respond to that message and so on, until eventually they were provided with a list of results that they could see.

The second use case is emails. Once again, it was touched on earlier that referrals were possible for certain services. Certain services would allow you to self-refer to them if you had received them from the support journey finder. The only way we could make that referral would be to actually send an email to the team that would be handling that service. Gov.UK Notify also allowed us to do this.

So, if someone completed one of those journey routes and said yes, I want to be referred, and provided the information required for a referral, our service was actually able to produce an email template, send that over to Gov.UK Notify, and then Gov.UK Notify would send that on our behalf over to the client, to the service. That would start the self-referral process from that services perspective.

The other joy about using Gov.UK Notify was regarding data retention. It was really helpful in ensuring that all of our data was in-flight, that we didn’t have data stored. We didn’t want any sensitive data sat around. We didn’t want to expose that risk. By using Gov.UK Notify, we didn’t have to worry about backing up the database and then sending it back out. We could just take information, send it across to Gov.UK Notify and Gov.UK Notify would not be storing that information. Which is very helpful. This also assisted in allowing future health boards to pick up the technologies.

If any health board wanted to use this service, they would also just be able to leverage Gov.UK Notify. They could create their own Gov.UK Notify account, provide the keys required that our service would ask for, and that would be it. They would have that connection for both emails and text referrals. They wouldn’t have to worry about creating or maintaining the email or SMS servers. Which for anybody who has tried that in the past, will know they can be time consuming, as well as quite difficult to keep safe and secure. So, it was wonderful to be able to use Gov.UK Notify to catch that for us, and use this other service to carry that burden.

Finally, I just want to talk about the cloud technologies that we used. I mentioned a few times, one of our key focuses was that another health board should be able to quickly pick this up and implement the code themselves. They should be able to get this service running within their own county. Due to that infrastructure code almost became a necessity. We had to also consider that we were using AWS. We knew that we had opted to use AWS. Another health board may not necessarily be using AWS. While we weren’t able to say, here’s a Zooa or GCP version you can spin up, what we could do is use Terraform to provide a more common language for that team.

If they don’t know AWS and cloud formation, maybe they know Terraform. By knowing Terraform, maybe they would still be able to spin up the AWS technologies in an AWS account, but managed using Terraform rather than having to suddenly get concerned because they are trusting something they have no knowledge about. It might just help provide that additional knowledge.

By using AWS, we were able to empower our application to be reliable, secure, and cost-effective. We tried as much as we could to reduce management overhead.

I’m going to rattle off some of the services we’ve used. This is not an exhaustive list, and the list will go on and on, as it quite commonly does with AWS cloud, in all honesty. The first key service I want to bring up is Amazon ECS, the elastic container service.

You may have remembered in the diagram that this was essentially that blue subnet, minus the database. What this allowed us to do was to deploy and host our containers, containing both Wagtail and Next. JS, and have them running in the cloud. It would also remain scalable because ECS was allowing us to say hey, we’re getting too much traffic, so let’s create a new incidence of Next.JS which can run and take more of that burden. Let’s not overload the application.

It also meant that we could have rolling deployment. For those less familiar, a rolling deployment means that hey, I’m deploying my code, but don’t take the website down. There’s no reason to show that this page is down for maintenance, visit back in two hours. It will wait until the container has been created successfully, is running, has passed its health checks, and then it will drip feed the other applications.

So, someone could continue to use the site and suddenly a new widget has appeared because that was part of the latest code deployment.

I would also like to mention Amazon Aurora because this links very closely to ECS. What Aurora allowed us to do was it acted as our database. A standard SQL database, but it provided a point in time recovery, which we found to be very helpful if something ever went wrong. We were able to roll back to a very precise period of time, being able to catch something critically wrong. We could just take an image from a bit further ago.

What was also really handy here was that we were able to produce read only database connection strings. So, if someone had access to one of these connections strings or an instance, it meant that they were only able to read the database. They were not able to write. How this ties in really nicely with Amazon ECS is that within the ECS, we had a version of Wagtail which was available to content editors. That is how content was created and produced. However, when we were using Next.JS, that would be looking at another incidence of Wagtail which was in headless mode, and only had a read connection to the database. That instance was not able to write.

What this meant is that our Next version was not looking at the same instance of Wagtail that content editors would be working with, helping us to provide that much more separation for security purposes and reducing risk. It also meant that there was no possible way that the container from Next would ever be able to do anything with the Wagtail instance to write to the database. Providing just a wonderful security plus for us.

For AWS code pipeline, I just want to mention that this allowed us to apply code for the pipeline and run, for example, our unit tests, keep it all safe and running. What we did find helpful is that by using AWS code pipeline, these pipelines were purely run in AWS, and there was no need for us to make any assumptions about the client’s pipeline technologies that they were choosing to use. We were instead able to say, here are the pipelines we’ve used, you can also use them. You can follow our process, you can run your Linctus, you can run your unit tests, you can run a regression test, and then it can deploy to pre-production. You can test it there, and then it can deploy, finally, to production automatically.

I will rattle through the next ones very quickly, because I am a bit cautious of time. AWF Waf, we were able to use this to configure our firewall. It was incredible how it was able to spin up and then be so manageable yet so strong. What the Waf allowed us to do was, we had a specific issue with images, where it was thinking that certain uploads of images were malicious. We were able to work around this whilst not compromising on security. We were able to make bespoke changes as required.

We also used Amazon Dynamo DB as it allowed us to store some of the end structure data related to the chat bot. This was done by using non-identifiable information and leveraging Dynamo DB to be able to throw out any records after a fixed period of time because we did not want anything sat around where possible.

Finally, I will just mention Amazon AWS S3, which we used for our asset storage, such as the images and videos, the stylings. This is where they could be stored and pulled from. I could rattle on but we would be here all day. ECR, ACM, Route 53, the load balancers… I am cautious about time, so I will pass back to Rich now and calm myself down a bit.

RICH BYRNE: No worries, thank you, Liam. Just to highlight as well, that Liam hasn’t been feeling too good lately, so well done. It’s always interesting to talk about the bits that actually pull the stuff together. It was a big old system and a big old lot of work that we had to do to get this running. Thank you for that, Liam.

We do have some questions but I just wanted to finish up with what this work has actually led to, now.

Basically, we found that the information needed to access these mental health services did become easier to find and to understand.

We made the service secure and resilient, as Liam mentioned there. We also made it open and reusable so that any other NHS health boards like Bristol and Somerset, they could take the code as is, and very quickly spin up their own version of this with all of their own services, and run it in exactly the same way. They could rebrand it slightly if they wanted to, as well, changing the Gloucs styling out for the Bristol styling, for example. That’s where I’m based and that’s why it’s in my head.

Through user research we revealed that around 2,577 children regularly visit the site. That’s since launching it in schools. One thing that NHS Gloucs mentioned was that they found it really useful to advertise this service in schools, alongside other mental health awareness programmes that were happening in schools, over certain periods.

The site has reached around 100,000 young people so far. It’s not on this version of the slide, but the work has also been shortlisted for the Health Service Journal and Health Tech Now Award for Providing a Service to Mental Health Services. So, it is definitely work that I am super proud of. It’s one of the best projects that I have had the opportunity to work with, not just at Made Tech but in my career. I certainly felt that it was very rewarding.

Thank you to Kat and Liam for working on this as well, it wouldn’t have been possible without you.

With that in mind, I’m going to move onto a couple of questions that we’ve got. Kat, I think you could probably help out with this one.

The first we had was did we work directly with content designers during the research, and were they involved in the Alpha phase?

KAT THACKRAY: Yes, and no.

RICH BYRNE: I thought so, yes.

KAT THACKRAY: We worked with an amazing content designer called Amy Heap, if anyone needs one, I would recommend. We didn’t get her involved until we knew what we were building. Then she was a really integral part of the project team. Everything we put in front of people, she had written. She was also very involved in knowing what we had found during the Alpha phase. It wasn’t perfect because we were sort of doing a download and explaining here’s why we’ve got this in here, and here are things to be aware of, here’s the kind of tone of voice that we have experienced as being the most useful. So yes, most of that work was done during Beta.

RICH BYRNE: Yes, I definitely remember working with Amy, and panicking her slightly when we realised that the text bot service has limited characters. We had a very nicely defined question order and set of questions that were clear and verbose and accurate but the text bot was limited I think, to nine hundred and something characters including punctuation. So to be consistent and to match the site, we had to re-ask the questions, or split them again. Amy was great at working those out, and also spent a lot of time working out the wording for services, and how they should be represented. All of the content through the site.

KAT THACKRAY: Yes. Every single service in the database, Amy wrote the description for it, so that young people would know what it does, who it was for and how it could help them.

RICH BYRNE: And again, that had to get approved and checked and went through many iterations. So yes, it was a process for sure.

Hopefully that has helped answer that question. The second one is more about Wagtail, about how we identified the blocks and modules needed for the content types, and was that part of the user research too. I’m going to cover the first bit, but Kat, you can probably correct anything I get wrong.

We used, as we’ve mentioned throughout, the NHS Digital Service Manual and design system. What that comes with is a huge list of components to use, things from buttons, radio buttons, check boxes, warning call-outs, notes. These are all the elements that you see on NHS websites. What the design system describes in a lot of detail, as well as giving you an example of what it looks like, is also when to use it, when not to use it and how to use it.

So Kat, you will be able to jump in. We basically implemented the ones in Wagtail that we needed on the site. I think they did come from user research, when we were doing that content to work out whether this is a warning call out, for example, that needs to go here, or is it just a note? Is this a check box question or a radio question?

I think there was some discussion around the sensitive content as well. That very first question of how angry and aggressive that needed to be.

KAT THACKRAY: Yes, we had a lot of conversations with the clinical team about the best way to approach that. I mentioned earlier that someone who is immediately at risk of serious harm to themselves or others, really, that fits the style book – you just said the word and I’ve forgotten it.

RICH BYRNE: The NHS Digital Design System.

KAT THACKRAY: Thank you very much. That very clearly says that if you have to take immediate action, it needs to be red. If you have to immediately go to A & E rather than your GP, it’s red on a black background. If it’s just a note, then it needs to be yellow. We followed that and put it in front of young people, and they were really turned off by what was probably immediate action, and higher than GP level. This is the crisis team that we are suggesting you call. So, we used the red and black and it really did not go down well.

I think something that’s interesting is that we came into the project with a lot of people saying, we want to make it friendly, we want to make the design kid-friendly and approachable. But actually, all the people we spoke to, well, most of them who expressed an opinion anyway, but the NHS style guide actually tested really well. Not patronising, it felt safe, it felt reassuring, it felt legitimate. All of those really important things you need when you are fourteen, seventeen, eleven and looking for help.

So yes, we did deviate ever so slightly from that style guide in a couple of cases, but it was always for research based reasons.

RICH BYRNE: Thanks Kat, I was going to mention that. It could be quite heavy to see an NHS based site, but I guess that familiarity, and knowing that it is a legitimate thing possibly helped in that it tested well with young people.

We’ve just had another question come in, actually, which was really interesting. I think we’ve got time to try and respond.
The content can be quite heavy around mental health. Did you have anything in place for yourselves on how to deal with that? I can go first if you want, while you have a think.

I would say no, nothing immediately direct. Fortunately for myself, and the engineering side of the team, we are tangentially involved in the user research, hooking up with Kat and her team about what had been found. So it was more about making sure the content was there, and that it was in place. We did have a mentor in place throughout. It’s just how important this service is, and how important it is at the end. So when times did get tough, and there were late nights and things like that, just reminding ourselves how important it was helped me to get through it. Fortunately, I was a little bit more removed from the immediate harder discussions, which possibly helped me with that. We definitely kept in mind who we were doing this for. The user groups were definitely at the forefront during this development, for me. Kat, was that the same for you?

KAT THACKRAY: We have a bit more of a process. We have a whole guidebook on sensitive topics, protecting researchers and participants, which I touched on a little bit earlier, so I won’t say too much on it here. But yes, we did have support available. We’ve got counselling available through our standard employee health scheme. Also, I’m one of the leads here, so I am responsible for team dynamics and modelling what is and isn’t appropriate behaviour.

One thing that we will always do in a research team is just to be really open about – this is my previous experience in this field and I am happy sharing it. You are welcome to if you need to, and you don’t have to. Here is some other support that is available. Also, having those conversations. I found that really tough, actually. So, just a little time to decompress afterwards, and acknowledge in a safe space that this stuff is hard, really helped us to get to the end of the day not carrying a bunch of heavy stuff.

Sometimes we did. Sometimes we heard really sad stories. There are a few songs I couldn’t listen to for a couple of months after we finished the project. But mostly, that peer support and open safe space for saying, ‘that was hard, could you be in for the next round?’, was really helpful to the research team.

RICH BYRNE: Thanks, Kat. Thanks for sharing. Actually, thinking about it more now, that was what it was like for our team as well. We just shared a lot and talked a lot. We worked together and worked in pairs. There was constant discussion, we had a lot of meetings together and shared group activities and fun times as well, just to help. And counselling things were available if we did need it, through Made Tech.

Again, just remembering who this was for and why we were building it, was certainly what will stay with me. We have reached time, and in fact, we’ve gone slightly over. As I said, there will be a feedback form going out after this. If there is any feedback, whether it’s content, more things that you would like to see, if you want to hear more about this or more specific things around certain areas, more about the tech or more about user research, or more about the project in general or what’s in the future, do let us know.

If there are any other questions, do let us know that too. Otherwise, you can also stay in touch with us at our various website or our Twitter accounts at Made Tech and Mason Menter.

Thank you very much for your time today, thank you Liam and Kat for discussing the bits you did, that was fantastic. And Anna as well, who has been running the slides behind the scenes. Couldn’t have done it without you. Thank you very much. Have a great rest of the day and take care.