David Bailey - The Future of BBC's Global Experience Language

Hello everybody. My colleague Nikos is at the back of the room, I'll talk about that in a minute. So first of all it's really nice to be here. I came last year to this event, I had a great time. There's loads more of you over there, wow. And so I'm a big fan of Copenhagen, I'm really pleased to be back here. And I'm also, yeah, just very excited. Last time I came I talked about my background, how I used to be a skateboarder, and then I became a designer that worked with the Designers Republic and I made loads of record covers and cool stuff like that. And then I ran my own design studio and ended up at the BBC about three years ago. And I talked about the work that we do there. And some of that stuff I'll recap on today. So, wasn't Todd's talk good? I like, I like, those guys at MailChimp are so cool. I visited them earlier this year and I have a few of those Freddys, I've got three of them. And I'm not eBaying them. Okay. So, I'm David, I'm the Creative Director of the BBC's Global Experience Language, which is our shared design framework with which we design all of the BBC's online output across all platforms. And my colleague, Nick Hoss, who is at the back of the room, standing in the doorway there, is our Senior Developer Advocate. And we're here today to talk about culture and strategy. And those two things, and they don't always sit comfortably together. And also about the work that we're doing that's helping the BBC transform from being a traditional broadcaster into an internet fit organisation. Oooh. I did that just to make myself giggle. Okay, so creativity is at the heart of everything we do at the BBC. I'm sure it's at the heart of everything you guys do. So we're in the right place. For the past almost 100 years, the BBC has used creativity to educate, inform and entertain. And during that time, we've had to reinvent ourselves a number of times. And we've done this successfully by embracing design and technology. Since 1946, the BBC has been a publicly funded service. Everybody in the UK that has a television has to pay a licence fee. For that, they get loads of great TV, radio and now online content. Since 19... no, sorry, since 2010, the BBC has been locked at about £145, one-off payment each year. And it isn't likely to increase any time soon. Which is understandable given the economic uncertainty we find ourselves in in the UK. No thanks to Brexit. We won't talk about that. And then... But also the commercial market forces and how they would prefer to see the BBC change into more of a traditional sort of a subscription model. Now, we don't want that. And we don't want that because we know that the majority of the people in the UK don't want that either. What they do want, though, is they want for us to remain a vital and relevant public service moving forward into the digital age, so to speak. Um... Which means we've got to change. And that's one thing that we know about the BBC. Change is our only constant. It's the one thing that you can bank on. Now, with the internet, to change is quite exciting because there's loads more opportunities and options and ways of presenting the BBC to our audiences. Which is really exciting. But it gives us a bit of a paradoxical requirement. Which is we need to provide greater efficiency, while supporting an explosion of creative ambition. OK. So, to do that, we need to change the way we do things. And we are doing. I mean, we've never done this before. We've never been an internet-first thinking organisation before. We've never taken television channels online before. But we're doing that. Now, to do that successfully, you need some good strategy. But as a famous business commentator and author once wrote, Culture eats strategy for breakfast. And that's so true. It's so annoying. Yeah, culture. Culture, the way that we work, the rhythm that we work, the way that we do things. You get into a rhythm of delivery. So that you can keep moving forward and being creative. And doing what you do well. OK. So, that's what we're kind of up against. And it's difficult to change. It's very difficult to stand back from what you do. Look at what you do. Reassess it. And then, sort of reinvent the way you do things. An organisation as large as the BBC, we don't have that luxury. So what happens is we make incremental steps forward to make change happen. And when you're busy, it feels like that. Now, this isn't the best way of doing things. But it's often the way that they get done. OK. So, Nikos and I, we work in BBC User Experience and Design. We are a comparatively small department of the BBC. It's about 130 people. That's quite big, actually. No, but compared to the rest of the BBC, it's quite small. It's actually very small. If you imagine, the rest of the BBC is about 20,000 people. So we're a small department. And we're made up predominantly of user experience designers. But also information architects, design researchers, and accessibility specialists. And what we do is we design that layer of interaction that lives between our audiences. And all the BBC's online content. It's a big job, but we love it. Oh, God, he took the picture right as I was going. All right. So, yeah, so the work... Where was I? Yeah. So, if you imagine our department, BBC has loads of products. So we call them products online. Here's a selection of six of them. And our department sort of sits independently of those products. And we embed our design teams into those products to fulfill the UX requirement. And they do this using GEL, our global experience language. We make design patterns and experiences that are reusable by other teams so that we can have consistency across all the different products online. Okay? And what my team does, the GEL team, is we facilitate the origination of those... of those design patterns collaboratively. And we publish them as guidelines. And these guidelines help our designers work quickly, do the job more successfully and more efficiently. Okay? And we publish them on our GEL website. Which we've been working tirelessly for the past year or so to really improve. And there's all sorts of good stuff on there. So it acts as an online resource for our designers to do their day-to-day job. But because we're a public service and because it's online, we give it away to the world. So it's on there for you guys to go and check out. It's bbc.com slash GEL. We'll show you the URL at the end. And I'm sure you'll find some good stuff in there. There's great guidelines, how-tos, articles and really fun explainer films as well. So it's going well. But let's talk about guidelines for a minute. So one might argue that guidelines are solving yesterday's problem. Yeah? And what I mean by that is they are providing uniformity in a changing world. Our product colleagues in the wider BBC, they don't wait for change. They are the change. They're creative too. We facilitate that happening. So if we're to be a truly digital organization, we need to become more flexible. Now all of these product teams, what they do is they make their different offerings online in different ways. They're all in different silos with different engineering teams, technical architects. They build their stuff on different technical stacks. So and then GEL comes in and gives it a consistent look and feel. But if we're to become truly flexible and digital, we feel that we need to flip that. So rather than things be built differently and look the same, we think they need to be built the same to enable them to look different. Okay, so how might we do this? How might we prove the benefits of not only making reusable design patterns but making reusable, shareable, and visible code? Okay, how might we bring developers and designers closer together so they start getting to know each other and have a better relationship and understand their thinking? But most importantly, how might we afford a sense of ownership with all of our wider colleagues in the organization? Because if you get that right, you change culture. And that gives strategy a chance. Okay, so that's the setup. I'm now going to bring in Nikos and he is going to tell you about some of the things that we're doing to help that along. I'll come back at the end. Okay. Nice. Okay. How's this working? Can you hear me? Ooh, there is a lot of people here. Hello. Hi, everyone. My name is Nikos Tsouknidas. Thank you for having us in Copenhagen. Ingrid, Michael, everybody. It's a lovely city. And thank you for the intro, David. So my name is Nikos Tsouknidas, which is a difficult Greek name, I know. So you can call me Nick, Nikos, Nikolas, or just Tsouk. Which I've been told that it's a weird thing in Turkish. So apologies to any Turkish people here. I know at least one who's chuckling. So a little bit about me, my back story. I started as a comic book artist. And then I studied computer science. Then I did some illustration. Then went to do interaction design and augmented reality. Then back to illustration. So I guess maybe you see a pattern here. So I've been basically playing jump rope with design engineering. Then I went to Japan and did design strategies, what I think says there. And then came back to Europe. And for the last five years, I've been a software engineer at the BBC. So I guess... I am a developer with a design background. Working in UX&D. Which is quite new in our organization, at the BBC. And in these years, in the last five years, what has happened at the BBC is that the gel team has actually changed the wonderful and amazing but different landscape of the BBC to a nicely kept garden. And following our guidelines, our designers have gone out. And they have changed the way things look at the BBC. The way they look and they interact. For the last year, I've been working in this team, the Global Experience Language team. But as a software engineer, not as a designer. And I went in to look underneath the surface. And underneath that surface, things are a little bit different. In a way, that's to be expected. I don't know if you know of Melvin Edward Conway. A computer scientist, a programmer and a hacker, apparently. Mr. Conway here. So he coined this phrase, which I love. And it says... I'm going to read that out. Organizations with design systems are constrained to produce designs which are copies of the communication structures of these organizations. And in the BBC, our communication structures are mainly product structures. As you saw from David's slides, we have lots of products, even more than these. Those are just a small piece of them. Now, this is not the case in the UX&D team. And this is why the UX teams are quite different. They work differently. So what we were due for was an organizational change last year. And what happened is that our heads of departments decided that we were going to change the name of our division from digital to design engineering. And that's a really good phrase here. As you can see, design comes first in this phrase, which is how it should be. Design should come first before engineering. Actually, even in engineering itself, design should come first. What GEL did, what the GEL team did, is that they brought the design disciplines together. But it's not the same in engineering. Sometimes it feels like engineering is drifting apart. If you look closer, under the hood, as we say, there are large distances to cross in engineering. And also, between design and engineering, this little amber stamp there with the space, it's not doing enough to bring design and engineering together. So what we're going to do as the GEL engineering initiative is to bring design and engineering together and also attempt to get engineering working better within itself. And I'm quoting a poem here. Whoever finds it gets a little thing in the end. So we have some problems, we have some aims, and I'm going to tell you what we're doing about it. It definitely feels like sometimes we're pushing tectonic plates together at VBC. It's slow, but it's definitely going somewhere. One of the problems we have is that sharing around engineering in the VBC has really high costs. It's difficult to reuse stuff. And I've been in the meetings where engineers have argued to me that it's easier to redo something from scratch than to reuse something. And they've argued that successfully. In their arguments, most phrases were about product backlogs and product owners. And the main, the same word there, as you can see, is the thing product. So we have product things in the VBC, and inevitably we get silos, and this is how we manifest Conway's Law. Another problem is that new technology is easier to adopt by teams than by the whole organization. And I don't know if you've heard of that. They say that technology is like fish. It is good when it's new, fresh. If it's stale, it's bad. And when you're in doubt, you'd better use it on a cat. Because the Internet's full of cats. One of the examples was when the news team went out and used GitHub two years before everybody else in the VBC was able to use it. And that's because they identified a need for it. They needed to share code in this platform. They needed to use a new repo language. But the rest of the VBC took two or three years to do that. Now we're all on GitHub and we're all sharing code. That'll be source code for now. So these are some of the problems that we have to face. And what we have to do is make sure that we reuse cheaply and effectively. And to do that, we made this culture shift. We need to change from thinking about products to thinking about services. Because service is something that everyone can own in a big organization. And can contribute to. It has its own myth. Teams to communities. We have to change from teams to communities. Because communities are easier for people to move around in them. And there's natural osmosis happening in communities that doesn't really happen in teams. So what are we doing to shake the dust? What we decided to do in Agile Team, is going to build a place where everyone can contribute. Both designers and engineers. Both designs and code. At the same level. Then we can all own it together. A place where every component and design in the VBC will be visible in its own responsive glory. At a set of standards that meet engineering excellence. And design excellence. So we're building a component library for the VBC. And it's going to be eventually open for all of you to check out. This is going to be an extension of our website. The guideline website. Which informs this library. Where you go there, in this library you will audit, discover, and promote stuff from the VBC. It's also linked, it's going to be linked to GitHub. From where you can continue development. Do feature requests. Brands, Fork, all the stuff that's hot in GitHub. This is a place that the VBC doesn't have yet. VBC is a massive organization. To get everybody in this component library has been a road, definitely. It's a shared space where we can afford people a shared sense of ownership. What we're also doing is we're building tools that are neither pure design, nor prototyping, nor development tools. They are everything tools. This is what this regex there says. So it's multi-tool. They're design tools for the code curious, we might say. That's how we name them. And the reason is that we think that if both designers and engineers are working on the same tools, they're going to start talking the same language. And communicate better. So we're building tools to lower the barrier, of this communication. And bring design and engineering together. Like this. And that's not an easy thing to do. It's not an easy task. But who likes, who envies people who have easy tasks? Right? So we're working on this by thinking and building. By talking and sharing. By design and engineering. In the gel team. And we think we're in a good place now. We feel we've reached base camp. Thank you.