Learning that compromise doesn’t equal failure

I was on holiday in Africa this week, leaving product behind and heading for the mountains and the sun.

Whenever I’m away I tend to keep a sneaky eye on anything involving developers, because issues that arise there are usually the most complicated to fix, and I’m the one who knows what shade of yellow all the balls in the air are.

Mostly I decide things can wait, but occasionally I’ll step in if I see conversations heading towards a consequence that hasn’t been accounted for.

When that happened during my holiday this week, it made me wonder whether imperfection is inherent to product management and whether that might not just be a reassuring fact, but also a positive one that leads to better overall results.

Playing out on Podio this week I could see my team trying to fix something in a way I knew would break something else. They’d done all the right things; figured out the problem, consulted with a developer, kept people informed and agreed a fix.

When I jumped in and got them to revert their decision, it made me stop to notice that they were dealing with a problem that, in the timeframe, didn’t have a correct answer – there were two paths and the one I pushed them to take was still wrong, just less wrong than its alternative.

These are the types of decisions I make all the time, but on each occasion a tiny bit of me feels like a failure; I didn’t find the third way, I couldn’t get everybody to win before the clock ran out and I had to settle for something less than what I wanted.

Watching a great team of capable people going through the same process this week made me not only resolve to cut myself a little more slack in this area, but also gave me the opportunity to reflect on the benefits of that rock and hard place situation. There will be a third way for next time and getting back to work on Monday will allow me to find it, but will also give me something I wouldn’t have had if the issue had been easier to solve.

These trickier problems and craggier paths to success lead to the pondering, consulting and late night googling that make us good, better and then the best at our jobs. They’ve led us to find the third way more often than we’ve ever stopped to notice. The development is gradual, but the only way to achieve it is to keep clashing with the issues that don’t have an obvious answer and use what we learn to keep moving forward.

What I learned from five minutes with a user

General Assembly at the moment are running a series of free introductory seminars in various specialist areas. They’ve been great, I’d definitely recommend signing up to a couple if you have the time.

Last week I went to one on user experience design and I thought I’d share a highlight of the session.

Usually when a speaker says “I’d like you to get into pairs” I get an internal sense of dismay. After all, if I relished opportunities to make awkward chat with humans I didn’t know, I wouldn’t be working in digital.

However, what I have realised over the last five years is how much I love user research, and fortunately that was the task we were set in this session.

We had five minutes to imagine we were working on improving the Citymapper app and run user testing with the person next to us about their experience of using it, in order to make informed recommendations about what could be improved.

The most interesting challenge with my partner, I’ll call him Adam, was that he was very distrustful of apps generally, particularly apps that asked for access to his location. He felt ill-informed about how his data might be used, and uncertain about the location-driven apps he downloaded having access to other areas of his phone.

Adam had never used a travel app, when I asked him about the methods he preferred for navigating London, he said he would use the TFL website. This started as a productive line of enquiry as we went through the way he used the site, but it soon became clear that he didn’t have very high expectations of TFL, it was simply ‘fine.’

Fine was enough for Adam when it came to maintaining his digital privacy. When I asked him how he would get around outside of London, he said he would ask for directions or take a printed map of his journey – that was how strongly he felt about protecting his identity online.

Thinking about the app design brief, I wanted to get to more than ‘fine’ with Adam, I wanted to know what would make a digital experience great for him. So I started asking him about his favourite non location based app.

It took him no time to get out his phone and show me a radio product he loved, and the most interesting thing about this was how much of what he said could be applied to the development of the Citymapper app.

On the radio app’s home screen, there were six content categories – things like ‘popular now’ ‘stations’ and ‘favourites.’ Though the ‘favourites’ option was in the bottom left corner, not the usual position of popular actions, Adam went straight to it and started showing me around. This indicated how important personalisation was to him, something really useful to explore with users in the context of the Citymapper app.

I then asked him to show me how I might use it as a first-time user, to get an idea of the journey he might have been on when he first signed up, and what he liked about that.

He showed me the search function and commented on how good the app was at returning exactly what he was looking for really quickly – another useful insight for apps more generally. The interesting thing about that search function was how it remembered his latest query and then made suggestions on what his next one might be.

He said he found this feature surprisingly accurate and  that it had introduced him to new stations he wouldn’t previously have come across. It was clear from this that he had begun to trust the app and let it guide his behaviour and propensity to try new things – another great example of something that could be explored more generally in the development of other platforms.

The whole task was a great reminder that good digital experiences come from putting the person before the product. To learn these things in five minutes made me really excited about some user testing I’m running for Breast Cancer Care next week. If you haven’t done any for a while, I hope this can be some inspiration!

Adopting a ‘start where you are’ approach to digital

A few months ago, I went to one of the really great (and free!) digital seminars run by Precedent Communications.

The main takeaway for digital progress in an organisation was to “start where you are”, which was interesting for me as one of the things I was working on at the time was creating a tool for the site which would allow all supporters to share examples of having challenged mental health stigma in their community, school, workplace or daily life.

As the needs of each group were so similar, I was keen to find a way to unite them into one resource that would work for everyone both internally and externally, without any UX compromises that would undermine the value and potential of the tool.

At the same time, I was aware of the need to view the tool’s creation in the context of other interactive areas of the site, to ensure we weren’t reinventing the wheel and dividing supporter attention between similar actions.

In ascertaining requirements, both internally and among key supporter groups who had initially expressed a need for the tool, I identified a significant functionality overlap between this project and something we had previously produced to support our national campaign drive in 2015. The campaigns team had been keen to find a way to ensure this bit of the site remained relevant beyond the campaign, so to my mind, this was a perfect opportunity to test out the “start where you are” philosophy.

Adopting this approach saved us a lot of time and money; we were able to get the tool built easily within our usual monthly sprint turnaround, and for just over £1,000. Most importantly, we were deploying to live having already worked out any UX kinks from the previous iteration, giving us a valuable product from the outset that supporters immediately began to take advantage of.

I’ll definitely be incorporating this into my thinking again!

Removing redundant web content

This blog is about removing redundant web content from a large site.

Before I start, I should say that a much more sensible person would have got an agency to do this. At several points during the process (which I started in October) I’ve thought I was being far too stubbornly INTJ about the whole thing and it would be easier to hand it over to a bigger team of people who could work on it full-time. But it was interesting and technically achievable – I’ve come to realise I can’t say no to anything that can be described like that.

What were the issues?

During my first year at Time to Change I’d slowly been discovering a lot of redundant content. A lot of it was unnavigable, which I think was part of the problem – whoever created it had left, forgotten it was there or for whatever reason abandoned it to float around the website without its parents. It happens in any organisation, perhaps particularly in busy charities where everyone’s working at such breakneck speed that the phrase “just get it up there and we’ll deal with it later” can become common by necessity.

The tricky thing is that nobody does deal with it later, because we’re all straight on with the next cripplingly urgent thing. And so it continues until there are are over 5,000 out of date pages that no-one but Google has time to notice.

A crucial part of this was that we didn’t have a system for forcing parent page assignation, so bypassing this step and saving everything as a page in its own soon-to-be-forgotten-about right became inevitably common practice overtime.

A further contributor to the problem was that we had no processes in place to deal with content that had a known shelf-life, so community event listings from 2011 continued to sit there gathering dust in the absence of an agreed way of unpublishing and redirecting them.

How did we address these?

As well as dealing with the content that needed to be removed, I’ve been keen to make sure we improved our set-up to negate the need for such a time-consuming audit in the future. With a bit of development, now when people add content to the site they’re asked to assign a parent by default, and an auto-generated url now inherits that breadcrumb trail as standard.

To deal with the event listings, I’d hoped for a module that would manage these automatically based on a set expiry date, but the slightly more laborious alternative of manually setting an auto-unpublish date when approving the listing and then using Siteimprove to pick up the 404 for redirecting is a fine substitute.

Incidentally, Siteimprove has also been great for us in a number of other ways, and I found you can haggle them down fairly substantially from their opening service offer, I’d definitely recommend them.

How did we ascertain the redundant content?

Although we can export all pages on the site from our CMS, I wanted to make sure we knew which were the high performers so we were making removal decisions within an informed SEO context. With that in mind, I picked the slow route of exporting them 5,000 rows at a time, in rank order, from Google Analytics. 

Once I had a master spreadsheet of 17,000 pages, I looked through the first hundred or so to identify any top performers that might also fit the removal bill. Happily there weren’t any I could see that ticked both boxes – top performers were, as you’d hope, well used and positioned pages, or personal stories and news articles that remain indefinitely evergreen.

With that reassurance locked down, I could sort the spreadsheet alphabetically as a way of identifying groups of similar pages – e.g. blogs, news stories, user profiles and database records which we wouldn’t want to remove. It also identified duplicate urls and other standard traffic splitting mistakes. I then selected and extracted these from the spreadsheet, cutting the master down to around 10,000 pages.

Next I wanted to filter out the dead links, because we now had Siteimprove to pick these up and a weekly digital team process of redirecting highlighted 404s crawled by the software, so they didn’t need to be included in the audit.

As GA exports urls un-hyperlinked and minus the domain, I needed to add these in. I used the =concatenate formula to apply the domain and the =hyperlink formula to get them ready to be tested. I then downloaded a free PowerUps trial and ran the =pwrisbrokenurl dead link test for a couple of days over the Christmas holidays. It’s worth saying my standard 8gb laptop struggled a bit with this, so if you have something with better performance, definitely use that.

PowerUps divided my data into broken and live links so I could filter out the broken ones and be left with an updated master spreadsheet of every page that needed auditing by the team. There were just over 6,000, which we divided between us and checked on and off over several weeks, marking them as either ‘keep’ or ‘delete’ and fixing the url structures and parent assignation as we went.

That process identified 1,000 relevant and valuable pages to keep, and 5,000 redundant, out-of-date and trivial ones to remove. Past event listings make up a large proportion of these, but I’d also say you’d be surprised how many other strange things you find when you do something like this!

What’s next?

Now we know what we’re removing, I’m going to get a temp to unpublish and redirect it all, which I hope will take about a week. From there I’m going to look into how we might go about permanently deleting some of the unpublished content, as a spring gift to our long-suffering server.

Once that’s done we can move onto the content we’re keeping, so the next phase of the audit will be about ensuring everything left behind is as fit for purpose as we can make it – I expect this to go on until the end of the quarter.

That time should start to give us an indication of Google’s response to the removal of so many pages. I’m a bit nervous about this and prepared for an initial dip in traffic, but by Google’s own standards I’m hoping for a curve that looks a bit like this:


I’ll keep you posted!

Upscaling server capacity – part 1

At Time to Change we generally get around 1000 visitors to the site a day. On peak days, like World Mental Health Day, this might double, but there’s enough flex in our server capacity to manage that without issue. Once a year though, the first Thursday in February, we run Time to Talk Day – a massive single day campaign to get the whole country talking a mental health. We’re lucky, it’s very successful, bigger and better every year we do it – just last week I was in a meeting with someone from an agency wanting us to pay to trend that day, we were all quick to point out we organically trend all day anyway, without paying a penny. Very, very lucky.

The downside though, if we can call it that, is that we’ve now reached a point where our site’s infrastructure is not equipped to deal with the spike in traffic, which last year reached 32,000 visitors and tripled the time it took pages to load for supporters wanting to take part in the day. It never went down, which was a relief, but it was painfully slow, despite our most ambitious estimates and load tests in the preceding months.

So it’s my job this year to make sure we’re ready, not ready for a sensible growth on last year, but really ready for the kind of numbers we feel arrogant even talking about – just in case. In previous jobs I’ve just called the hosting company to increase the server capacity, maybe even kick a few smaller charities off to give us maximum breathing room. But the issue at Time to Change is we’re already on the biggest physical server, at its highest capacity, so the standard option isn’t an option for us. Ruling in and out the various alternatives has been pretty stressful as they all carry risks and, as ever, it’s a ridiculous time of year with millions of other urgent things happening at the same time.

So what are the options?

  1. Caching – improving this made a great dent in our performance by increasing our capacity by 20%, but we need more than that to get through Time to Talk Day
  2. Move to a virtual server – this does solve the immediate issue as the capacity is exponentially better, but then we’re left with a problem of poor performance due to underload the rest of the year, so it’s not a good long-term solution
  3. Temporary, reversible migration to a virtual server – this is a possibility but a very risky one as you never really know how your site’s going to perform in a new environment until it’s had some time to bed in and be tested to its limits in a live setting – none of these we really have time for
  4. A microsite – if I was a web developer I’d probably go for this, move the entire problem into an isolated container that guarantees the stability of the main site? Sounds perfect. Unfortunately I work in comms and microsites are a brand and UX sacrifice I can’t live with, so we’re not doing that
  5. Varnish – the Iron Man of caching systems it turns all your dynamic content static (except the bits we need on the day) and improves performance by about 50%
  6. Match our current server with another and load balance on the day – like an overflow unit for when the traffic hits its peak

I’m going for 5 and 6, we’ve got just over a month to get it right and in the meantime I’m site auditing our 10,000 pages to make sure we’re only working as hard as we need to. In part 2 I’ll let you know how it went!

PS – another way to find out is to take part in the day, 4 Feb 2016, let’s get the nation talking about mental health.

How Mind managed to publish breaking news, from 2011

Today a totally ridiculous coincidence happened, which I want to document somehow since it was fun to fix and will probably never happen again.

What happened

When Mind launched their new website back in November 2012, we hired a keen team of digital volunteers to set about the tedious task of migrating content from one site to the other. Mind has a huge site, it was an endless and dispiriting task which we eventually decided to shelve, once the main content was over.

What we left behind were several hundred old news stories and blogs, back as far as 2010. Since then we’ve had a fair amount of internal and external pressure to bring the rest across, none more demanding than Moz.com and its hard to ignore report of 404 errors resulting from dead inbound links. Google is our master and we’ve been willing anarchists causing SEO chaos all over the internet, it was time for action.

A few weeks ago we decided to revisit the monster; exported the dead links in priority order and hired someone to migrate them. He’s been doing his job excellently for most of every day since he started, all’s been fine.

Today, we had an announcement to make, a lot of work went into getting as far as launching the story and the last bit was the news article – no big deal. The media team added the news story, naming it “Mind Media Awards: shortlist announced”, which naturally inherited the standard url format taking into account its structural position and title. All fine.

Elsewhere in the office, not 20 seconds before this happened, our patient content migrator had published a story, from the hundreds he was working through, called “Mind Media Awards shortlist announced”, a defunct page from back in 2011. Not a risk, right? Our CMS is smart enough not to let us name two pages the same thing, that would be silly. Except that he didn’t, there was no colon in his news story, so the website says “fine, these are different things, you can have both.”

But back in the 1970s, a group of nerds at Ascii decided characters like colons in a url pathway would probably confuse or break things, so decided to omit them, which means servers don’t read that they were ever there, even if good CMSs like Umbraco are fine with the whole thing.

At 4pm we tweet our release and point to the news story – right before some sharp-eyed tweeters alert us to the fact we’ve sent out a story from 2011. I’ve been managing the migration guy while my boss is away so know straight away what must have happened (and what a ridiculous coincidence! Of all the hundreds of urls on that list!)

To solve it, I set up a 301 from his content node to ours. Only of course it doesn’t work, because Umbraco knows they’re different, but the server’s thinking “why are you making me serve this page in circles you strange person, what kind of digital officer are you?” And I’m thinking “how on earth did this all happen at the same time?!”

The resolution

We delete the migrated page, change the url of the news story and set up a 301 from the old to the new. Sorted. 15 minutes of team-awe ensue, while the rest of social media is none the wiser.


What’s wrong with irresponsible reporting around suicide

Yesterday the world received the sad news that Robin Williams had taken his own life after struggling with addiction and depression for many years.

Despite its prevalence, depression is still a much misunderstood illness and mental health organisations, along with their supporters, fight hard to ensure it has parity of esteem with physical health conditions.

A lot has been achieved in recent years, through huge national campaigns such as Time to Change, as well as the work of leading mental health charities like Mind and Rethink Mental Illness.

As ever, the media have a huge role to play in shaping public attitudes towards mental health, as well as a responsibility to report on suicide in a way that is neither glorifying nor triggering for the millions of people around the world who are struggling.

The first tweet I saw about Robin’s death was the beginning of what I knew would be a shameful few days of irresponsible messaging which can, ultimately, claim further lives.

This post by The Academy is intended to be a well meaning tribute to the star’s work as the Genie from Aladdin. It has been retweeted over 3000,000 times so far, as undoubtedly kind hearted people from all over social media continue to share it in Robin’s memory.

They shouldn’t.

Despite its good intentions, what this post says is ‘when the pain gets too much, there is a way out.’ Wanting it all to stop is such a common feeling for people who are struggling with suicidal feelings and the media cannot continue to portray taking one’s own life as a peaceful solution to all-consuming depression. It isn’t peace, freedom or tranquility, it’s death – a permanent end to everything you are.

It’s dispiriting to have to talk about them but, as ever, the tabloids deliberately abused well established media guidelines on responsible reporting about suicide. If there’s one rule which everybody in the industry can’t help but know, it’s that you never ever mention methods. Doing so is akin to publishing an instruction manual to vulnerable people on the most effective way to end your life and leads to what researchers call ‘contagion’ or copycat deaths.

Particularly horrific examples include:

This is not ok and the Samaritans guidelines on responsible reporting are freely available for anybody who’s unsure, please do read and share them when you can.

Now that they’re out there, it’s not too late to make a complaint and help make sure these guidelines are followed. You might just save a life.

Three problems with the no makeup selfies for cancer

A month on and there’s no denying the success, in fundraising terms, of the no makeup selfies for cancer. They raised millions for Cancer Research UK, the first to spot their potential and channel participants to a text giving account.

The campaign ticked all the boxes for creating sharable content – it was image based, easy to do, involved a small twist on everyday photo sharing and was perfectly set up for social media.

Nevertheless, as soon as the campaign began, three niggling questions burned away in the back of my mind:

What does not wearing makeup have to do with cancer?

I love creating sharable content, it’s exciting, it’s satisfying, it has the potential to drive change and lead to something positive – it’s a great thing to be part of.

That said, taking a sharable action and tenuously uniting it with a disease that affects everybody is lazy. It undermines the communications industry and places organisations which focus on high profile causes at an unfair advantage.

It’s important to remember that the no makeup selfies were successful for two reasons, both the content and the cause. If we take away the cause then it’s a good idea, but it’s nothing new or groundbreaking. Cancer was the key ingredient which guaranteed viral, inspiring, money making success.

Good digital media campaigns need to be meaningful, justifiable and contribute to wider learning about what works and what doesn’t. This campaign doesn’t help smaller organisations working hard to change the world, because all it teaches the sector is that people really, really care about cancer.

If this is being linked to bravery, isn’t that appallingly insensitive?

Amid the confusion was a rumbling implication that the no makeup selfies were in some way linked to bravery. Throughout the campaign I saw a number of references to a genuinely brave woman who had had a double mastectomy and who shared a photo of her body in order to raise awareness and tackle the fear and stigma associated with the operation.

To suggest that everyday women taking makeup-less photos of themselves on the way to the gym was in any way an act of bravery, in this or in any other context, demonstrated a shameful lack of empathy for the millions of people struggling with the terrifying reality of having cancer.

Isn’t this whole idea a bit cringingly anti-feminist?

Finally, feminism took a real hit during this campaign and watching social media overflowing with women making demeaning and pro-patriarchal statements about themselves was intensely dispiriting.

“It’s all for a good cause” is no reason to send social progress careering back to the turn of the twentieth century. Women gave their lives to free us from these condescending stereotypes, so let’s please not forget there are plenty of other ways to give money to charity.

You could do it right now, here’s everything you need.