BTP: Creating a Design System with Jason Grant
Behind the Pixels is a conversational blog series that aims to give a glimpse into the work & life of being a designer at Klaviyo
AH: How about you start off by introducing yourself? How long have you been a designer and then how long have you been at Klaviyo?
JG: I’m Jason Grant, the Design Systems manager leading a team of designers, technologists and content strategists at Klaviyo. I’ve been a designer for about 25 years. The first 11 years of that was designing building architecture, the physical product. I then had about three years transitioning between the physical and digital where I managed, trained and implemented a product for architects to convert from two-dimensional design to three-dimensional design. That was my launching point to move into the software world where I have been designing digital products for 11 years. I’ve been at Klaviyo for about ten months.
AH: Okay and starting super basic here — what constitutes a Design System? And why is it important in UX?
JG: While many people look at a Style Guide of colors, typography and logo usage and feel like they have a “Design System”, it is so much more than that. These are the first aspects of a Design System, but the color needs typically far exceed the brand palette of a Style Guide as well as needing accessible versions of success and error. The next level on top of the Style Guide is a Design Kit and Component Library. Both of these have different purposes. The Design Kit is built in Sketch, XD or Figma and serves the needs of designers. The Component Library is built in Web Components or a front-end framework like React, Angular or Vue, which serves the needs of engineers. While having all of these is good, you are still not done. Everything then gets wrapped up in documented usage guidance for design and code samples for engineers. This includes what the purpose is for the component, what are acceptable usages of it and where to avoid using it. It also includes a higher level of rules. For example, if you have less than 5 options in a dropdown, perhaps you should use a radio button or checkbox group to better reveal options to your users. While a button is a button across many companies, each company has slightly different rules on how it’s used. Those rules help drive consistency and that consistency helps the end customer that you’re addressing.
AH: You’ve had several different roles in your design journey. What originally made you interested in doing Design Systems work?
JG: Architecture is heavier on systems-thinking than many envision — you don’t just sketch a building and then it’s done! There’s a lot of thinking around how all the pieces come together. How do all the invisible parts like studs fit within the wall and what are the rules and codes behind it? Design Systems are the natural connection between where I was and where I am now. I have done more typical UX design along with the Design Systems work, but I always kept gravitating towards the front-end code and system-thinking. When you have the design-thinking mindset, you focus on the customer and their journey through a process. System-thinking takes a more global look and not only addresses that same customer but many customers. Not only does a system thinker need to anticipate the needs of multiple customer journeys, but also how designers and engineers will utilize those elements to create solutions.
AH: As a designer, I can say I highly appreciate having you guys thinking about the whole system! And a Design System team in general is made up of several different design disciplines. Do you want to give us a little detail into your ideal team makeup and then what our team at Klaviyo looks like at the moment?
JG: The team makeup is really based on what you’re trying to achieve as a company as well as how big your company is and what platforms you support. If you have a web app and then you add mobile, that changes the makeup of your team since you might need specialties in native Android and native iOS. Since you are systemizing a lot of work that trickles down to designers, there is a greater need in specialization. If you’re trying to set up motion standards, you need a motion designer. However, you don’t need a motion designer on every project if you create rules, systemize that into components and write standards. So the ideal team is really dependent on your specific needs.
For Klaviyo, we are focusing strongly on the tooling aspect to enable Figma to drive efficiency for our designers and also consistency in the handoff to engineering. That’s one of our core focuses that we’re building up and we’re investing heavily in plugins for Figma because we think it’s really important to our future goals. In addition to that, we are a data focused product so we have a need for effective data visualizations. Because of this, we have someone focused on data visualizations on our team. And then we have a motion designer to help us start modernizing our product and get it to a point where motion isn’t just used for flashy things, but it helps grab the attention of the user in an effective way or show them the status of what’s happening in the system. This helps the customer feel at ease and guided to the next step in their process. In addition to all those, we also have branched out into content strategy as well. Because an effective product is not just one that has nicely laid out visuals, the content is really core to how a customer understands how to use the system. Why are they clicking that button and what should happen after they click it? Therefore, consistency in both design and content is really important.
In the future, we’re also expanding the team to start targeting the greater UX by standardizing patterns. We have a lot of teams that work on different areas of the product, but they have similar customer journeys. So, as we expand the team, we’ll have someone that focuses on all the web platform patterns and customer journeys. So how does one journey [on the web] look different from another? And should those be more consistent? We’ll also have someone focusing on mobile experiences, someone on internationalization and then, as the design team grows more, we may need someone to help on the Design System operations side. That role will likely be part of our Design Ops team, but there would be a strong partnership between the two to drive the experience of Figma training, feedback on what we’re doing well and what we can improve on. Because Design Systems are a product serving designers and engineers, we need to treat [the Design System] the same way as any product team by getting customer feedback. Our customers are both internal and external.
AH: So the PSA here is that Jason is hiring from now until forever! And then you all work a lot with our front end development team. Do you want to tell us a bit about that partnership and collaboration?
JG: Similar to how the different roles on a team depend on the needs of a company, how the Design Systems team is structured is based on how the company scaled. At Klaviyo, we have a Design Systems team and we have a Component Library team. Without knowing how Klaviyo works, someone outside the company could see this as a red flag and the assumption would be that we have siloed teams. That is not the culture of Klaviyo where we collaborate radically and provide open and honest feedback. We have different teams because the teams have different management needs for the mentorship and growth of each team member. We have a really strong cross-collaboration between our teams, which includes a weekly cross-functional meeting and shared retro/sprint planning meetings. I also attend the engineering daily stand up to help keep the number of attendees small, but keep the two teams informed about any blockers. We also have pairings of a front-end engineer with a Design Systems designer. When there’s a new feature, that pairing will meet on their own, one-on-one throughout the week as needed to talk about the decisions that are being made. It’s really about driving communication so that we’re not surprising anyone. Engineering shouldn’t surprise design and design shouldn’t surprise engineering. We should be on the same page and understand what’s going on — communication is really the key to success.
AH: Awesome. And then how does the Design Systems team integrate and work with the product teams and the other designers?
JG: I’m going to talk to you about where we are today and where we want to be next quarter. Currently, we are a new and growing Design Systems team that is focused on rebuilding the foundations. We are aware that the design team wants greater collaboration and guidance, but until we do the research, propose changes, get feedback from designers, write specifications and get those implemented into component changes, we can only provide feedback based on the past guidelines.
Alongside the foundational changes, we have been planning for how to modernize the product without frankensteining the user interface in the process. With this comes the implementation of Design Tokens into the Component Library and other behind-the- scenes work that the design team doesn’t see.
Similar to renovating a house, most homeowners don’t care how the plumbing or wiring is completed. They just want to ensure the outlets, lights and plumbing fixtures are in the right place. As we change the plumbing of our React Component Library, we look for feedback from the design team to ensure we are going in the right direction.This next quarter is all about releasing new components and starting to implement changes to the design and engineering of pages. Collaboration with the design team is going to be really integral at this point. We need to work on training. We need to work on how we deprecate components and move to the new ones. It’s going to be a crazy year, but it’s really exciting. And I’m really looking forward to the product being completely modernized.
AH: So sometimes I think with Design Systems people feel like it can limit designers or make them feel like they can’t request changes or make anything new or different. How does it work here or in general if designers want a new component or are trying to do something that isn’t in the system?
JG: We only expect that 90% of the product at best would be a Design System component since there are unique product features that may only be used in one place. We look at components at different levels. There are abstracted core elements that are used within most designs and are also embedded into other components. Being abstracted means that the component is flexible to accommodate many different scenarios and use cases. Then there are feature-specific components that are reused for similar customer journeys. For Klaviyo, an example would be our email and SMS builders. As we start thinking of other uses across the product for these features, it is essential to componentize them to provide our customers with a consistent experience and increase our maintainability for them by engineering.
Outside of standardization, we are working to set up processes for designers to explore. They can explore new patterns, create new Figma components and use those in their design within a shared exploratory Figma library playground. This library is open for the entire team to contribute to and is a place for the Design Systems team to collaborate on the future visions with the design team. Our Figma library of components aligned to React equivalents is restricted to fewer team members, so we can ensure consistency and reliability.
Design Systems can be a blessing and a curse. You have a huge wealth of components that you can use, so it seems logical to start with what you have. For simpler design challenges this is ok, but I do tell designers to not to rush into using components when envisioning a new customer journey or a new pattern for solving a problem. By not jumping to using components, you can stay loose and make infinitely more design iterations. Once you have a solution, then you can determine how existing components can be utilized to solve that and if not, you have a clear use case for what is required.
AH: Love it — constant collaboration with a flexible, always growing system. So you have mentioned a few things, but what has been the most challenging aspect of building the team at Klaviyo so far?
JG: Hiring is difficult — finding great people that have system-thinking mindsets is essential. Can they look at the unintended consequences of decisions, as well as understand and describe the purpose of these components and why we need them? When you’re hiring a team of specialists, each one is a unique hire and that is tough. It’s not like you can just say we need five product designers and all of them should be measured against a similar skill set. Instead, we’re looking for a motion designer, a UX engineer, a UX technologist and then a person that has experience with data visualization. It makes sourcing a lot more difficult, but luckily I have a great recruiting partner. The other challenge is we are very cautious in who we choose to bring on because we’d rather take the time and hire the right people than rush and hire the wrong people because that has long-term effects on the team. So far, we have gotten some amazingly talented people.
AH: Totally. So far you guys have hired an awesome team. I can vouch for that! So then, looking ahead, what are the biggest upcoming challenges for the team?
JG: As I mentioned before, my biggest concern is what level of frankensteining are we comfortable having in the product even if it’s for a short time. When you’re transitioning from one look and feel of a product to a new look and feel, there are a lot of in-between steps that are unavoidable. We don’t really want to do a big bang change, where we just drop an entire new experience on our customers. That typically doesn’t work well. We want to iteratively change it so that our customers can ease into it — smaller changes over a longer period of time. But at the same time, you don’t want to degrade the experience that the user has. It will be a delicate balance with a lot of moving parts. It is really important for us to over-communicate at this point or else we will get a lot of questions as to wether something is intentional or not. This includes the design team, product managers, support, engineering and others across the org. They all need to understand what each next step is in the transition.
AH: Definitely very challenging. And as designers who focus on the details, I’m sure it makes everyone a little crazy. On the positive, what are you the most excited for in the future?
JG: We will be transitioning from a product that looks like it’s 10 years old to something that has a modern look and feel. A product that is responsive, built for internationalization and is enhancing the experience for our users. That’s really exciting. It’s such a big challenge to get from A to B. You wish you could just press the button, and be there but that challenge makes it so much more satisfying when it is complete.
Hopefully you have had an experience like climbing the steps of a monument, pyramid or mountain. It’s exhausting, sometimes feeling like the steps will never end but when you get to the top, turn around and look at the vista, it makes the journey worth the effort.
That’s what I’m really excited for — this end state that we’re getting to and knowing that’s only the beginning. We’ll iterate forever after that. You can never have a perfect product. You can never have a perfect experience. But we can get significantly closer to where that would be with each iteration and improvement!
AH: Building the Klaviyo pyramid. Good analogy. All right, two final questions about advice. First, what advice would you give to someone who’s interested in learning more about or becoming a Design Systems specialist?
JG: For this, I would definitely look up the differences between design-thinking and systems-thinking. I think that it is really important to understand the type of person you are, because with design-thinking you’re looking more at empathizing, defining, iterating, prototyping and testing. But with systems-thinking you’re looking at how elements of a system are interconnected and how the elements work together. How do they relate to each other in a complex system? And so it’s two very different approaches to working. The first step is to understand where you’re at and where you want to be in your career. I’ve been mentoring on ADP list and I get a lot of questions like, “How do you get your first job?”, “How do I get into Design Systems?” Many times the conversation moves to recommending the individual step back and think, what are your goals? You shouldn’t just apply to any job. Think about whether you want to work for an early startup, mid-stage startup, mature product or are most comfortable in an enterprise environment. What you want in the environment, team culture, and type of work are the most important aspects and allows one to target the best companies for you, not just what you think is trendy. Focus on what you specifically want to do and double down on learning everything about just that and you will impress the companies that align with your passions.
AH: That’s good advice. And then the second question, for those who are not lucky enough to have a Jason Grant and team at their company but still want to make strides towards a Design System or just getting more consistency in their product, what advice do you have for them?
JG: Start with baby steps. What you can realistically accomplish depends on the size of your company and the investment in Design Systems. Don’t expect to be at the maturity of Shopify, Adobe, or Atlassian. Those are unachievable goals for a team of 10 product designers, maybe even a design team of 100. Rather than feeling discouraged, use these companies as an aspirational goal.
The most important aspect is not going wide and creating every guideline or component possible. Instead, go deep and create what will be important or provide value for your design team. This will make a greater impact. If you’re a small team, you probably don’t need a lot of guidelines, because you can easily talk amongst your team. However, you probably need a good Design Kit to help the team be more efficient and to drive that consistency of the Style Guide with the components as you grow.
As Klaviyo is scaling, what’s really important now is getting the design guidance out to designers. Because once you get to an inflection point of growth, where you have too many people to easily check in with, it is difficult to get alignment. You can’t ask everyone, “how do we do this”? It has to be written down and you can break rules if there’s a valid customer reason to it, but if there isn’t a reason to break that rule, the guidelines should be followed to provide more consistency for your customers. So don’t worry about being perfect, just take each step one at a time. If you find that you are saying the same thing over and over, write it down as a guideline and over time, your guidelines will grow. Design Systems are a marathon, not a sprint, so pace yourself and enjoy the journey.
🖌👷♂️— Jason and team have been making huge strides in creating a world-class design system for Klaviyo. Looking forward to making it to the top of the pyramid!
Does working on a growing design system sound like your perfect job? We’re always looking for great people to join our team.
