Transcript
Sophie Beaumont: I’m going to be chatting a little bit about the BBC’s web design system. Before we get into the design system side of things, here’s my embarrassing photo of my garden fence. I think you’ll all agree, looking at it, it’s just a little bit wonky, isn’t it? My mum would say it’s feeling squiffy. When we moved into our house, we didn’t know what that big bush at the back was. We didn’t have any documentation about what was going on with the garden and the plant at the back. We left it and left the fence alone and left the garden alone to redo the inside of the house first.
Then our neighbors decided that they needed to nail their garden furniture to that same fence as well that the plant was climbing up and depending on. They didn’t really chat to us about that. They are absolutely lovely, love them to bits. We didn’t communicate very much about our shared fence, our shared garden component. Then later on, they decided, actually, we want to change our furniture again and we’re going to remove all the nails out of there.
Then that’s when we started to see the slightly drunken lean on the fence because it hadn’t been maintained very well either. That was on both of us. We weren’t chatting about it. Then the fence started to depend on the bush for survival. Now if I want to go ahead and fix any of that, because we didn’t have any of our documentation, communication, no clear ownership, and no maintenance of the garden nor the fence, it’s going to cost me a lot of money in the summer to fix it all at once. Because if I try to take the fence out, the bush is going to hold on to it. If I try to take the bush out first, then the fence will probably fall over into the garden. It’s all at once, unfortunately. Hopefully, as we go through our talk, we’ll figure out how to not let our design systems end up like my garden fence.
Professional Background
I’m Sophie. I manage a whole bunch of amazing software engineering folks who are building the common web foundations for the vast majority of the BBC website. I come from a software engineering background generally, so I’ve been in the BBC for, it’s coming up for about 10 years now. Part of the furniture. I did a lot of accessibility work. That was my specialism as I went into the senior and principal roles. I founded the BBC’s first dedicated web design system team. I’m currently acting as the engineering manager for that wider space, too.
BBC’s Scale and Tech Stack
Before we get into the actual design system itself, I want to give you an idea of the kind of scale that we’re talking about when we’re talking about the BBC. I checked these numbers very recently. This website that we have, unlike my garden fence, which scales to exactly two households, the BBC website serves far more than that. These numbers are a 30-day sum period in January this year. We receive, for the pages that our design system serves, 4.8 billion requests, which is absolutely wild. Of those 4.8 billion, our presentation Lambda rendered 3.9 billion times, which is incredible. That scale is huge. On the product side of things and the services that we support as well, lots of brands across the BBC website.
If you’ve ever used the site, you’ll know this, that we serve lots of different audiences across the UK. We have currently 10 brands supported by the design system with about 25 capability teams, so cross-discipline engineering teams working and contributing to that system. There’s been, when I checked last, 450 contributors to our monorepo where we keep most of this code, which is amazing. In terms of frequency of release numbers, last month we deployed 285 times, which is pretty impressive. Lots of very awesome software engineers contributing to this system. Really quick fire on the tech stack. Our app currently runs on what we call the presentation Lambda. We have a React frontend with our own web framework that renders all of our pages.
All of that then hooks up to a business logic layer and then onward to many upstream content APIs and information from our editorial staff. Our code lives in GitHub. You’ll probably hear and read the word WebCore throughout this presentation. That’s just our internal name for the web platform that we’ve created that uses all of this aforementioned tech. For our design system specifically, Storybook is our front door. Our design system really evolved from the code implementation rather than from a UX perspective, although we do reflect the components in the implemented system in Figma as well, so that folks can access it there and update all of the docs. We treat Storybook like our Argos catalog of components and containers.
The system is not versioned, which is really interesting. When you merge something into the WebCore platform or to the design system, it goes live. That is the source of truth then for everyone who’s then using that system. Because of that, we lean fairly heavily on Chromatic for visual regression testing across the repo when people are raising PRs so that you know if you’re impacting other people’s code.
The Design System Experience – Flexible Entry Points and Onboarding
The design system team themselves came up with this mission statement, and I was there when this was created. “Through inclusive thinking and collaboration, the design system enables others to create accessible, consistent, and scalable user experience with audience value at their core”. That audience value is really important for the BBC specifically because we’re trying to get that best value possible to our license fee payers. I think this puts front and center what the team are trying to achieve. The way that we run the system is a little bit unique and interesting. We have a federated contribution model. People in the teams can contribute whatever they want to the design system. Most of the things that are on the website are in the design system. Some are more reused than others. We decided that that was fine.
Then the design system team themselves sit as a central expert team that garden the system. They keep everything running and make sure that when people are contributing to the system, they are following guidance. That means that we’re benefiting the system and what the business needs are as well as them meeting their requirements. That team have a lot of cross-cutting understanding and expertise over particular problem spaces like accessibility and reusable solutions specifically. They’ve made themselves experts in contributing to the system. A lot of the people in that team have either built on the system previously in one of the capability teams or they’ve had experience of design systems outside of the BBC. What’s really important about this, I think, is that it talks about enabling others.
The system is really only as good as the successful outcomes that it enables. You can have this perfect design system that’s like super not messy and it’s really tidy, but if no one’s using it and they’re circumventing the system that you’ve provided them, the purity probably isn’t worth it.
How does this work in practice? We’re going to look at it from the perspective of a team trying to build part of their experience on our system. We’re going to put some children’s web team shoes on, and they are very nice, bright and yellow. We’ve got our team of folks in the children’s web team and we are trying to bring our brand, our CBBC brand and probably later CBeebies as well, into the system. We’re going to start by onboarding. As we approach the system for the first time, the first thing that we’ll probably notice is that we’ve put a lot of deliberate effort into the onboarding process for that system. They’ve made it really clear upfront what’s important to know about the system before you start contributing to it. This is on our front office, so Storybook. We’ve added a lot of documentation that we’ve hand-rolled in the Storybook tool. Even if the people who are in the children’s team, so in the team that we’re currently putting ourselves in the shoes of, have never interacted with the design system before, we’ve got an onboarding path for you. Every discipline in that team can come and understand what the design system is, what it’s supposed to do, what it expects from you.
Then if you’re maybe an experienced developer, even, there’s pathways that you can dive right in. Say here you wanted to go straight into the theming side of things, then you can do that. We do also have that whole hub of information that we’ve created to help guide you. It’s also really good for onboarding third-party teams that we’re working with. We’ve been working with a lot of third-party folks recently that are helping us build our experiences. This has been super useful. This helps us scale because we can send this documentation out and it’s super self-service to begin with.
If you are more about that face-to-face experience, though, the team do run quarterly onboarding sessions and then they record the last one that was done, so that if you really want that human explanation from the design system team themselves, you do have access to that, or you can come along to one of the actual sessions. I think that one quarterly meeting to onboard anyone to a design system this big is pretty good going and is a good way to scale that system.
It’s made super clear, like I said earlier, what we’re trying to achieve with the system just in the plain docs as well. If you want to just go read through docs and that’s more your bike, that’s totally fine. It’s clear to us if we’re thinking about the children’s team coming on board, that when we look to solve problems with this system, reusing things and solving common problems once is the way that we’re probably going to be entering that system and wanting to work. We even go a little bit further and take it to the next level.
If you’re someone from, say, the product or UX discipline or even the delivery discipline, you can come in and we’ve got this Figma flow chart, which can help you with your decision-making. As you come into the system, it will help you understand what are you actually trying to achieve, and then guide you down a path of either reuse or you need to add something to a component, or you need to talk to the design system team because you need something brand new altogether, which is totally fine. UX is very often embedded in our teams that are working on this system. Having something like this that’s more accessible for that discipline is really useful and helpful.
Then, finally, you are going to get that introduction to the design system community. I think that this is super special about our design system. All of those 25 capability teams that I mentioned earlier are onboarding to a community that they know they have full access to. That includes the design system team themselves. They also know that there’s all of these support channels. We’ve got Slack channels. We’ve got community meetings. We really do treat it like a community of teams who are trying to build that one BBC experience. We’re all trying to solve problems and some of them are similar, and we might be able to come together and come up with a common solution.
Just to recap that little bit there, we’ve got flexible entry points and onboarding. Up front, we’ve seen what the expectations are on our team as we build on this system. We also understand how we can contribute successfully. It’s through paths and at a time that suits the needs of the people in the team. You might have someone who’s, “I just want to read docs. I don’t want to have to talk to anyone”, which is totally fine. I think we’ve all met developers like that, which is great.
If you really want that human interaction and you really want folks to be reassuring you about your decision-making, if that’s what you’re looking for, then the team are there for you and the other teams building on the system are there too. You can go and speak to people who’ve done this before. Our expectations are really clear as well. We know from reading all those docs that when we do contact the design system team, they are probably going to be asking us to reuse things. They’re going to be questioning our approach and they’re going to be encouraging us to be thinking about the things that are important to them in the business, like accessibility and performance and efficiency.
Adding Flavor into the System – Well-Documented, Scalable Foundations
Remembering again, we’re in those CBBC children’s web team shoes. How are we going to add our own flavor into the system while also making sure that it’s reusable, maintainable, and scalable for later? As we go through the onboarding docs, we learn about our design systems’ levers system. This is using a few layers of tokens. I’ve seen design systems before where you’ve got that first layer of tokens where you name the hex codes and you map them. We’ve got an extra layer on top of that, and made tokens where the tokens represent what you’re trying to achieve, not just the color that you’re picking. This keeps everything super consistent. Because you’re thinking about that purpose, you can transfer the usages of those tokens between components really easily. It doesn’t matter which brand you’re using, the decisions about color contrast and accessibility are being made up front.
Then you can trust that those tokens are going to work together really nicely as you go from one component to the next. We can go in and we can see in Storybook and check out how the other brands are defining their colors. How they’ve mapped their own service level tokens to use in the news lever, for example. We do a lot of governance around these tokens and using them correctly. We ask people to avoid using those raw hex codes wherever possible in the system. There’s a little bit of governance there. When new components come onto the system, the design system team do review them before they get into the code base. They might contact you and be a bit like, it would be great if you could use the token system properly and make sure that you’ve got your tokens well defined in your lever.
Conversations about adding new tokens is completely fine. Again, we’re not blocking people. We’re gardening the system. We’re asking folks to have a conversation. What are you trying to achieve here? Should this be a new thing that we add in? They’re gardening as they go. Like I said, this makes all the components in the system completely transferable to another service or brand entirely. You’ll notice that we’ve got like accent and accentContrast there.
Again, we’re talking about accessibility and making sure that when you define these colors, you’re thinking about where those things are going to be used and making sure that you’re making accessible decisions for our audiences, which is super important to the system. Making sure that we’re using these means that they can be safely reused across other features without worrying that your accessibility is going to work or not. Also, that you’re not going to be hunting down your hex codes in your components going, “What did I set for that text over there again?” That’s great.
We can also play around with a nice bit of tooling about the way that the tokens look when they’re applied to realistic use cases. Again, this is all in Storybook. The design system team are an incredible group of engineers and they’ve created some really cool tooling. This really helps visualize not just for engineers, but for anyone else who’s approaching the system from another discipline. They want to see like, tokens. That’s going over my head, like, what does it look like? How does it actually get applied? This allows folks to contextualize decision-making about the brand that we want to introduce in our children’s shoes, if that makes sense. You can see an example here that we’ve got. That’s what it looks like when you apply the news lever, so all those tokens we saw before. This is the applied version of that with a cheeky little live in there as well, just for fun. We also have a similar system with the fonts. We have font palettes that you can apply.
Again, at the same time as you’re defining that service lever for your page, in our page composition, you can also define the font palette that you want to use for that experience. We probably want to be adding to this because as the children’s web team, we want to be adding in probably a font that’s a little bit more child friendly, maybe a little bit more fun and round looking than the adult news, potentially slightly boring font. I love the Reith font. It’s very good. We paid someone to make the font for us and it is incredible. It’s super accessible and it’s really nice. I love the branding there. Then, more classic design system stuff. We’ve got our foundational values for spacing and breakpoints that we can use in our implementation later if we need to make anything new, so that our features look consistent across the entire site and align with the other services. Again, to create that one BBC, kind of like all together, nice seamless look.
CBBC, we’re doing the brand. Amazing, we’ve got our colors into the system. We’ve created our own lever for CBBC. We’ve thought about that accent and the accentContrast. We’ve thought about our accessibility. We’ve also added that really nice, more rounded, more playful looking font, which is wonderful. To achieve that, we went through our well-documented, scalable foundations. That’s the super-important part of a successful design system, I think, and being able to scale. The constraints and governance that we do have are clearly explained. We know that when we’re contributing to that system, that the design system team are probably going to be asking the right questions. It’s really easy to adhere to, but also to add to.
Then that means that consistency really becomes part of the baseline of the experiences that you’re building. We also have that interactive documentation tooling to allow for visualization. Lots of different ways into that documentation again, but super clear what is expected of us, and how to use those foundational elements of the system.
Automation-Supported Component Documentation
Let’s say that we want to create an index-like experience. We call them the homepages of the brands, may be indexes. Like the news front page on the BBC website, we would call the news index. Say we want to create something a little bit like that in our children’s web space. A little bit like this one here we saw earlier in the palette playground with the new service lever applied. What we’d really like to do is not only apply our colors here, but also add some maybe additional icons to the cards, we call promos in our system, to make it super obvious to our child audience the kind of content that they’re going to be clicking through to.
Let’s dive in and have a look at how we might see about the details of one of those components. Very good, we’ve found the promo in Storybook. This component is probably one of the biggest that we have. It has a lot of options. You can do lots with this component. There have been multiple conversations over the 5 years or so that we’ve had this system building up about, do we break it down? Do we create zones within the promo? Yes, very complicated component, but it works really well. Pretty much every promo that you see on the website, aside from a couple of exceptions, is using this one component, which is really cool. It has a lot of control so that we can see what it does in Storybook. Let’s take a look at that documentation.
We’ve added extra stuff into the document, the default Storybook documentation here. We’ve got lots of helpful information in there. We can see when that component was last modified, when it was created. We can also importantly see who owns it, so we know who we need to speak to. We’ll get onto that a little bit in a moment. We’re also noticing that we have this accessibility health check tooling. That’s pretty high up in the documentation. I think if we’re going to be contributing to this component, we can see that accessibility is super important to the system because it’s been hoisted up in that documentation, making it really clear that that’s what we’re expecting from you. We need to be thinking about that. What if we don’t know much about accessibility, what do we do?
Even when we haven’t filled out our accessibility documentation yet, there’s even links to more documentation and more instructions and help to help us understand how to meet the system’s expectations. We have this whole accessibility site that allows the teams to go and understand how they should contribute to the system and how they’re going to meet the expectations of that health check in that documentation. Here’s a nice example of some of our screen reader UX. We ask for this in every new component that is on the system, especially the ones that are super reused, so something like the promo. Really important that you understand how it works for our assistive technology users before you start going in and changing things. We’re very specific about having that level of documentation.
This is super useful, so we can see a little further down in the docs about the promo, that it already has that icon functionality that we were looking for, but it maybe just doesn’t have our icons in it yet. Hopefully we’ll be able to add those to the system and add it to the various assets that we have access to, and we’ll be able to meet that requirement that we were talking about earlier. We can also see in that same documentation which tokens that promo is going to need and where it’s going to be applying them in the component itself. Again, connecting all of those dots as we’re going through and trying to add stuff in. We do also have our classic props tables. Although we do not have TypeScript everywhere in the repo, we do use TypeScript definition files alongside those components so that this can be autogenerated.
All of that documentation that we’ve just spoken about there is mostly automated. Aside from the descriptions of what you’re trying to achieve with that component when it’s first built, all of that accessibility health stuff, all of the last modified, all of that, we’ve added that in automation and as tooling. It’s data driven. When you create a component, you can use a command line command for that, and it generates all of the files and metadata that you need alongside the component files and the story files. You don’t really need to work too hard to get all of that documentation in there. All of the accessibility stuff is pre-populated. It’s really easy to then meet those documentation requirements because of that. You did see those important behaviors hoisted up near the top of that dot.
Mandatory Ownership
We’re back in the shoes. I definitely didn’t take a screenshot of the existing CBBC website for this earlier. We’ve got some promos in there and we’ve got our colors in there as well. This is applying all of the things that we’ve added to that system. We’ve got our icons as well, which is great. Henry is looking very cute on there. Wonderful. Love that. If anyone watches a bit of Blue Peter. Everything in this implementation is reused. When the team did actually, in real life, come in and implement their pages, they basically didn’t have to build anything new at all. This is called the hierarchical promo collection component. Even the layout is componentized and reusable. We’ve been able to use things that other people have created and just very gently tweak them and then apply our levers, and we’ve got most of a page. What if we want something with a bit more oomph?
If you’ve been on the BBC News website and other pages, because they’re picking up this component a little bit more, now you’ve probably seen one of these gigantic billboards. That’s the name that we have for it in the system itself. They’re usually used for huge breaking news stories. They have this default brand ambience using the lever system, which works great for the existing core brands that we mentioned before. We’d be able to put maybe the CBBC purple into there.
Editorial absolutely love this collection of components. It’s very versatile. It’s very eye catching. It’s very high impact. We can go into Storybook and we can see, what if we put a bit of Bluey in there? Let’s try seeing what it would look like if we use one of the simpler versions of the billboard. We’ve not got those extra promos in there embedded, but we’re still using that big canvas space with the gradient and overlay there on our brand image. It looks all right, doesn’t it? It looks ok, but it’s a little bit not branded. Even if we use the CBBC purple here, it doesn’t necessarily go very well with the image the editorial have chosen for this brand. It’d be really cool if we could better represent the children’s brand colors in here.
Let’s go and look at that documentation again in Storybook and find out who do we need to talk to about adding or changing the way that those colors are in the system. We can see from our strong ownership that we’ve got here that we need to maybe go and speak to either the homepage or topics team or both. We’ve got that wonderful community of people and all of those Slack channels that we onboarded with earlier that we can go and talk to them through.
Even better, every single team in the system has their own team page also in Storybook, so you can go and see not only where to contact them, but also what other things they might maintain and any components that they’re using from the other teams as well. We’ve got this really interesting mapped out dependencies that you can go and look at and understand where everyone’s connecting with each other. Let’s go and speak to the topics team and have a bit of a meeting with them and talk to them about our requirements, so how we want to add our branding into this big billboard. They use it already. Actually, it turns out they’d like to do something really similar. They’d like to do the same thing, but for their brands that they might be supporting. Big one, Doctor Who, we’ve got this big topics page. They’d really like to be able to use that branding from the show and the images from the show and apply that to that billboard component.
Really important that we have that mandatory ownership in place to be able to start these conversations. Every single component that is built in this system is owned and that ownership is clearly surfaced. It’s also codified in the repository. If you don’t have your files in our code owners, it’s not going to let you merge them in. It’s going to tell you that you need to put a team, and it’s a GitHub teams that we use to do this, in there somewhere so that folks know who they need to be talking to. That’s really important that you don’t end up with a bunch of orphaned components somewhere that folks would like to maybe use, but they don’t know who owns it, who uses it. Having all that information available to us helps them understand the state of the system and the components that they might want to reuse. Open collaboration from other contributors is really important.
The reason that we ask everything goes in the design system, is because even if it isn’t shared right now, it could be shared later, and someone can come along and they have all that documentation available and they can understand if it’s going to work for them.
Collaborative, Community Gardening Approach
Once more into those shoes. The thing with CBBC and the thing with CBeebies is that they have a lot of sub-brands. They’ve got a lot of shows. They’ve got a lot of campaigns that they’re doing. CBBC alone has 235 sub-brands that they work with. That’s a lot of sub-brands. Topics probably have a similar amount considering all of the various things that they cover. CBeebies is a little less sorry, with about 174, but that’s still a heck ton. What are we going to do here? We’re going to add 235 levers to the design system because that seems quite difficult to maintain. How are we also going to make sure that all of those meet the accessibility and scalability and maintainability requirements of the system? That sounds really difficult. We should probably go to speak to the design system team about this, because we’re talking about introducing new colors and brands and stuff to the system.
Speaking to them, they are concerned about the maintainability of adding so many hex codes to the system, and imagine having that drop-down of levers and instead of 10 tidy brands, it’s like 200-odd things that you have to scroll through. That would be pretty wild. Yes, they’re making a face at this. It’s really easy to contact them and it’s really easy to set up meetings with them, and the community come in and we bring topics in as well. Let’s have a conversation about how we can do this. To avoid all of that maintenance and make sure that you can reuse this stuff across more things than just children’s in the future, perhaps, how about we shift our thinking into tooling here? Can we be a little bit more creative about the way that we come up with a solution that meets the requirements of the team that we’re in and the thing that we’re trying to achieve, but also meets the requirements of the system and what the business would like from us which is not having to have a whole team of people looking after just 250 brands, which would be a lot.
The design system team are a bunch of amazing, very clever folks, and they came up with the concept of something called the color picker. The color picker ended up being a reusable component that wraps around other components that overrides that initial page levers theme in an isolated space. It allows our editorial staff to choose an image that represents the brand that they’re trying to show to the audience well.
Then we have this color picking library that goes in and it picks out colors from that image. We’re doing this on the fly now. We’re not adding like the blue hex background there or anything like that to the system. We are allowing people to inject that brand in without polluting that wider system. As children’s, once we’ve introduced this tool, let’s go and have a look. Now that looks a bit bad, doesn’t it? We’ve got that nice bright green that’s the highest population color from the background. What you’ll notice as well is that between those two, the text color is flipped. That’s because the color picker not only goes and picks those colors out of that image, it also makes sure that any text that you put on top of that gradient of background is automatically accessible.
One of the things that we find challenging sometimes is if our editorial staff are making decisions about colors, sometimes they’re not aware of accessibility standards and it’s quite hard to bridge that communication and skills gap sometimes. We wanted to make it as easy and as automatic as possible and as safe as possible when they’re choosing these colors. Then topics have been able to use it too. Doctor Who looking very nice there with that purple. We love that. We’re picking those colors out. This is actually reusing that tool that has now been collaboratively created, but across another component. This is actually a slightly different component called the topic header. They’ve taken that from that collaboration and used it in their own space for their own benefit. They didn’t even have to ask for it. Another team made it. Another team met their requirements and now they’re able to reuse it in other places, which is awesome.
We’re really taking that collaborative community gardening approach. If someone comes along and they’re like, “Yes, I’m going to come into the shared community garden and I’m going to plant a gigantic oak tree right in the middle”. You might be a bit like, “That sounds awesome, but maybe, hear me out, we choose a birch tree instead. We pop it over here so that it doesn’t interfere with all the other things in the garden that everyone else has put in there. It’s not taking all the nutrients away”. We do a similar thing with the design system team.
They go out and they speak to the teams that are building on the platform, but we’re not looking to block people. We’re not trying to police them. We’re trying to help them meet their requirements, but also keep that system successful and tidy and maintainable so that we don’t have to linearly scale the design system team with the amount of stuff in the system. We’re really leveraging all of our tooling and that community to maximize the amount of scale that we can achieve, but without having to put tons of resource into that team and to maintaining that system. Then, where the system can be impacted by the things that the editorial are asking for, or the teams are asking for, can we get super creative and really think about how we can scale, but without having 235 levers in the system, perhaps.
Recap
Just to recap what we’ve been through there. We’ve got our flexible entry points on onboarding, so we knew exactly what the design system was about, what they were trying to achieve. We could see all of the tooling, the visualization, which is awesome. All of that documentation around the components is super automated and it’s always there. In every component, you know what to expect and you know if something’s missing as well. You can go in, and if you really wanted to use something and maybe the accessibility documentation isn’t as good as you think it could be, you can go in, you can find those files, you can update it, you can edit it. Then you can chat with the team who maybe created it to begin with.
Generally speaking, people are super happy to have those contributions from other areas of the business. Mandatory ownership. This is super important. You don’t want components that are orphans. You don’t want components that no one knows who they need to speak to if they want to update it, or change it, or if they want to add something in. That code owners also allows us to have this really nice system where people can just raise PRs against your stuff and you’ll just get a little notification to go, can you have a quick look at this thing? We’ve just added a new prop to your component for our needs. Have a quick chat about it, and that’s all good. That really collaborative community and gardening approach.
Again, we’re not trying to block you. We want to help you meet your requirements in the teams, but also meet the needs of the business and the design system itself. Hopefully, if we follow some of these tips and advice, your design systems will end up in a better condition than my garden and my garden fence, which is going to be very expensive, as I say, for me to fix later on this year. I’ll have to rip everything out all at once and I will have to talk to the neighbors about it.
The BBC Web Design System Team
I just want to call out the actual BBC Web Design System team themselves. They are an incredible group of people, specifically on the color picker work. We had Nat there and Sam did a lot of work around that, collaborating with the teams that were looking for that solution. Everyone on this team is absolutely incredible. I really wanted to give them credit for the work that they’ve done here, because I just have the absolute joy of gently guiding, steering, and managing those people, that they are intensely clever.
Questions and Answers
Participant 1: I’m curious about the team composition. You have people, so do they specialize in web engineering and more UX? What does it look like?
Sophie Beaumont: The design system team? It is a cross-discipline team. We’ve got the full gamut of disciplines in there. We have products. We have delivery. We have three UXs in that team, because it is quite a UX, and design and branding heavy area. In the BBC, we have something called GEL, which is the Global Experience Language, which is the overarching branding decisions that get made for the whole organization. A lot of the UXs in the design system team have worked in that space. They can really push that branding stuff through the advice that they give through that team as well. I think there’s right now four or five web engineers in there. We’ve got Josh, for example, who represents the BBC at the CSS Working Group. Yes, lots of involvement in that design system and web space from the engineers as well. They are the design system experts in the BBC at the moment.
Participant 2: How old is the design system? From the business side, do you have a dashboard of KPIs? The ROI of the design systems, how do you measure that for business people?
Sophie Beaumont: The design system that we have is about 5 years old now. It has very slowly grown. We didn’t just go straight in with that quality of documentation from the beginning. It’s definitely been a buildup of that tooling. In terms of making it valuable to the business, I think, again, recently, we’ve been doing a lot of surfacing of data around the system itself to the rest of the business. We are going to continue doing that. We’re now like out the other side of that design system spectrum. You start at the beginning, and you’re a bit like, we just really want everyone to use our stuff. Please use our stuff.
For us, that wasn’t as much of an issue, because everyone that was building on WebCore, which is that central web platform, were building on the design system. We’re a bit of a captive audience. We’re kind of like, all your stuff in the system, we love that. Now we’re in a position where more people want to use it, and more teams want to use it and contribute to it. We’re on the opposite side of that scaling. I think that’s where that data visualization starts getting really useful, so that we can start showing which teams are maintaining or creating the most components and which ones are just reusing everything and not maybe maintaining as much.
I think we’ve got some interesting ownership challenges in our future, because now we’ve been around for 5 years or so, we’re starting to get that thing where you get natural churn in a company. Teams move on to other things. They own like five components, what are we going to do with that? Some more interesting stuff around it. That data visualization is going to help us make those decisions and be able to show the rest of the business the value that we have and where it’s going to sit as well. I think all of that documentation really helps as well to show every discipline. It’s not just for engineers, it’s not just for our designers, the product side they can come in and have a look at what’s in the system and play around with it themselves, if they want to. It’s that easy to use and understand.
Participant 3: How do you manage the A/B test and the experimental version of the same component?
Sophie Beaumont: At the moment, experimentation is very much a collaborative effort. It’s something, again, that we’re looking at creating better tooling for. At the moment, it really is going and speaking to the people who currently own that component and making sure that when you’re doing the experimental work in those spaces, that it’s not super interfering with some plans that they have in their roadmap, which definitely could be better. Experimentation is one of the big challenges of having that one version system that you can’t just version a component off to the side and do some stuff with it. Equally, it also means that if we had an accessibility complaint not too long back, where someone mentioned that we weren’t using headings on the indexes, we were using links, which semantically makes sense.
For our audience purposes, needing to browse things on those index pages, the research that we ended up doing for that showed us that we should be using headings everywhere. Because of that one version state that we’ve got in the system, we could just update the form to use a heading and it fixed it across the entire website all at once, which is really nice. It is a very wide blast radius for change. I think experimentation is something that we are trying to do more of. I think in the future, we’ll be looking at introducing some more tooling around that to make it much easier to do it rather than going in on the components that are live on the site right now and putting all of your experiments in there when they might maybe clash with each other.
Participant 4: As a core team with lots of other teams depending on you, how do you balance any requirements that emerge from these teams? How do you manage? What’s the priority?
Sophie Beaumont: When folks approach the design system team with a support request, we’ve got a bot that they can use to fill out a support request. One of the things that we ask in there is, is this blocking you, and how much of a priority is this? Is this like mission critical that we need to introduce this thing? Sometimes we have conversations with those teams, and we go, we’d really like to do something that’s super reusable, and we have a plan for that. If you’ve got a deadline for like the election next week, obviously, we can facilitate a tactical solution in the moment.
Then we’ll revisit it with the design system team advising on that and how to recontribute that to the system again. We do have the ability for folks to take those components if they really need to into their own, what we call like container space. It’s not as much in the reusable component space. It’s almost like their little bit that they can do what they want with if they really need to. There is an avenue for people to pull the cord and be a bit like, no, we really need to get this in here right now. We can’t be super reusable just yet. That’s totally fine. We handle support requests and prioritizing them by talking to the teams about that. We do also have things that the design system team are trying to do themselves. The tooling that we saw, that’s all like their own roadmap work. Yes, it’s really balancing the support requests with the day-to-day BAU that we’re trying to do as well. That can be tough sometimes. That is the nature of being an enabling team as you do a lot of outreach and talking to people.
Participant 5: I understood that the design system was mainly web and React. Any experience in integrating mobile native components or other technologies?
Sophie Beaumont: Actually, the web design system was the first one that we created a team around. Then, maybe 2 years ago, we did actually spin up a mobile design system and app design system team, very similarly, because of the success of the original web design system, which is really cool. At the moment, the way that we’re going to be doing it is having separate design systems for those spaces. We’ve very much very recently moved the organization more around those modes of people accessing the BBC. We’re going to have a whole team for the app side and TV side, which is really cool.
Participant 6: We can see it’s amazing how you’ve made that work for the overall page, the layout. Does the design system also include mechanisms for people who are telling visual stories? If we take the news, for example, maybe you’ve got charts or maps or visual storytelling as part of the pages themselves. If so, what does that mean for an unversioned design system? Do you have this massively increasing scale on your Chromatic diffs that look back over historic stories, for example?
Sophie Beaumont: A lot of our, what we would call visual journalism, so if you go into articles and you see the charts and the stuff that get created, are coming from third parties. We do work with a lot of partners to create those graphics. We do include them in Storybook. We don’t need a screenshot for every permutation of the way that the graph looks. That’s not really what we’re trying to test there. We’re just trying to make sure that all of the main elements of that embed, for example, are in the right place. We probably wouldn’t, in our case, have very many snapshots around that. Yes, just a few to make sure that the embed works correctly. Who knows, maybe in the future we’ll need to cross that bridge.
Participant 7: I’m just wondering if you hope to integrate the web design system and mobile design system at some point. Do you have a strategy for that, or is it separate for the time being and will continue to be?
Sophie Beaumont: It’s separate for the time being. The plan is to, I think, keep them separate for now. I think because there are things that you can definitely share in terms of standard of documentation, things like accessibility importance. We really want that to be shared across those areas. The implementation details are so different for the mobile space to the web space, and especially TV as well. We do a lot of the TV apps, even though that’s web technically. There are hundreds of versions of TVs. I was on a graduate scheme with the BBC and one of the teams I worked with at that point was the IPTV team, our area. I still remember testing all of our stuff on such a massive range of TVs with very different support capabilities. Yes, I think for now it’s probably going to remain separate. We will continue to share principles between those two spaces, because there’s a lot of underlying foundations that work regardless of your mode of access.
Participant 8: How do you assess the accessibility of your components, particularly when it comes to screen reader behavior?
Sophie Beaumont: When it comes to accessibility, we use Axe in our CI/CD pipeline. We’ve got that embedded in there. It runs against a representative subset of routes every time the build happens, and flags up any new problems that have arisen there. Storybook has an accessibility tab for a particular component, because component level and page level accessibility, they’re quite different. In terms of the screen reader stuff, that comes in with the accessibility swarms that we ask people to complete. That part is still quite manual. I think it’s really useful for teams to be going in and just giving it a go with the screen reader on their Mac, for example. The whole team will get together around a feature that they’ve created and go through this swarm template that we’ve created. It’s still in Dropbox Paper. I’m hoping to maybe do a bit more tooling around that to make it even easier to do that in the future. We go through a standard checklist of accessibility checks to make.
Then also a little bit of, can you get through the headings? Can you get through your landmarks properly? Are the semantics correct on the page? Just getting people to think about it up front, really. Definitely progress over perfection when it comes to the accessibility side, because, yes, the scale is absolutely massive and not every team has the same accessibility skill level as others. That’s perfectly fine. They can always come to the design system team in which we’ve got folks with accessibility expertise as well, so they can help out with that.
See more presentations with transcripts
