About Experience Projects


About 3 months after I joined BuzzFeed, a small team of engineers and designers began building what would become a unified CSS styleguide for the team’s web products. Solid is a lightweight framework and design system, written with functional CSS. You can check out the latest release here.

Why we did it

The BuzzFeed design team was the largest I'd ever joined, with around 12 designers at the time. Seeing the breadth of work was really interesting for me, from internal tools to consumer products. But it was clear that as the design team and volume of work was growing, the inconsistencies across products were as well. Not only that, but newer parts of the site clashed with the "legacy" pages, making the ecosystem kind of jarring for the end-user.

When critiquing, we didn't have a good baseline for what patterns to use when, and when it felt right to introduce a new pattern (aside from our gut hunches). Creating new designs and giving feedback lacked focus and structure. It was hard to get my footing as a new designer at BuzzFeed, with no patterns or practices to draw from.

At the same time, all of these new and different styles in conjunction with our legacy styles meant a lot of bloated CSS. Evolving a feature or fixing a styling bug became difficult, because it was nearly impossible to understand or troubleshoot which styles were getting applied where. Though we continued to chip away at our old CSS, we didn't want that to stop us from evolving the website.

We also noticed the collaborative efforts between design and engineering were lacking. We often worked in silos from each other, and communicated only via specs or tickets in Jira. We were eager to experiment with a process that brought engineers closer to the product and designers closer to code.

I wouldn’t say we built Solid in order to get designers coding, but having a library and shared language across design and engineering has been invaluable to us.

What existed before we started

This lack of communication became clear when the engineering team introduced a component library they had been building for the past few months. The library was built off of the current, existing website modules. Each module on the site was broken off into its own template with its own styles. The intentions were good. The engineers wanted a library to reference and to reduce the number of styles for the same UI. “No more code bloat”, they reassured me.

A screenshot of the component library in progress when I first joined the team

There were a couple problems from the start. One, the engineering team was working on this with almost no input from design. How did they know which UI should be componentized, which UI was here to stay? What about things that needed to be modified?

Second, the library wasn’t exactly living up to its promise of reducing code bloat.

A component in its purest state was fairly self-contained.

Example of the "Story Block" component from the early component library iterations

Code attached to the original component

Yes, a component in its purest state was fairly self-contained. But as soon as it was modified or altered in any way the CSS became a mess of nested layers and dependent styles. While the standard style of the story block component held up, many variations of this story block appeared over the course of a few months on different pages of BuzzFeed, and we didn't account for what would happen to the CSS when we introduced new variants.

Variations of the original storyblock that were introduced after the original component was built.

The amount of CSS we needed to append onto the original styles to achieve the modified variant styling😭

Having brittle components just wasn't giving us the flexibility we needed. There were many ways we could have solved component modification, some of which we still consider today. Regardless, it was clear we needed to move away from this. The root of the problem was that design and engineering weren’t aligned on the future of the BuzzFeed’s UI. I felt like I was in a unique position, seeing both sides of the coin. Engineering wanted stability, and design wanted flexibility.

Exploring Possibilities

We still wanted designers to get in the code. I came from a small team, where I was responsible for the design & front-end. I was fully behind the benefits of a collaborative cross-discipline environment.

We started playing around with BassCSS, a functional CSS styleguide, and found to be a really nice way of spinning up new designs. Not only that, but BassCSS is written in a way that makes it easy and non-intimidating for designers to pick up. Being able to use it in our own prototypes inspired us think differently about how we write and consider CSS.

We decided to get a small group of designers and engineers to sit together weekly and begin discussing different ways of tackling our CSS problems.

The key to success here was choosing the right people to start the conversation. Anyone who expressed interest could join, but we really wanted those key engineers involved in the initial component library in the room.

The original Solid team

The final negotiation revolved around using a functional CSS library over a more systemic BEM-like approach. Functional CSS can be described a few different ways, but it basically revolves around tightly scoped, single responsibility classes. Functional styles should be immutable, or not easily overwritten.

Aside from playing around in BassCSS, we started reading up on other libraries tackling the same problems, such as Tachyons, and Lonely Planet.

Making the Right Choice for BuzzFeed

We wanted the ability to create some consistency where it made sense, but also to easily make new things or rethink old ideas. This was especially important for the BuzzFeed product and to our constantly-evolving editorial strategies.

Functional CSS was a low-barrier way to create tightly scoped, fundamental styles that wouldn’t interfere with the existing components.

An example of Solid's single responsibility classes in the documentation

Broken down, we were looking to create a flexible style guide for BuzzFeed that would allow for a scalable and iterative design approach in a more efficient and less risky way than we previously were.

Getting Started

We worked together to determine what would be included in the style guide, how we would break it down, and how we would choose to implement it in code. The weekly meetings had a focused agenda. In the early weeks, we covered topics such as the BEM vs Atomic debate, whether we would include components, and how we would document the work.

The process included many conversations in Slack, countless iterations in Basecamp, and a ton of PR’s in Github.

Our collaborative toolkit: Slack, Basecamp, and GitHub

We started by tackling the fundamental elements, such as typography and tables. In the weekly meetings, we decided what to tackle when, and assign one or two people to each task. Everyone was responsible for giving feedback, code reviewing, and offering support.

Sometimes we spent meetings negotiating a particular technical decision, while other meetings were spent focusing on the language & design of the documentation. The biggest takeaway I have from this period was that we took everything in stride. We weren’t trying to do everything at once, but rather a couple core things at a time to build momentum. Because we could afford to spend the time we needed on this project, quality was valued over quantity.

Once we had a beta version of the documentation, we started doing a bit of roadshowing. BuzzFeed’s hackweek had fallen around the same time as our first internal “release”, and we were able to pitch the styleguide as a helpful toolkit for potential Hackweek projects.

It was serendipitous in a way; we were able to get our first “users” to try out the product during Hackweek. We also got a ton of feedback on the first iteration of the product, as well as buy-in from engineers.

"Buzz Maps", a hackweek project built with Solid's first Beta release

We spent the next 4-6 months refining the documentation and styles. The first public project we tested the Beta release on was Buzzfeed.com/news. We were able to drastically reduce the amount of CSS and page weight. We also added it onto smaller independent pieces of the CMS.

Documenting breaking changes was especially important when starting out with internal use, since we were evolving and iterating at a rapid pace.

Shipping and Learning

A year after launching Solid publicly, we’ve been able to ship a suite of new pages, as well as iterate on them painlessly. Learn more about why we made Solid public here.

We implemented Solid on the new homepage, BuzzFeed Tasty, and a few newer category pages. We’re currently in the process of implementing the styles on article pages while we port them over to a responsive layout.

Some wins we’ve seen in the past year:

  • Designers and engineers are working together! We have a common language to talk about UI
  • Designers are coding (Solid makes introducing designers to CSS a lot simpler)
  • Engineers in turn are embracing their product and design instincts
  • Pages are responsive & faster
  • Code is easier to manage

Some things we’re still working on:

  • Adding reusable components to the library
  • Figuring out when to add new styles (How many use cases justify a new component? What kind of use cases are we talking about?)
  • Revisiting some technical decisions we've made, such as when to add !importants, and which styles merit more than one responsibility, if any.

An example of one of Solid's lightweight components in the documentation. The components, unlike the utility classes, use a BEM class structure.

At the end of the day we’re able ship things quicker, communicate smarter, and iterate easier (all without adding tons of CSS to our codebase). At the most basic level, Solid is only what it needs to be for each product we make. Though it was built first and foremost for BuzzFeed, it’s open to the public for anyone to play with (check out the link below to try it for yourself!). I’m really excited to see what comes of Solid and the future of design systems across the board.


Product design & development


Cap Watkins (VP, Design), Sam Thurman (Engineer), Allison Chefec (Designer), Lindsey Maratta (Designer), John Niedermeyer (Designer), Mark Shuster (Designer), Amaury Molron (Engineer)

See It Live Caret right
Arrow up

Want to get in touch? Feel free to reach out ↠ brick.emily@gmail.com.