Interview with Emily Brick
Senior Product Designer at Buzzfeed, where she focuses on the site experience and their CSS framework, Solid.
What got you into design systems?
I became pretty interested in design systems thinking pretty early on in my career. I didn’t consider systems in all the ways we think of them today, I mainly wanted something to handle my day-to-day responsibilities more efficiently. The team I was working on at the time had 3 designers (including myself), and close to 30 full-stack engineers, none of whom showed a particularly strong interest in front-end or CSS. The design team began utilizing a fairly “bare bones” atomic CSS framework; it was for no other reason than to make less work for ourselves. We had to work at a pace much faster than we were able to, and creating a system made coding our designs easy and fast, without cluttering up the codebase. From there, I was introduced to some of Brad Frost’s writing and work, and I guess you could say that the rest is history.
Who have you been inspired by, past or present?
I’ve been really inspired by Kat Holmes lately. She’s led the way at making inclusivity in design a priority at Microsoft. Their Inclusive Design Toolkit has really helped to spread and publicize knowledge around designing for everyone, in a more approachable way than other documentation has in the past. The toolkit also embeds those principles as part of a larger ecosystem in which to design around.
What tools (software, physical tools, design or code) are essential to you in working on design systems?
Probably any tool that can efficiently increase transparency. For us, that’s been Slack, GitHub, and Basecamp. Forgive the kitchiness of this answer, but I think the only essential tool that every team needs when working on design systems is early and often communication (probably goes without saying that negotiation and debates are healthy, too).
If you look back over the past year, what would you do differently?
Solid is a CSS framework (or pattern library, or atomic style guide, or code legos, whatever you prefer). We hadn’t really considered building a component library while building Solid, aside from some obvious lightweight use-cases. Now that all our apps run as microservices inside a mono repo, we’re seeing a ton of duplicative chunks of functional code and UI that have no easy way of cross-referencing each other.
So, we’re starting now — a bit retroactively — to build that library of shared components. If I could do it differently, I think I would have pushed to get us thinking about a component library earlier on. The technical benefits of shared components alone get you so many wins. Additionally, putting a component in a shared location with the intention of being utilized in multiple places forces you to consider the reasoning that the component looks and acts the way it does.
In the past few months, what’s something that you are really excited about?
I’m pretty pumped that Sketch’s file formats are now available as JSON data. I mean, how cool is that? I’m excited to see all the different ways we can bridge the gap between code and design using new tools. I’d wager to bet anyone reading this right now is already familiar with React Sketch.app, but that’s been something I’ve been oo and aah-ing over. It reminds me of this talk by Brett Victor from almost 5 years ago — but still so relevant today.
Emily presented at the Design Systems Coalition NYC meetup in December 2016, check out the slides and video from the meetup on designsystems.nyc
