The Cancer Research UK Design Principles

We've adopted a set of design principles to help us describe how we want to work at Cancer Research UK.

We've written another blog post that explains a bit more about design principles, and why we think they're important. So give that a read if you're interested in learning more. And we've also included the agenda for the workshop that helped us get to these design principles at the bottom of this post.

Our Design Principles

 

We focus on outcomes, not outputs

We start with a problem, and work out the best way of solving that problem. By focusing on solving a problem over delivering a list of features, we make sure we provide the right things, for the right people, at the right time.

We treat our data as a critical asset, and make decisions based on evidence

How our products and services collect, manage and query data is vital to the everyday operations of the charity. And we believe using that data is the best way to make the things we deliver better. We always test our assumptions before making decisions, and we’re not afraid to stop working on things that aren’t backed up with evidence proving their value.

We partner with the people in the charity who use our services, encouraging co-creation and empowerment

We put power into the hands of people so they can manage their work with autonomy. Governance is light touch, we recognise that good ideas can come from anywhere, and a self-service approach is encouraged in everything we do.

We disagree without being disagreeable

Disagreement isn’t something to be scared of, as long as it’s done in the right way. If we don’t agree with something we speak up, but once a decision has been made we commit wholeheartedly to its success.

We start small and develop iteratively towards our goals

The best products, solutions and services start small, test early with users and iterate from there. We’re comfortable with experimentation and testing, since it’s the best way to keep things simple, future-friendly and usable by everyone.

We always think about delivery end-to-end

Although we start small, we know a Minimum Viable Product (an MVP) is not a final deliverable. We make sure that whatever we deliver is robust enough to scale. And that security, quality and resilience are designed into everything we do.

We don’t rest on our laurels

We celebrate success, but we also avoid complacency. We recognise that inspiration can come from anywhere, and we know that however well we’re doing, there’s always an opportunity to be better.

We work ethically, honestly and deliver things that act in our users’ best interests

We start with user needs and provide products, solutions and services that treat people with respect. We do what’s right for our users, even when it’s difficult or controversial. And we never trade in their goodwill for a quick win.

We work in the open

We’re open and transparent about the things we deliver, the way we work and the challenges we face. This means we share as much as we can as often as we can, and we’re comfortable with ambiguity.

The workshop that helped us decide our principles

• Introduction - what are these principles for, why should we use them  + questions (15 mins) 
• Talk through existing 'example principles' and where we've gathered them from
• How is today’s session going to work?  (5 mins )
• Warm up -... thinking about how we do things in our directorate  (15 mins)
• Individually brainstorm what we're good and not so good that make us different from other directorates (5 mins)
• Discuss with your group (10 mins)
•  Design your own  (post it notes/sharpies on table) (40 mins)
• Think about the best project you’ve worked on here (15 mins)
• What made it so good? What behaviours did people exhibit? How did you go about things?
• Add one post-it note per ‘thing’
• Share with your table group and discuss similarities/differences (20 mins)
• Stick post-its against one of the example principles on the wall – or in its own space if it doesn’t fit any
• Coffee break (15 mins)
• Review the example principles/new principles individually (10 mins)
• Discuss as a room together, stress testing with ‘anti-principles’  (30 mins)
• Dot vote with 5 dots – on existing principles, or individual post-it notes (10 mins)
• Play back principles with most dots (5 mins)
• Hopes and fears post-it exercise (25 mins)
• Any worries, concerns, doubts about what we have? Share on post-its, then let’s discuss
• Wrap up and cover what happens next (5 mins)
• Flag that any disagreements or contradictions will be discussed at SLT level
• Flag that we'll collate, wordsmith and recirculate what we have

Designing our design principles

Why do we need design principles?

It’s always tricky bringing 2 teams together, and it was no exception when our old IT and digital teams came together to form a new Technology directorate. Back when we were 2 separate teams we had different cultures, ways of working and delivery methods. And we knew these differences wouldn’t magically disappear after we’d restructured.

So, alongside our new strategy, we had an assumption that a set of design principles could help everyone to commit to one way of working to solve problems. And give us a way of describing how our newly formed team would work with the wider organisation.

What are design principles?

There’s a bunch of definitions out there, but I think the best way of summarising design principles is by thinking of the place where your culture meets your design process. So imagine a mix of “the way we do things round here” and “the things that are important to us when we deliver work”.

How did we build them?

Combining teams had left us with a jumble of visions and behaviours from different parts of the directorate, that weren’t as aligned with each other as they could have been. This left us with a couple of challenges; ‘how do we make sure we’re not starting from scratch unnecessarily?’ and ‘how do we motivate people into sitting through yet another vision setting away day?’.

So rather than re-invent the wheel, we pulled people in to a workshop to try and bring our existing outputs together to form our new principles (more on this later).

And, since the idea of design principles is to inform a behaviour, we decided there’s no point in a design principle that’s self evident. For example, ‘be user-led’ could be a design principle, because some organisations would take an approach of ‘our users don’t know what they want until we build it’. But ‘do good work’ couldn’t be a design principle, since there isn’t a (serious) organisation out there that would describe one of their principles as ‘doing bad work’. So we also made sure to stress test the principles we came up with by reversing their meaning and seeing if they still made sense.  

What did we learn?

Don’t make them sad bits of laminated paper

Our Director said this early on in the process and it stuck with me. We’ve all seen office motivational posters of jargon encouraging us to ‘cross fertilize high value corporate deliverables’ or to ‘develop a best in class service led ecosystem’. Design principles shouldn’t fit into the category of meaningless phrases that are laminated, stuck on a wall, and then forgotten about by the people actually delivering work.  For design principles to work they need to be used and referenced regularly.

Power to the people

The easiest way to make sure something’s used regularly is for the people using it to feel a shared sense of ownership on the thing that’s been created. So we invited representatives from every team in our 300+ person directorate to attend the workshop. Not everyone could make it, but those who couldn’t were given the opportunity to feedback on the draft principles. So everyone had the chance to contribute.

One group we did exclude from the workshop was our directorate senior leadership team (SLT). The main reason we did this was so that the principles were created by the people who would use them the most. And were closer to the reality of the day-to-day challenges of delivering work at Cancer Research UK.

Use them or lose them

Although they weren’t at the workshop, we made sure to share our outputs with the SLT afterwards, and take the time to listen to any comments or suggestions they had. This was important to prevent the opposite of the ‘laminated pieces of paper’ effect. Since we knew that if that group didn’t stand behind them and defend them to the wider charity they’d never take off.

It also helped create a contract between delivery teams and leadership. By endorsing the principles created by the team there’s some clear expectations around the behaviours the SLT expect from us. And around the behaviours we expect from the SLT.

This helped position our design principles as something that sits outside of our organisational hierarchy. So everyone is held to account for the same standards of behavior, not matter how junior or senior they are.

Build your design principles, not someone else’s

There’s a bunch of existing work out there that influenced our design principles. From the new digital design principles for charities to the how to guide by Protoypr and the work GDS have done. We definitely didn’t want to create our own principles just for the sake of it.

But at the same time, we knew that just copying and pasting the GDS principles wouldn’t work for us. Because we’re not GDS, we’re Cancer Research UK. It sounds obvious, but when you’re thinking about what organisation you want to be, you also need to take into account what organisation you are right now.

So while we weren’t afraid to use existing templates and research to influence our thinking, we tried to make sure we weren’t just taking a cookie cutter approach. Since if they weren’t relevant to our situation we knew they wouldn’t be used.

What’s next?

At the moment we’re taking our design principles on a mini-roadshow to the different teams in our directorate through a pretty simple workshop exercise where people:

•  Pick a principle they’re great at, and another principle they think they could be better at
•  Pair off with someone else
• Guess what the other person picked for their 2 principles, then swap over and discuss

It takes about 15 minutes, but we found it’s a great way of getting the discussion moving. It also forces people to actually read and reflect on the principles, rather than just reading them and ignoring them completely.

And what have we got planned for the future? Well, the honest answer is “We’re not sure”. We’re still finding our feet with our strategy and our place in the organisation.  So we’re positioning our principles as an ‘open beta’ that we’ll be testing out as our team becomes more mature. We’ll only really see how successful they are by seeing the quality of work they help us deliver when we use them.

Of course, there is a danger we won’t use them. But if that’s the case, then either our behaviours aren’t right, or the principles aren’t. At the moment we’re planning on doing a strategy check-in in around 6 months’ time, so once we’ve done that we’ll do another post to share how we’re getting on.

So what are they?

If you’re interested you’ll find our design principles and a full outline of the workshop we ran to get them here. Hopefully our principles will change and evolve as our team does, so we’ll keep them updated. In the meantime we’d love to hear any thoughts or ideas on how we can make them even better.

Chris Flood

Content and Search Lead

Cancer Research UK