Creating an enterprise-wide CSS framework by Front End Developer, James Almond.
“Create an enterprise-wide CSS framework that will be used by development teams across the business.”
As you can imagine, when given this task my first thought was something along the lines of…
“This is going to be interesting”
Building an enterprise-wide CSS framework is no small task but I was definitely up for the challenge. Pulling together four huge sites, with multiple languages to consider and numerous requirements sounded like fun!
Before making a start on a CSS framework, the team and I figured we’d need to do a bit of research into what a CSS framework actually consists of.
What is a CSS framework?
There’s a lot to consider, here are a few questions we had:
- What will the framework consist of? Purely CSS or should we include JS too?
- How will the framework be structured?
- What sort of technology can we use within the framework? Is CSS grid ready for production use?
- What solutions will a framework offer? Will it enable teams without a dedicated front-ender to create front-end systems?
- How is the framework deployed? NPM? Another method?
- Will it be open-source? If so, how?
- Should we use an existing framework?
After much discussion a decision was made, below are the features our CSS framework should contain:
- Fully responsive, mobile first. It’s easier to add CSS than remove.
- Component-based, built of elements that are used throughout the website.
- Built with an ITCSS structure so specificity doesn’ become a problem.
- Accessibility should be a high priority, all components must be accessible.
- Our CSS must be performant, keeping our CSS bundles as optimised as possible.
- Easily installable.
- Easy to understand documentation.
- CSS consistency enforced via linting and pre-commit hooks.
- Multi-locale. Must support multiple languages.
- Progressive enhancement for the latest browsers.
ITCSS (Inverted triangle CSS) illustration
At this point we were in the same space as a lot of other developers find themselves.
“This sounds great; a CSS framework that’s built to be responsive, easy-to-use and supports all the business needs, let’s get going!”
We quickly realised that we need to make sure the business is aware of why they need a CSS framework to do this successfully. A CSS framework that needs to be rolled out across our front-end teams, getting all of them bought into it and utilising it into their workflows means we need to convince the business why they need one.
Why do we need a framework?
There’s no reason why we wouldn’ need a framework, right? A lot of other businesses have one so we should too.
After thinking about it, I asked myself the question:
“Do we need a framework?”
If we set up some code reviews and get the front-end team upskilled with up to date CSS technologies, that would work just as well, right?
After some taking some time to reflect on the objective the answer was clear. We need something that promotes consistency across a website’s front-end, and establishes an ultimate source of truth from a single point, a guide to how the website should be styled and structured. This could be a simple document that developers refer to whilst working on projects to keep consistency.
There is still the risk of error, we’re human, and we all make mistakes, it happens.
One day there will be AI that can create a website’s front-end based on a design that it’s given, till then, we need to help our developers some guidance to building websites.
This is why we need a framework, we need that single source of truth and structure, that can be used by humans to reliably develop a consistent front-end journey.
Okay, so how do we start?
To start, we needed to create a design system that contains our styling rules, these rules will define the contents of the CSS framework.
To create a design system, we got in touch with our pals in the UX team; their goals aligned with ours of creating a consistent front-end journey.
After much consideration and discussion, we ended up with a design system that we all agreed upon. This then allowed us to start defining our base styles within the framework, this included:
With these three building blocks, we began to construct our base elements, which can then be used to create components.
We’re on our way.
Let’s get cracking
Great! We’ve got buy-in from the business, a design system to build from, and our building blocks defined. What’s next?
We realised that building our framework would take time, quite a lot of time actually; as it turned out we needed at least one developer working on it full time for weeks.
“Can we afford to take a developer or two off project work for weeks to create this? Hmm…”
The answer to that thought was no, we shouldn’. Our developers were quite rightly focusing on projects that are currently a higher priority.
We needed to find a way to create a framework amongst our project work so we had the idea to marry it with our project work!
Our solution was to create the framework alongside a redesign of an older part of the website; specifically our “My Account” section where our customers can view their details and order history. My Account was redesigned using the aforementioned design system, meaning we had a great opportunity to create our elements and components while working on the redesigned front-end.
Developing in phases
Instead of building the entire framework in one go, we realised we could easily split up the project into phases:
- Initial framework consisting of the build system, documentation, and common core journey components
- Product team specific components e.g. media gallery, filter bar, checkout specific breadcrumb etc.
- Open source separation and progressive enhancements
If we built the framework in this way, we could release phases separately and get it into the build systems of our front-end systems quicker. It also allows our developers to use the framework and provide feedback before it is complete, exactly what we need.
It also allows us to delegate tasks to product teams using the framework so they can create their own components based on the documentation guidelines.
“The smart thing would be to have our product teams do it for us…”
This approach allows the framework to become a much more collaborative project for the entire team, it will be a living and breathing project that will be continually improved upon and added to, all conforming to a UX approved design system for the betterment of the user.
In building this framework, I had a lot of personal wins. I’ve never built a CSS framework before, and this one was large.
I had the opportunity to learn how to manage a huge project, one so large that it requires multiple team members working on separate parts of it and bringing it all together.
This helped me develop my leadership skills, something that I’ve been eager to improve for a while. One leadership skill that I did learn is that listening is your ally, always listen to whatever suggestions or feedback you get as it can only help the project and develop your skill set. Even if the information isn’ correct it shows which way you should go.
I also learnt about project management, specifically how to set out achievable goals for the project and setting deadlines for said goals. Without deadlines, the project wouldn’ move as quickly as it possibly could do. Deadlines create urgency and even if the deadlines aren’ met, work is still being done and the goals are getting closer to completion.
Throughout the process of creating the framework, I had to stop and ask myself many times…
“Am I doing the right thing?”
I cared so much about getting it right, that honestly I did doubt myself sometimes and questioned if I was the right person for the job. My team members did a great job at reassuring me and if there’s one thing you should take from reading this, it’s that you should never be afraid of asking for help, even if you think you’re going to look stupid for asking.
What’s the future of our shiny new CSS framework?
Firstly, we need to deploy phase 1 and get the wider front-end team using it within projects. This will allow us to get feedback and improve the framework whilst it’s in development.
Secondly, we need to get the remaining phases complete. Booking in time within sprints to get the remaining product team components completed.
From there it’s a case of looking at the framework and seeing what we can open source. Here at AO, we want to contribute to the open source community as much as we can.
We’re committed to updating the framework as time goes on, this could include:
- New technologies e.g.
- Media queries level 4
- Display grid
- An animation library
- Much more!
I hope you enjoyed this look into the CSS framework here at AO. It’s still a work in progress but we’re confident it’ll help us achieve the goal of a fully responsive, component-based library, which will improve the styling consistency of the front-end journey on our website.
If you’d like to see our CSS framework in the wild, feel free to sign up for an account on ao.com here: https://ao.com/myaccount/. We’ll be rolling the framework across site in the future, so keep your eyes peeled.
Thanks for reading!