Building Scholar design system
It’s been 9 months since we began building our design system for BPP. I wanted to share an update on the journey my team has been on; from system foundations to onboarding the first consumers of our new component library. Our design system is just a small part of the exciting tech transformation happening at BPP.
Defining the journey ahead
As a design systems team, it’s important to start with a shared vision. We kicked off by workshopping some pillars and a mission statement. While we already aligned to our overarching Product & Tech principles, we hoped a set of system pillars would allow designers and engineers to make fast, confident decisions.
The team’s values and hopes for the system were all pretty aligned. We shaped our pillars around accessibility, brand identity, clean code and clear documentation and we came up with a mission statement:
Our mission statement
The BPP Design System allows designers and developers to use a comprehensive library of standardised design elements, guidelines and tools which allows them to design and build excellent products to reach more learners and help them succeed.
If you’re curious, there’s more about our mission here.
What’s your name?
The name ‘BPP Design System’ felt like a bit of a mouthful. We wanted a name for our design system that was distinct, straightforward and represented our heritage brand. We riffed off ideas around teaching, learning, progression and our lion mascot. An important criteria was to find a name that didn’t sound like a team from The Apprentice! We landed on:
Scholar
Designing success
Scholar can mean student, specialist or learned person so as an education brand it covers off our different levels of end consumer nicely.
Everyone knows you’re not a real design system until you’ve got stickers so with our name sorted, we went ahead and ordered some.
Getting the foundations right
BPP initially engaged a consultancy to kickstart the design foundations. Their designers and engineers did an excellent job getting workstreams up and running across the domain teams and creating the foundational design elements. As more teams came onboard and requirements grew, we saw a need to revisit things like colour and type to allow for future scale.
Accessible colour palette
We worked alongside our Brand Marketing team to develop a fresh new colour palette with accessibility at the forefront. Accessibility is one of our system pillars and it’s important that our palette allows for good colour contrast. Off the back of a brand refresh, we introduced some new colour ramps with a lightness scale that allowed for defined contrast stops, making it easier for teams to make considered colour choices.
Type, spacing, icons, shadows and the rest
Alongside colour, we refined our typescale across responsive breakpoints and aligned this between design and code. We switched to Font Awesome icons and undertook the mammoth task of manually refining over one thousand icons into a new icon library. We also instigated a new spacing system that allows for infinite scale — literally!
We’ve put a lot of effort upfront into the design system foundation, but I feel like it’s given us a solid base to build on for the future scale of Scholar. You can check out our work on system foundations here.
Introducing tokens
Our initial setup was simple and worked off hardcoded values like hex codes for colours and pixels for spacing. This worked fine in product, but the designs we saw from our team who are rebuilding bpp.com, required both a light and dark colour theme. We needed to find a way to support a second theme, and potentially other themes in the future.
Introducing tokens to a design system allows for theming as tokens take the place of hardcoded values. We got to work on a token architecture for colour and tested this out extensively across our design system components. New tools, like the variables feature in Figma proved a real help here. We also tokenised our spacing system which allows for further theming capabilities like potentially introducing compact or loosely spaced themes to support different use cases. We added this token layer to our components in design and code.
Code re-platform
As the demands of our consumers evolved, we were finding it increasingly difficult to deliver the developer experience and feature set we wanted with our original component library. It had served us well but didn’t allow us the future scale we needed to support such a large and evolving transformation project. Our engineering team made the bold move to re-platform Scholar.
Our new packages are highly optimised making bundle sizes smaller and onboarding more straightforward. We simplified styling technologies, leveraging Tailwind CSS, and offer code splitting support to only include the JavaScript in the bundle for the components that you import.
We’re documenting the developer experience in our Storybook and the new platform is slowly gaining parity with our legacy library.
Supporting our consumers
It was important for us to set up a good support network for our community. We’ve found a design system Slack channel to be the fastest way for consumers to log bugs and make requests, which then progress to Jira tickets. We’ve also set up weekly touchpoints which have been a nice way to get to know the wider product org. We run a weekly engineering forum, a design forum and a working group for accessibility queries.
We’ve recently onboarded the new bpp.com project, who are the first team to consume our new library.
The shape of the Scholar team
I’ve had the joy of working with all these amazing people in our Design System team.
We have a mix of contractors and permanent employees and people have started at different times over the last 9 months, but hopefully you can see the scale and balance of the team below:
Alex Kiersnowski — Senior Product Designer
Geri Reid– Web Accessibility Designer
Awais Waheed — Senior Product Designer
Alex Marriott — Senior Engineer
Seb Gug — Senior Engineer
Lee Cheneler — Principal Engineer
Janak Trivedi — Engineering Manager
Glen Hammond — Delivery lead
Murray Brown — Head of Product Design (Product Owner for Scholar)
Next steps for Scholar
In design, we’ve just released our v1.0 Figma library with the colour and tokens upgrade so our focus is helping designers get onboard and migrating legacy design files. Our engineers will be adding the remaining components to our new code repository and documenting along the way. Once all teams are onboard, we’ll work with them to sunset our legacy components.
With a scalable system foundation in place, we feel like this is just the beginning for Scholar. We’ll be supporting our product teams long term across the different domains to build considered and inclusive experiences for our BPP learners. Follow our blog for updates!
