A rudimental starting point
WebCore started as an experiment to create a platform for BBC products like Sport, News, Weather, Bitesize (and others) could be possible. When I joined the team, WebCore had been a successful experiment. But there were still plenty of gaps to fill. Gaps which would help transform the WebCore experiment into a fully fledged platform and an asset to the BBC. One thing which hadn’t had full consideration was the Design System.
Platforms, Products and Design Systems
Language is confusing. WebCore is a project. To build a platform which teams can create BBC products and experiences with. The Design System is one small part of this platform, alongside all the other good stuff a website needs to work. Shout out to the teams figuring out routing and providing teams with the data they need.
Having my ear to the ground
I started as the solo UX designer and I began by listening and supporting the teams beginning to build things using WebCore. I was able to spot themes in the Design System foundations for layouts, colour and components. Where the system could meet some of their needs but fall short.
I was beginning to see pain points forming where teams needed to collaborate with the Presentation Layer. A team which is the team associated with the Design System. It was clear that creating a culture of sharing work early and sharing updates often would be needed.
I could also see an expectation teams to be able to recreate their current websites and experiences on this new platform almost pixel for pixel. Something which could ultimately increase the duplication of components (or the scope of components) in the Design System, causing plenty of complexity. Complexity is bad for a young design systems. We believed that if we started with something complex, it would become unmanageable in the future.
I spent most of my first few weeks in this team simply listening, learning and providing advice where possible. This is probably one of the most valuable lessons I’ve learnt when working with Design Systems. Just like any other product with a clear audience – it’s about creating a service for somebody. Design systems are no exception. This needed to work for the development teams at the BBC and by taking the time to build empathy with those using WebCore, I could begin to understand how the platform may better serve my colleagues.
Pinpointing my efforts
Opportunities were plentiful. I began to see how I might improve the experience for people working with the Design System.
- Onboarding new people and teams
Folks didn’t understand WebCore, what it was trying to achieve, which teams were building it or how they should operate. - Layout components
One of the main areas of repetition and duplication in the Design System was layout. There was little to no framework for applying layout on a webpage. - Design tooling and documentation
If we wanted designers to adopt the new WebCore components, it was sensible to provide the community with good documentation and access to pre-made components in a design program like Sketch or Figma.
These were simply starters. The community aspect is the one of the most biggest and could be separated into a whole other case study. These were the practical steps I could identify.
Onboarding and team workflows
First things first, I needed to create a bank of information about the purpose of WebCore, what it’s trying to achieve and who’s building it. After picking a format which teams were most familiar with I wrote the ‘How to get started’ guides. I used my knowledge from my support roles within teams but also from scouring old presentations and piecing together the information. This documentation was important for automating support requests, but also for educating/informing people about their role to play in building a Design System for the BBC.
Secondly, I helped to devise a set of illustrations which examined the relationship between the four teams building the WebCore platform. Important for knowing who to talk to, and how the platform worked, based off the teams building it.
Not knowing what to do next
All teams contribute to the Design System, and despite there being a Presentation Layer, it means that each team building components in WebCore have an equal ownership of the Design System. This meant there was no-one to make tricky decisions. So I helped to create and implement a flow for what an ideal contribution looked like.
Although no project is exactly the same, this helped to give teams a steer of what to do next when the path forward seemed unclear. I could use this flow to demonstrate what a good relationship between team and Design System looked like.
A layout framework
I worked with multiple teams to figure out what a framework for layout on a page might look like. By running workshops breaking down their pages into different parts I could see how each team wished to build their webpage. With the teams being the user of the Design System, it was important to put them at the forefront of this project and to base the framework from their requirements.
This framework was split into four parts. One to manage the overall page structure. Another to manage the arrangements of components inside a container. Component layouts were acknowledged, but too difficult to standardise in the short term. And finally, there were page wraps and additional layout constraints to have additional control of the display of elements on the webpage.
This framework is being slowly adopted in WebCore over time. But proves to be flexbile enough to meet the needs of teams building experiences in WebCore.
Sketch libraries and Paper docs
To help teams get familiar with the components we have in WebCore, I became an advocate for the creation and upkeep of solid documentation. This meant sometimes I had to provide ‘friendly reminders’, but I believe good documentation is important for multiple reasons.
- It tells you what problem a component solves. Which is important for managing conversations around like-for-like rebuilds of existing components
- It tells you how a component should be used, and more importantly, how it shouldn’t
- It sets a standard for components in the Design System
- It prompts designers to think about their component outside the context of their needs or product
- It covers aspects of designing for components which can sometimes be overlooked. Such as accessibility
I helped designers to write documentation for new components and organised these within the whole ecosystem of documentation around the WebCore platform.
Design toolkits in Sketch
There are a few component libraries at the BBC managed by other teams, and I used these to gather feedback about how people were using them. I reached out to other designers at the BBC before starting a toolkit for WebCore and it became clear that component libraries in design applications like Sketch or Figma can be difficult to manage and expensive to set up.
The benefits in creating a toolkit need to be balanced against the time and cost in keeping them updated. Therefore, this toolkit covered the essentials. It included frequently used components in the Design System and the ‘tokens’ or foundational aspects like colours and typography.
I used the documentation to help bring together a basic component library in Sketch for designers working on the platform.
From my initial research I found that one thing which designers struggled with is how they initially get set up and using component libraries. So I tried to make this as simple and as straightforward as possible by hosting the library on a server and using Sketch’s RSS feature instead. Designers only have to click a link to start using the library. Plus, I didn’t have to worry about people jumping into the library document and changing things around.
Things I’ve learnt
It’s safe to say this has been one of the biggest challenges I’ve faced in my career so far. Building a design system for the BBC is no easy task. There’s so many opportunities, part of the job was figuring out where were the best places to start. During this project I’ve learnt to listen to my colleagues around me. I’ve become confident in reaching out to teams scattered across the business to see how I can help design a system to enable them to create experiences more efficiently.
Introducing these updates to the Design System and changing the way in which teams are supported have enabled WebCore to expand it’s audience to more teams. There’s over six different web experiences now built using WebCore. Circa Spring 2021.
Is WebCore still an experiment?
Building websites like this is still unchartered territory for the BBC. And as more teams join the platform there are now further issues arising due to the sheer scale of the operation. The Design System helped to serve almost one billion requests in one month (in 2021). It’s crazy to think that the components and frameworks I’ve created have been seen by so many people. #humblebrag
