When I first started as a Digital Product Manager at Breast Cancer Care, I was aware that I had a limited window of impartiality, so I decided to use it to conduct a front-end audit of the site. I wanted to see what some of the main challenges of the role would be before I knew anything about our digital history or ways of working.

At the end of the audit, I’d examined every forgotten corner of the site, identified the areas I felt presented the biggest user experience challenges and created a list of seventy-six questions I wanted to spend the next few months gathering answers to, either internally or through user research.

A key challenge to solve

One of the biggest issues I noticed was our tendency to create microsites for every new campaign or fundraising activity. Internally this was taking a great deal more time than it needed to, and meaning quite small pieces of work were stealing the team’s attention for months at a time.

Externally I worried about the user experience implications of treating each activity as separate from the site as a whole, particularly as the microsites were so difficult to navigate to and from, and often contained a number of subsidiary pages that took users away from the actions we wanted them to complete.

Talking to people around the organisation, I realised a lot of this practice had developed because the site offered internal teams no good alternative. We didn’t have a sophisticated suite of content types to cater for the various ways we wanted to engage the outside world in our work, which left staff little choice but to begin almost entirely from scratch each time.

How we tackled the problem

To solve the problem we started working with the design agency William Joseph to create a new suite of content types, so that the site could better cater to user needs as well as our internal requirements. The first type we began working on was a flexible, modular and mobile-first campaign template, which is currently being used to showcase eleven of Breast Cancer Care’s key campaigns and fundraising activities.

Following the success of this approach, we set about creating a full suite of new and updated content types that are now in use across the site and better meet both the user and our internal fundraising, campaigns and information needs. These include types for:

• Campaigns
• Navigation pages
• Personal stories 
• Patient information
• Fundraising events
• Support events
• Statements
• Press releases

The end result

Through this approach we’ve found an enormous reduction in the time and resource needed to create engaging content during key campaigns, activities and other peak periods.

We’ve been able to up-skill digital champions around the organisation to create more of their own content and reduce reliance on agencies to create landing pages on our behalf.

Brand-wise, the site has benefited from a vast improvement in standardisation and consistency, which proved difficult to achieve with so many agencies each interpreting our brand guidelines in slightly different ways.

Finally and most importantly, we’re now in the second year of using our new suite of content types and have seen a marked improvement in engagement and conversion to our key activities and campaigns.

If you’d like to see an example of a campaign page in action, you’re welcome to sign up for a Pink Ribbon Walk this summer. (See what I did there?)

This post was first published via Just Giving.

In the last few months, I noticed our support bills with external developers had slowly been creeping up, so I created a workflow document to manage the way we’re using helpdesks internally.

Although it’s a very low-key, totally internal workflow chart, one developer mentioned that quite of few of his clients ask for similar guidance, and asked whether he could share it more widely.

I hadn’t really considered it might be something useful beyond our team, but he made me realise this is probably quite a common problem, so here’s a format-free copy in case it’s useful for you too:

What’s the issue?

A new requirement: 

1. Have the team given you a full and robust description of what they want?
2. Would what they want provide significant value for Time to Change?
3. If yes, give full brief to Becca
4. Becca puts in development sprint
5. Becca manages sprint, UAT and deployment

A problem with something that used to work:

1. Have the team given you a full and robust description of the problem?
2. Is it broken for everyone, are they using IE, remote desktop, or another likely cause?
3. Can you easily / routinely resolve it yourself without any unknown implications?
4. If difficult to resolve alone, have you discussed with the rest of the digital team?
5. Before escalating to a developer, is it critically urgent, or if not, has it been consistently broken for two days?
6. Have you described the full problem and expectations for resolution in one simple Podio message?
7. Once actioned by the developer, does their solution match or better what you asked them for?

If you’ve had similar problems, l’d also be really interested to know how you’ve solved them!

As Time to Change is a social movement, sharing personal stories from people with experience of mental health problems is an essential part of our content strategy.

A lot of these stories we commission from the general public and host on the Time to Change blog, but we’re also a big fan of amplifying user-generated content, to strengthen the voices of people who will ensure the movement  can continue long after our funding runs out.

As we’re such a big campaign, a lot of user-generated content comes directly to us without much effort on our part. People write blogs or produce video content and tell us about it, knowing we’re always looking for great things to share more widely.

But what this doesn’t allow us to see is all the amazing people out there who are fighting for the same things, but doing it alone. Harnessing these voices really drives the campaign forwards because, as well as being stronger and louder together, every person who produces content for themselves has the potential to inspire someone else to do the same – building the foundations of a sustainable legacy.

In order to reach these people, we needed a social listening tool that would show us all the content being produced around the world that related to mental health and stigma. Google is a great tool for finding the top ranking HuffPo and Buzzfeed articles, but those need no amplification, what we wanted was to find everyday people who had powerful personal experiences, wanted to change the world and would inspire others to do the same.

We looked at four platforms that would do this, along with the other operational requirements we had. They were:

• Tracx
• Brandwatch
• Pulsar
• Meltwater

Having interviewed them all, we landed on two finalists. The first we picked didn’t work out, they had a few development issues they couldn’t resolve and I didn’t want to keep paying for something that didn’t work properly, so we switched to Meltwater, who have been fantastic.

We’ve been with them a few months now and they do everything we were looking for to help make our social media as good as it can be. We aim for every post to get 600 engagements and 60,000 reach, but invariably our user-generated content found through Meltwater vastly outperforms this, growing our online community and spreading our message of change to a wider audience. This month our top user-generated post gained 8,700 likes and 1.3 million reach – all made possible with a couple of clicks in a pre-built search.

If you’re thinking about using social listening more, for this or the many other reasons, let me know and I can share my notes on suppliers we spoke to.

In the meantime, here’s a lovely post from someone whose blog we shared this month!

Over a year ago now, I blogged about Samaritans Radar, a tool created by the charity that caused a lot of controversy amongst the strong mental health community on Twitter and elsewhere.

I agreed with a lot of the issues people raised, though for me privacy wasn’t top of the agenda, my worry was more around the obligation it placed on individuals to take responsibility for the safety and welfare of others – something our Government should be doing and, increasingly, isn’t.

Since then, Samaritans have been working on an alternative, something I was vaguely part of in the early stages, attending a couple of round-table feedback meetings and sharing my own experience of managing these issues on social media, in an interview format with the Samaritans digital team.

This week, Facebook have launched their suicide prevention tool in the UK, which takes elements of what the Samaritans wanted to achieve with Radar but looks, at face value, to be safer and better.

Three great things:

1. Anonymity for the person flagging that content to Facebook, which means they can look out for their friends without feeling alone and overwhelmed with the responsibility for keeping someone safe

2. A practical and empathetic support journey for the person who’s feeling suicidal, including a prompt the next time they login

3. Support options which connect them (anonymously and by choice) to the Samaritans, who are trained and able to provide the right help. They also get the option to connect with a friend – something that might feel more possible once you know for certain that at least one person in your network is worried about you.

In general I think there is a place for providing interventionist support within social media platforms, but I do have some reservations about the term ‘prevention’ and its potential to reduce the pressure on other agencies to create a society where 6000 people a year don’t attempt and succeed in taking their own lives.

I’m also wary of the passivity of asking for help in such a vulnerable and indirect way – if people need help they should believe in our systems enough to know they’ll get it, but since so much evidence into crisis services suggests that they won’t, people are left posting on Facebook and hoping somebody cares enough to respond.

Image credit: Felicity Morse, BBC Newsbeat.

Last month I blogged about how Time to Change would manage the exponential increase in server load caused by our annual marking #timetotalk day.

I talked about having six plausible options for managing the load and about the decision to choose a combination of Varnish and an additional overflow server to cope with the day’s traffic.

Setting these up was relatively painless but did involve a last minute need to migrate the whole site to a new primary server, because Varnish, for want of a better explanation, didn’t like the old one. Once that was done we were basically all set, we just had to make sure it excluded the dynamic tools we needed to run in realtime.

What was load like on the day?

Traffic levels were pretty much in line with what we expected, an increase on last year and way more than our standard infrastructure could have handled – in the end just under 50,000 sessions in 24 hours. Social media was a big driver to the site, with just under 60,000 tweets on the hashtag throughout the day – trending until about 5pm, and then again in the evening.

How did Varnish perform?

I can’t recommend Varnish enough – we set it up to manage load balancing and it handled just over two million requests through the day and barely broke a sweat, we used only 10% of our primary server’s memory, going nowhere near the overflow at all, and page load speed was a satisfying 3.2 seconds – it was perfect.

How was everything else?

Ironically after all that, our database ran into a bit of trouble around lunchtime, processing so many form requests that it crashed for around 10 minutes. But that was minor and we’ll upgrade it and increase capacity for next year – watch this space and, in the meantime, get installing Varnish!