3 things I learnt from working in a more digital way

Just over a year ago my team and I were set the challenge of cracking cold acquisition for mid value supporters. We were asked to figure out how to get in front of people who had never interacted with Cancer Research UK and persuade them to give to us at £25 a month or above.

Most people start giving to charity at the lower end of the scale, around £2 or £5 a month, and traditional methods of acquisition (telemarketing, door to door) are in decline. We knew this wasn’t going to be easy.

However, in our team we’ve always championed an entrepreneurial spirit and have aligned ourselves with the words of Henry Ford: “If you always do what you’ve always done, you’ll always get what you’ve always got.”

So, we decided to try a different approach.

There are many benefits to working at Cancer Research UK, with one being our infrastructure and support network. I started speaking to colleagues about the problem we were trying to solve and was quickly put in touch with various people in our Technology directorate. I was grateful for the help, but I must admit, at first this direction confused me. I didn’t know if what I needed was a technical or digital solution. But working with these teams soon opened my eyes to a new way of working, a culture and confidence to explore problems that don’t always find their answer in the shape of an app or a website.

Our approach came in the form of a spoke. A spoke is a dedicated project team made up of experts from a range of tech teams, here to upskill me and my team to help us move forwards and fix the problem ourselves. The old ‘give a man a fish and he’ll eat for a day, teach him to fish and he’ll eat for a lifetime’ adage.

There were highs and lows, and many bumps in the road. However, we were in it together and when times got tough there was humour, the pub and Beyoncé...

Here are the 3 main things I learnt working in this way:

1.       Words matter

Our team are now well versed in agile language and have embraced Slack, Trello, demos and retros. However, it has left some of our colleagues a little bewildered to say the least.

Our project relies on collaborating with a number of teams, gaining their buy in and ensuring they’re as excited as we are about what we’re trying to deliver. This is dependant on communication. Since working in the spoke we’ve tried to reach a balance of intrigue with our language as well as clarity. It’s easy to get sucked into the agile world and wax lyrical about ideation, stretching and building, Kanban and scrum, retros and demos. But if people don’t understand you they won’t back you. They won’t be able to get excited about something that doesn’t have meaning to them.

We now have a Kanban board which allows us to work in the open – giving our colleagues a visual representation of our work that goes beyond the jargon.

Think about how you tell your story and look outside of your own team. Ask how you can phrase what you’re doing in a way that others will understand – and get excited about.

 2.       It’s hard. But that’s ok.

The innovation/design/new product development, or whatever you want to call it, process is hard. Things don’t happen in a nice straight linear way. You go over stuff again, and again. People disagree on how to do stuff, when to do it, and why we should do it. But this is all part of the process and if it was easy then we wouldn’t be being as creative as possible. The boundaries wouldn’t have been pushed, and we’d end up with what we’ve always got.

My top tips for when things feel hard is be honest with each other. Use retros constructively to openly and bravely voice your frustrations in a way that will better the group, not harm it. In one retro we used pictures of Beyoncé showing different emotions to illustrate how we’d felt over the past 2 weeks. This softened us giving difficult feedback to others and made it more comfortable to share.

         

Use team members where they are needed. We didn’t all have to be in the room all the time. Carefully selecting who was needed for what allowed us to be leaner and get things done quicker.

As a team manager, be there for your team, let them know that it’s ok if it feels slow, difficult or frustrating. Let them know that we will get there. But look after yourself. Make sure that you have a support network, so you can lead when it gets tough.

3. Talk to others who have been through it and share your story – pass it on.

One thing that I found super helpful was being put in touch with someone who had already been through the process. She could let me know honestly how much of my time would be taken up, where and when I would be needed for decision making, and the challenges to expect. As well as the advantages I, and my team, would gain by being a part of the process.

I now feel a duty to pass this on to others and will happily do so. Since I know how important and helpful it is.

We’ve been on a journey with this spoke and it’s transformed our team culture. We now have the skills and confidence to pursue our work in a lean way, testing and iterating our ideas and continually putting the supporter at the centre of what we do.

Spokes have a bright future but listening to people that have been on one will be key to ensuring they’re useful for others, both within and outside the spoke. And making sure they bring as much value as possible to Cancer Research UK and the incredible life-saving work we do.

Alice Larden
Senior Fundraising Manager (Mid Value)

Design Sprints at Cancer Research UK

Finding new, faster and more user-centric ways of working to help us beat cancer sooner is a core purpose of our team here at Cancer Research UK. For a while now, but more intensely so in the last few months, one of the tools we’ve been using to achieve that are Design Sprints.

So what are Design Sprints, and how can you use them in your organisation?

Design sprints come from Google, where design partner Jake Knapp started running them in 2010 with teams like Chrome, Google Search and Google X. Then in 2012 he brought them to Google Ventures – an important note, as Google Ventures doesn’t just deal with software companies, but with a variety of organisations. Here is Jake’s definition of a design sprint:

“The sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers. It’s a “greatest-hits” of business strategy, innovation, behavioral science, design, and more - packed into a step-by-step process that any team can use.*”

Sounds brilliant, right? But in practical terms… what does it mean?

In a nutshell: during a Design Sprint, a group of people from your organisation come together for 5 days, in a room, to try and solve a problem or answer a question. By the end of those 5 days, they will have come up with a potential solution, sketched it, built it – and what’s best, they will have tested it with real users.

Any team can try out a Design Sprint, and no challenge is too big to answer. To get started, here’s what you’ll need…

A team

Design Sprint best practice says that your team should be made up of 7 people or fewer. You can stretch this a bit, but we did find that smaller teams were more effective.

One of these people will be your Decider – someone who can move things along by making an executive decision when the group can’t. This role should be played by your problem or idea’s stakeholder. This ensures that whatever solution you end up building, they’re confidently bought into it.

Another person will be your Facilitator. This role requires a lot of energy, to keep the team motivated and on track throughout the week. If you have someone in your team who has some experience of Agile ways of working, this role might suit them well since they’ll be familiar with some of the activities that will happen in the Sprint – but it’s not essential.

As for the other team members, who you need depends partly on the problem you are trying to solve. In our Sprints, we try to always have a UXer, a ‘technical’ expert (for example, someone who knows your CMS, if you’re working on a website-based idea), someone with content and message strengths, and someone who brings a marketing/commercial point of view. At Cancer Research UK, we mostly self-organise our Sprints: it’s a brilliant opportunity to let teams organise around the work!

Remember: the strength of the Design Sprint comes from having a varied group of people working together for a short but intensive period of time. The wider the range of points of view you can bring in, the better! You might not all agree at the start of the Sprint, but you will have reached a consensus by the end of it (you will – I promise!).

Time and space

A Design Sprint takes 5 consecutive days. This may feel like a big commitment, but if you consider how much you will get done in those 5 days (and how long it might otherwise take to get there), it’s hugely productive. And after all, if your team can’t dedicate 5 days to this idea, is it really an idea you believe in?

Once you get more familiar with the structure of Design Sprint, you might find you want to shorten the process to 4 or even 3 days – but if it’s your first try, we found it better to stick to the 5 days.

You’ll also need a room, with lots of whiteboards, post-its, and sharpies. Try to use the same room each day if you can.

A challenge

What type of question can you try to answer in a Design Sprint? According to Jake Knapp, the bigger the challenge, the better the Sprint.

For example, we’ve used Design Sprints to:

• find out the viability of a new product
• review the roadmap of an existing one
• kick-off a new marketing campaign
• bring a fresh perspective on a problem when we were stuck

Design Sprints can be used for all of these questions – and more!

How do you start?

If you want to get started with doing Design Sprints, my advice would be to simply start! Many of us here at Cancer Research UK didn’t have any experience of facilitating a Design Sprint: we read the Sprint book (see footnote below), talked about it as a team, and then we just went for it. It might seem a bit daunting to dedicate a week to something you’ve never tried before, but what you will learn from designing, prototyping and testing an idea with real users in a week is so valuable, that it will be worth the initial discomfort.

And if you do decide to give Design Sprints a try, or if you already use them in your charity – we’d love to hear how you use them!

Giulia Merlo
Lead Proposition Manager

*Jake Knapp with John Zeratski & Braden Kowitz, Sprint: How to solve big problems and test new ideas in just five days, Bantam Press, 2016.

Making the move to agile ways of working

Starting at Cancer Research UK over 10 months ago, I had no idea what it meant to work in an agile environment. In all honesty, when I first heard the word agile, it conjured up images of sprightly employees making their way across the office, leaping through the air, before twisting and twirling into their designated meeting rooms. 

Realising I probably wasn’t quite grasping the concept, I decided to do some reading up before my first day. Article upon article told me that agile ways of working had sprung from thinking of new ways to manage software development projects which resulted in the creation of the ‘Agile Manifesto’. Surprisingly, unless someone was going to quiz me on the origins of agile, this didn’t really help me a great deal.  

There was only one thing for it, to get stuck in and learn as I went along. And that’s what I did. 

You won't have a clue what anyone is talking about...

… well for a few days (or weeks) at least.

‘So you’re used to waterfall ways of working then?’
‘Quick, it’s time for stand-up.’
‘Have you added it to the Trello board?’
'Are you working in Kanban or Scrum?’

Huh?!

As with any job you come into new, you soon realise that all the acronyms, jargon and technical terms that people throw around, are all just fancy words for something that’s not actually that complicated to get your head around.

Once you experience the tools, meeting and methods in practice, it all becomes a lot clearer and you soon get into the swing of things. And of course, when things don’t make sense, there’s always someone more than happy to explain it to you!

Your first stand-up will probably be a bit unnerving...

Stand-ups are a chance, usually once a day, for the whole team to meet for a quick status update and take place standing up (hence the name.)

My first stand-up experience, for want of a better word, was slightly unsettling. As each member of the circle declared to the group what they had worked on the day before and what they were planning to do the next, my turn crept closer and closer. As all eyes fell on me, two thoughts crossed my mind: 

1. Why is everyone so happy to let everyone know what they’re working on?
2.  I’ve not actually been here that long yet. What the hell am I going to say?!

First my defensive side came out. I was very much used to just getting on with a task and then delivering it and found the thought of sharing what I was working on very uncomfortable. Why did everyone else need to know? Why does it matter to them?

Then my self-conscious side came out. What if they thought I wasn’t doing enough? What if I worked on a different project the day before and hadn’t anything to say the team whose eyes were now fixed on me?

What I soon learnt was that stand-ups aren’t there as a forum for people to judge each other’s workload. Stand-ups are in fact a great way to keep things moving. Instead of just putting your head down and plodding away at a task until it’s finished, stand-ups give you the opportunity to air any concerns or barriers you may face, and allow you to quickly and honestly tackle them together as a team. 

You don't know your user as well as you think you do...

I’m by no means a stranger to putting the hours into researching what users wanted from their content. Pulling stats, numbers and data from various tools and reports. But one thing that I wasn’t used to, was taking the time to stop and actually listen to the users themselves.

My first experience of user testing was fascinating. Sitting in the usability lab, watching from a separate room through a live feed, I was able to watch real people interacting with pages on our site in real-time. Where some elements worked well, some aspects of the page, that as a team we’d assumed were obvious and easy to use or understand, saw the users struggling.

Agile is about responding to change. It’s too late to wait till the end of a project to ask for feedback, only to find what you’ve produced isn’t quite right. It’s about testing and listening to your users throughout the entire process. 

Taking our observations from usability testing, we were able to respond and implement the changes moving forward. The end result? You’re left with something that actually makes sense and works for your users.

For me now, users are not just an abstract concept. They’re real people, with real insights. So why not make the most of that?

Moving to a completely new way of working is always daunting and is almost always going to generate some scepticism.  But from my experience of working in agile, the benefits seem obvious. Put your users first, work together as a team, respond to change. Immerse yourself in these principles and you’ll be an agile advocate in no time. 

Can content ever be agile?

Content strategists often have an uneasy relationship with agile. We’re not as technical as developers. Not as obsessed with post-it notes as UXers. And nowhere near as hipster as most designers. Because of this, it’s sometimes tricky to figure out how content should work together with these disciplines. So we end up as natural outsiders. Mavericks. Loose cannons. 

Part of this boils down to our history. Like a lot of content people, I started off in print. And traditional publishing is very much waterfall. Fixed cost, fixed deadlines and fixed scope. So when I moved into digital, I had to learn how to retrofit those traditional publishing processes to digital content.

But I think a bigger issue is our obsession with being recognised. We’re a young profession, which means we often get sidelined, brought in at the end, or just generally underappreciated on projects. So to get around this, we decided to invent a bunch of buzzwords that people could reel off to get them thinking about content. That’s great – God knows the UX guys have enough of them.

The problem with these buzzwords is they encourage the idea of content as something sacred and holy that needs to sit outside of the agile process.

Content isn’t king

If you’re ever bored during a conference, count the number of times you hear “content is king”. I guarantee you’ll run out of fingers by the second presentation.

The problem with this phrase, is that ‘king’ implies content is more important than great UX. More important than awesome design and solid development.

It implies that those other disciplines are just there to do the grunt work to let your content shine.

And it implies that content doesn’t need to be iterative – it’s too important.

Quite frankly, it implies that content is a complete douchebag.

Rather than a king ruling over all he surveys, it’s better to think of content as the kingdom that connects all these different digital disciplines together. Yeah, your users come for great content. But great content needs awesome UX and design to deliver the best possible experience.

So understand these other disciplines

If you want to produce good content you should understand UX principles. You need to know what goes into making a design appealing. And you should recognise the pain points developers need to go through to make that ‘tiny’ CMS template tweak you’ve asked for.

I can’t stress how much easier it is to create great content if you’re working side-by-side with these other disciplines. If you don’t understand what your users want, then your content will suck. But if the UX guys don’t understand the best content to give to your users – well, your UX will probably suck as well.

As content strategists we shouldn’t be hung up on our content in-and-of-itself. Instead we should be focusing on how to use that content as part of a great digital experience. So next time you have the chance, attend that development standup. Be part of that UX workshop. Share an overpriced latte with a designer.

Learn about the other disciplines you’re working with – understand their challenges, and figure out how content can help.

Content first is a bad idea

For non-digital folk, content first implies a defined process. You do the content, then the UX, then the design, and then the development. Classic waterfall project management.

When people use this phrase, what they really mean is “think about content at every stage”.

The best agile teams treat content as an MVP to iterate on. Start off with your message, then hone, focus and optimise it over time.

This can make stakeholders uncomfortable. Mostly because they can never “sign off” the content, since it’s always changing based on the stuff you’re learning.

So how can we encourage this approach?

Never, ever, ever (ever, ever, ever) accept lorem ipsum

Well firstly, acknowledge that lorem ipsum is the devil. Seriously. If you take away nothing else from this post, it’s that content is linked tightly to UX and design.

Without real content your user is always going to have an artificial experience. And you’re never going to be able to feed back the insights you’ve learnt into making your content better.

So if you’ve got something to test, knuckle down and come up with a first iteration of the content. It doesn’t need to be perfect. But it does need to be actual, proper content you think your users will respond to. No Latin please.

Accept the idea of a content MVP

Then after testing, if you find yourself changing the UX or design of a page then re-visit and re-test the content at the same time. Now, take a deep breath and repeat after me:

•   if you do a UX activity, re-visit the content
•   if you do a design activity, re-visit the content
•   if your developer builds new functionality, re-visit the content.

Repeat this mantra as often as you can. Preferably on public transport, at important social events, or in a lull between meetings in the office. That way as many people as possible will recognise your commitment to content as something to refine and update over time.

Accept your content is only done when it’s left the website

And when you’ve finally published your content, remember that’s not the end of the process. Your users’ motivations will change over time, as will the way they interact with your content. So you’ll need to keep that content up to date and relevant.

If you take this iterative approach then make sure you build in metrics for success upfront during the planning stage. Then test those metrics 3 months, 6 months, 12 months down the line to check your content’s still performing well.

Making the agile jump

Hopefully by now you’ll recognise that content absolutely has a home in the agile process. It sometimes just takes a little extra coaxing into place than other disciplines.

At Cancer Research UK we’re trying to embrace this approach as much as we can. It’s tough, particularly for people who are used to nice, neat chunks of sketching, wireframing, designing and content-ing (if this isn’t a word it should be). But it’s the best way of using content to create a properly joined up experience for your users.

So take a deep breath, and leap into the agile content mindset. I promise, your content will be better for it. And it won’t hurt. Much.

Chris Flood

Content Strategy Lead

Why should charities use Jira and Confluence to get things done?

I recently spoke at an Open Charity meetup event in London about how charities can save thousands, reduce waste and create awesome digital products using tools made by a company called Atlassian. Here are some of the main takeaways from that presentation. Powerpoint slidedeck can be downloaded here. 

What are JIRA and Confluence?

Jira

Jira is used to track tasks and issues for your project and helps you deliver more work, faster. It is popular with software teams but is by no means limited to them. A team using Jira can easily track many types of work, from simple tasks to bugs and user stories common to agile teams. We use multiple management styles at Cancer Research UK, and Jira is well-suited to many situations. The main benefit of Jira over good old white board and post-its is its reporting capability: all the work your team has ever done is kept in Jira so you can set up powerful dashboards and reports which empower managers to better forecast future delivery.

Confluence

Confluence is essentially a wiki for your organisation. it is a great tool for team collaboration and document management. Have you ever spent half an hour searching for that really important information buried somewhere in your email inbox? Confluence allows your teams to have 'one source of truth' for collaborative documents and meeting notes. Powerful macros allow you to dynamically display content to keep landing pages fresh. If integrated with Jira, you can dynamically link to lists of work items and dashboard widgets (See 'examples of good user stories' Jira widget below).

Why should I care?

If you are a registered charity and you have the capability to install and configure these programs in-house, they are completely free for you. This would include many add-ons which normally cost thousands.

These tools allow teams to be on the same page with high visibility and transparency of their work (see project dashboard below). They are highly configurable such that they can scale from a tiny startup to a massive enterprise-grade company. Dynamic reporting tools and dashboards eliminate what might otherwise be manual effort. 

What about other tools?

At Cancer Research UK, we use a combination of tools for Digital delivery.  We want delivery teams to be free to choose the tool that is right for them. There are competing products but lately we've found Slack, Trello, JIRA and Confluence to be the most useful. But it is a crowded field. Competing in this space are Sharepoint, Yammer, Skype, Hipchat, VersionOne, MS Office and Google Drive to name but a few. For a charity which needs to watch their budget, I recommend Trello, the Atlassian tools, Slack and Google Drive.  Pivotal Tracker is also worth a mention, as they have a significant free plan for non-profits.

Conclusion

Whether you’re a charity of 5 people or 500, the tools described here will help you deliver high quality work, quicker, across multiple projects varying in degree of complexity. See below for further reading and video tutorials. 

• JIRA Software information
• Confluence information
• Atlassian's Youtube channel

Open Charity Meetup

Open Charity is a public meetup based in London. For several years it was a rag tag group of charities and their partners meeting privately, but as of late 2016, their public events feature guest speakers, lightning talks and networking. Their focus is on bringing charities and partners together to collaborate and share open solutions to create value in the digital space. If you are interested in sponsoring, speaking or providing a venue, please get in touch via one of these channels. 

• Twitter: @opencharityorg
• Meetup: meetup.com/Open-Charity
• Web: opencharityuk.org
• Facebook: facebook.com/opencharityorg