Amber
Feinerman
Design Systems at Netflix
Amber Feinerman is a multidisciplinary designer with an affinity for intuitive and flexible systems. Over the past ten years, she’s utilized her hybrid skill set on a range of projects from prototyping for product innovation to leading design systems teams.
She’s enjoyed collaborating with talented folks at companies including Indeed, IBM, Shopify, Sprout Social, and Intuit.
Intuit
Sprout Social
Shopify
IBM
She’s currently a Senior Product Designer at Netflix, working on their design systems team to help scale and innovate design solutions across consumer experiences.
Can you walk us through the current state of the design system you're involved with?
Hawkins is two-pronged: the Professional side tailors to the feature teams building internal applications for Netflix, and the Consumer side focuses on the Netflix experience most people are familiar with.
Hawkins started as a grassroots effort on the Professional side, and after reaching a stable state of maturity, needs on the Consumer side emerged. This is the side I work on. We’re a tiny but mighty team building core components applied across our four main platforms: Android, iOS, TV, and Web.
While each side of the system tailors to different audiences and platforms, they share an underlying architecture through design tokens and assets (e.g., icons and illustrations), ensuring that all experiences powered by Hawkins look and feel like Netflix.
What tools do you use to build and maintain your design system?
We are fortunate enough to have an excellent team of Design Engineers that we partner with to help us build custom solutions for most of our needs, but there are still common industry tools that we leverage. We use Figma to maintain our design libraries and Storybook to visualize our components for our engineering toolkits. We also are currently exploring more robust CMS solutions for our documentation that we can build upon for our needs.
OUR TOOLS:
Figma
Storybook
Custom plugins
Hawkins API
How do you balance the need for consistency with the desire for creative freedom among your designers?
I would say for any design system, it’s a fine balance that always needs recalibration. We strive for visual and experiential cohesion where possible, but it’s important that we allow for teams to extend the system in ways we can’t predict so that the system can evolve alongside our product.
The general guidance we give designers is to leverage Hawkins's components and assets. If they need to build something custom, then leverage Hawkins tokens. If they need to build something that doesn’t use Hawkins tokens, then reach out to us so that we can learn about their needs.
How do you stay true to your vision for the design system, even when faced with external pressures or trends?
We have a roadmap for our design system that we evaluate throughout the year to ensure that ad-hoc requests and support don’t distract us too far from our goals.
Still, ultimately, we try to remain nimble so that our priorities can flex based on what the business needs. We don’t want to be too rigid that we can’t shift where teams need us to.
How does your team collaborate on the design system?
Weekly broader meetings
Weekly internal syncs
Office hours
Weekly engineering syncs
Slack channel
Feature teams forums
Our broader Hawkins design team (Professional and Consumer) meets weekly to review each other’s work or discuss about big-picture strategy.
On the Consumer side, our team has weekly syncs amongst designers to stay informed on what each other is working on and to jam on solutions together. We also meet with our engineering stakeholders weekly to partner on enhancements to the system and troubleshoot issues.
We partner with our feature team partners in a few different ways. We have a dedicated Slack channel where we offer cross-functional support. This is generally where we point folks to first as this is the quickest way to get in touch with us.
We also hold weekly Office Hours where folks can sign up for assistance, and we leverage breakout rooms to divide and conquer where possible. Finally, we try to attend relevant feature team forums to stay informed of what our design partners are working on and what has been productized.
Are you tracking your design system? If you had to choose one metric to measure the success of your design system, what would it be and why?
We haven’t put an emphasis on tracking the system, but are starting to think about metrics now. We have three significant audiences to think about: our senior leadership, our feature team partners, and our design system team. Each has different needs and would interpret the metrics differently.
Let’s look at adoption. For example, senior leadership might want to see adoption metrics as a way of understanding the ROI of the system and how much efficiency we’ve gained as an organization. Feature teams might want to see adoption metrics in regard to coverage across their particular projects to understand better how much they are aligning with the system versus needing to deviate. Finally, our internal design systems team might want to see both to understand better where to invest our resources.
I used adoption as an example, but adoption is just one piece of the puzzle. Other metrics we’re thinking about are around engagement, contribution, and happiness.
If you could go back and change one decision you made in your design system journey, what would it be and why?
This answer is not exclusive to Netflix, but I think what I would love to see more design systems do (that I haven’t done too well myself) is test/validate net new design decisions before officially integrating them into the system. Oftentimes when designing a new component or consolidating many patterns into one component, design decisions are made by systems designers that are then distributed throughout the product without thoroughly testing to understand the business implications that this can have. Sometimes, these decisions can cause a dip in metrics that then cause hesitation around adopting the system.
I’ve learned it’s better to partner with feature teams to test new components as early as possible, even if it means a few rounds of iteration. It’s a lot easier to get folks to adopt the system if there’s data that the system will not harm metrics (especially PM partners).
Where do you see design systems heading in the next few years?
I see less of an emphasis on designing and maintaining separate libraries per platform and instead shifting to a single library of components that have been designed for a variety of contexts that are platform-agnostic. Each element would be designed across core attributes like screen size, controls (e.g., mouse, keyboard, touch, remote), and orientation that can be applied across various devices no matter what language they’re coded in.
What's one thing you wish more people understood about design systems?
Don’t let what other systems are doing influence your system too much. While looking at systems like Google’s Material or Apple’s Human Interface Guidelines can be helpful for inspiration, or when designing for their platforms, it’s important to remember that they are systems for platforms, not a singular digital product.
Each design system varies from company to company based on the needs of the design organization and business. Focus on what works best for your team rather than trying to keep up with the industry and make small business impact decisions.
In your opinion, what are the most overrated and underrated aspects of design systems?
The most overrated aspect of the system: Building components.
The most underrated aspect of the system: Building relationships.
Components don’t solve the complex problems that help our users. People do.
I’m not saying that components aren’t important. Components are an essential tool to ensure that the solutions previously built by people are leveraged. They are core to a design system. But over time, the list of components stops growing, and the needs shift to more robust tooling and architecture.
If your design systems team is not building relationships with the folks using the system, then you can’t ensure that your components and tooling are solving their needs. If the system isn’t meeting their needs, or even better, anticipating needs they didn’t even realize they have, your system can’t thrive.
If you could have a coffee chat with any person from the design (system) space, who would it be and why?
This is hard for me to answer. I can’t think of just one person because I think there’s something to learn from all folks working in design systems. After all, the work can be so different from company to company, industry to industry.
But if I had to pick one company, it’d be Figma just to learn how they’re building for the needs of design systems authors, maintainers, and consumers.
Coffee with Figma?
What's one piece of advice that you would like people to remember from this interview?
No one team or person has it figured out. This work is complex, and even the most shiny systems have issues we don’t see. Take everything you read or hear (including this!) with a grain of salt. Remember to think critically about how your design system can best service your business needs.
What's your favorite thing to do when you are not in design systems?
When I’m not thinking about design systems, I like to play around with CSS and tools like GSAP for fun. Even though I work as a Product Designer primarily using Figma, I still enjoy coding where I can.
When I’m not at a computer, I’m usually snuggling with my cats and husband, watching a movie, working on projects around my home, playing my PS5 (currently Alan Wake 2), or exploring Florida nature (when it’s not too hot) with friends.
