Creating our Design Playbook: a story in two parts

Matt Gottschalk
EE Design Team
Published in
8 min readJan 29, 2020

We’re working to make BT’s approach to design easy to understand and give the design team the tools they need to work creatively and efficiently. In mid-December 2019 we launched our Design Playbook. This an important resource that’ll help us to be confident that we’re designing the right things for users, in the right way. In this post, Matt Gottschalk, Head of Design Operations, shares why we decided to create a playbook and what we’ve done so far.

An illustrated mission patch celebrating the launch of the playbook in December 2019, complete with a picture of a rocket

Part One: Why we need a playbook

Seven months ago I joined the BT Group as the new Head of Design Operations. The opportunity to join such a huge and iconic company such as BT, and establish a brand new design operations department, was exciting.

The size and scale of the work is daunting, but I’ve seen the passion and drive my colleagues have for wanting to make change and scale our design practice by delivering good design at speed.

New ways of working

The BT Consumer Digital team has undergone some big changes over the last year; from joining the BT and EE brands under a single digital unit, to an ambitious rollout of a new operating model which has seen the creation of around 170 product and capability squads.

We know that to create and run amazing, yet simple, user-centric digital experiences we need to have people dedicated to their continuous optimisation. We also need our people to be experts in their craft. They must help the wider business understand how cross-functional squads employing user-centred design (UCD) processes and methods will help us get to market faster with the best digital services, products and features.

Embracing change

Lots of work has gone into rolling out this new operating model. Every team member is now a member of one of the new squads, with responsibility for a specific part of the BT and EE digital ecosystem, or the team capability that underpins them. But the reality is this is the start of a long journey.

Getting to an advanced level of agile maturity with teams becoming autonomous takes time and effort. It can be anywhere between two and four years depending on the size and scale of the organisation. You also have to account for other factors, such as existing culture, tech infrastructure, and maturity of teams.

But every organisation has to start somewhere. Our design team is learning how we need to work and adapt to this new world. This starts by making sure we have the right tools, processes, and methods in place to lay the foundations to deliver great design at speed and scale.

Early observations

I’ve worked for a few large organisations over the last 10 years that have moved from siloed teams working in waterfall methodologies to a ‘product ownership’ model where cross-functional teams ‘own’ new experiences. They’ve all adopted agile ways of working to deliver and optimise those products.

Three challenges emerge during a transition like this that are fundamental to the ongoing success of design teams, their ways of working, and ultimately the value they provide the organisation:

  • A lack of understanding of roles and responsibilities (including how people need to adapt their ways of working and learn new skills to be a success)
  • A lack of understanding from stakeholders on where they fit within this new process (leading to them handing product teams and designers solutions to put in place, rather than problems to solve)
  • A loss or dilution of previously optimised workflows and processes (resulting in inconsistent outputs and non-standardised ways of working)

I’ve seen those challenges here, too. As a design leadership team, we’ve had to adopt new strategies to build an environment that allows our designers to develop skills and grow in confidence. We’re still working to increase the visibility and understanding of user-centred design across the organisation by bringing more people into the design process. Design needs to move from being seen as an output to a process, which will help put customers at the heart of all our products and services.

Enter the Design Playbook

Creating a design team playbook is a major operational initiative for us and is a huge step in our journey to embed UCD. The idea is to allow our entire design team to have a central resource that contains standardised methodologies, guidance, activities, and useful templates to help create and run amazing, yet simple, user-centric experiences for our customers.

Working with Rebecca Hales, our Head of Content and SEO, we co-created the playbook alongside our design team.

Part two: Creating the playbook

When we started this first phase of work, Rebecca and I had three goals:

  • To create a core information architecture (IA) for the playbook
  • To involve the wider team in helping us to determine the structure and hold collaborative workshops to co-create entries for the UCD activities included in the playbook, defining and recording how we work and want to work
  • To create a minimum viable product (MVP) that would provide value to the team at launch

Both Rebecca and I were new to BT. We needed to find time to focus on this work while also trying to establish our new departments. We started with regular weekly sessions to lay the foundations and assign roles and responsibilities to progress the work. We quickly found a nice rhythm of using the meet-ups for a mixture of working sessions and creating action plans for the following week.

We decided to use a tool called Notion to host the playbook. Our user researchers were already using Notion to document their user research findings and this meant we didn’t need to spend time exploring other options. It provides enough customisation to create basic templates and the text editor is very intuitive. We don’t necessarily see Notion as the long-term platform for the Design Playbook. As we build on our MVP, we will likely move to a tool that provides better navigation, search, and accessibility considerations.

We’ve split the Design Playbook into three sections: our design approach, working in a squad, and our design toolbox.

Our design approach

This introductory section is for people who want to find out who we are as a design team. It was important for us to provide this section not just for new designers joining our team, but also for other digital teams and stakeholders.

We also used this section to introduce our Experience Principles (more on those soon) which our teams are starting to use to help shape user-centric digital products and services. A set of criteria supports each of the principles and we use these to assess whether a user journey is effectively contributing to our goal to create experiences that enhance our customers’ lives.

Working in a squad

This section focuses on how the different disciplines within the design team work within our new operating model. As a team, we’re 150+ people. That’s product designers, content designers, user researchers, accessibility experts and SEO specialists, as well as design operations. Each one of these disciplines has its responsibilities within our multidisciplinary squads.

We’ve documented the responsibilities of each of these roles so that designers know what’s expected of them. It also helps us to be as transparent as possible across BT and EE so people understand when, and how, we can help.

Workshopping our design toolbox

This is the meat and bones of the Design Playbook. We’ve divided our design toolbox into three areas: Build, Measure, and Learn. This framework acknowledges the value of being agile — iterating and learning fast. To build, measure and learn effectively, our design toolbox allows designers and squads to select methods, tools, and templates to help them learn and create efficiently at any stage in the design process.

The workshops we ran with members of the design team to help populate the toolbox were each focused around one of the key areas: ‘build’, ‘measure’ or ‘learn’. We opened up the conversation to the team at the start of each workshop to discuss what we all felt each of those areas meant to ensure we were aligned before starting to identify some of the activities the team were already doing in those particular areas.

An image showing a group of designers in a workshop in front of a screen that describes how they do affinity mapping

We used templates to help capture information about each activity during the workshops, including the name of the activity, why you might decide to use it, and the outcomes it could provide. We also asked the team to document who would be involved in the activity and the types of materials and templates needed.

Around 30 members of the team were involved in these sessions across all our disciplines and it was really interesting to start to understand their perception of the build, measure and learn framework.

Following the workshops, we asked everyone who had proposed an activity to write up a more detailed description and guide for each of the activities they had recommended, and these formed the basis of our design toolbox for our MVP launch.

We wanted to gather enough content to be of value for our teams. By this, I mean enough resources for them to use, but also enough for us to measure whether what we’ve included is useful. We hope to run workshops around the activities we’ve included in the playbook so that our designers can put it into practice and let us know where it’s helpful, and where we need to add more guidance to help them solve problems we may not have thought of.

Let’s do it differently next time

It was great working with 30 designers on this first iteration, but we want design to be a process and not an output. If we do any future workshops around playbook content, we’ll take them wider than design. We want to understand how product owners experience journey mapping, or how developers understand the role of an SEO expert in the squad. We can’t do that without those people in the room. So next time, we’ll invite them along.

We also need to improve on how we follow-up when commissioning content for the playbook. We went out to our contributors and then kind of left them to it. Whilst great for autonomy, we needed to help them prioritise this work. Maybe next time we’ll take a lesson from our developer colleagues and do some mob writing sessions.

The next challenge
The way we work on products and services allows our squads to build and release small iterations that are continuously improved through agile work practices. It’s a fast way to get things off the ground and into the hands of customers, but it also means things feel like they are constantly changing.

We hope the Design Playbook will help us make sense of the activities, standards, and rituals through which our designers, SEO experts and user researchers build, measure and learn together and share progress with others. Eventually, the Design Playbook will become just one part of a larger Digital Playbook that all disciplines will use.

Our next challenge is team engagement and adoption of the Design Playbook. We’ll let you know how that goes.

We’d love to hear from you if you’ve worked on developing a design playbook and have any lessons to share around roll-out. What worked for you? How did you promote it? How have you measured success? Let us know.

--

--