Building Solid
As Emily noted in her post introducing Solid, the team building our framework was a mix of designers and front-end developers. Prior to that, we had unintentionally built silos around the two disciplines. While we’re definitely proud of the end result, this new way of working came with some interesting challenges and lessons along the way. We know there are a lot of teams out there who are curious about bringing their engineers and designers closer together, so we thought we’d share a bit about what we encountered and what we’ve come away with after nearly a year of working closely together.
Process Rules
When we started the project, we were pretty stoked about the idea. We were finally going to have a style guide! CSS would finally be simpler to work with! With all our excitement, it would have been pretty easy to just start building things without much regard for process or how we’d work together. We needed some sort of process to help us align our team and avoid a messy codebase. However, we also recognized that adding too much process too early can snuff out the energy and momentum before you’ve gotten anywhere. If we were going to be successful, we needed just the right amount of process and just the right amount of freedom.
To start, we decided to meet weekly, giving us a way to maintain momentum and have a regular forum for in-person discussion. After a few philosophical discussions in person and on Slack about how to structure our style guide and write the CSS (we had a lot of philosophical discussions throughout this process), we drew up an initial list of the elements we thought we might need. From there, we tackled one or two UI pieces at a time, starting with inventories of current implementations and new design explorations before moving on to actually writing them into the Solid codebase.
Collaboration Is Key
For each UI element inventory and explanation, we asked everyone to weigh in on the best, consistent solution. We used Basecamp (a staple on the design team) to share our work and explorations regularly and solicit feedback from across the entire product team. Even though the style guide group itself was small, we wanted to craft the core BuzzFeed styles with as many perspectives as possible. After all, these styles were going to belong to all of us.
Though a couple of our designers were already strong front-ends, we also decided to pair engineers with designers who had less front-end experience to write Solid’s code. Surely it wasn’t the fastest route, but it ensured a more well-rounded style guide team, taught designers how to write front-end and began to break down those old barriers between design and engineering.
Build, Break, Change
Once we’d implemented our first couple UI elements, things began moving pretty quickly. Soon enough we had a somewhat working style guide that we could actually build things with! And, of course, the Solid team immediately started building small prototypes with our shiny new CSS. We didn’t have to focus on crafting the perfect button any longer. Now we could focus on more important problems like user experience and information architecture. We were thrilled to be able to easily demonstrate an idea with code, whereas before most of us had been living in a world of static mocks.
As we started to share these prototypes as part of our normal design process, other designers wanted in too. We knew that the sooner we got people using it in their work, the sooner we’d discover things we missed, things we could kill, and what documentation was unclear. So, the Solid team helped designers get the local environment running on their machines. We used our public Slack channel as a way to answer questions from those using it and as a venue for collecting feedback. It soon became clear we needed a way to track issues, so we started to use Jira to manage our tasks and bugs. Things were really happening!
After using it ourselves and receiving feedback from the designers testing it, it became clear what was great and what needed more work. Our small team was able to iterate quickly. We changed class names when we realized they were confusing; we reorganized the navigation when it was hard to find things. And because our changes only impacted some small design prototypes, it was fairly painless to make sweeping changes when we realized we’d gone down the wrong path. Now, even though Solid is far more stable and being used in quite a few production environments at BuzzFeed, we still continue to evolve the code and documentation, knowing that as our needs change, our style guide has to change with it.
Compromises can make or break your team
Throughout the entire process, it wasn’t all rainbows and pumpkin spice lattes. To be honest, we’d regularly find ourselves in various disagreements. For instance, we didn’t always agree on how to structure the CSS. Should we use BEM or not? We discussed this issue countless times, and it’s something we are still struggling with today. We were all passionate and opinionated (and still are!), but we listened to each other and tried to arrive at most sensible product decision. We stayed focused by making the decision that made the most sense for us at the time. If we didn’t have a use case for it yet, we didn’t worry about it. We knew we’d cross that bridge when we got there.
Compromising isn’t always easy, but when you’re a small team working towards a single goal, you have to make it happen.
Early communication means no surprises.
People don’t like secrets, especially when it comes to building something everyone is expected to use in their work on a daily basis.
From the beginning, we had two goals when it came to communication:
- Keep the team small and the communication tight so we’d be able to move quickly.
- Be transparent about our process, the project, and the expected outcome of it all.
We knew we had to work in a small, nimble team to be able to build the style guide quickly. We didn’t necessarily want all of the questions thrown at us from the beginning because we didn’t know the answers ourselves. We were figuring it out as it happened. At the same time, we weren’t secretive about the project or the process. Our public Slack channel was open to the entire team, where we were happy to answer any questions we could answer as well as take suggestions.
Our early adopters were spreading excitement about Solid throughout the organization, but there were two other key events that helped us get the buy-in we needed to push Solid towards production. First, we gave a talk to the entire Tech team during our weekly Tech Talks series. We talked about why we thought Solid was important, how it was built and gave a quick demo of building a piece of UI with the framework. People were wowed and it felt really good to see the entire organization start to get excited.
About a month later, we held our first annual BuzzFeed Hack Week. We asked people to use Solid in their Hack Week projects while it was still in beta and then requested feedback after Hack Week was over. We were betting that if people found it made their lives easier, we’d gain even more momentum. We collected some valuable feedback over the course of Hack Week, but all in all, people were excited to have a framework that was easy to use. They’re hacks went a lot faster (and looked a lot better), and afterward we had a lot of folks clamoring for Solid to hit 1.0 so they could get it into our production environments.
The process continues
The Solid team still meets on a weekly basis, though the size of the group has decreased now that the guts of the product have been built. We review Jira issues, talk about tweaks we might want to make (big and small), as well as discuss adding new features. We know nothing we’ve built is set in stone, and that Solid is a living, breathing style guide that should and will evolve over time. Tech changes, BuzzFeed changes, and Solid will too.
