Linzi Berry — Design Systems Lead at Lyft
Hi, I'm Linzi Berry. I work at Lyft on the product design side and I have been working on design systems here for about three years. Previous to that, I got into design systems at a small agency called Odopod. When I worked their design systems was really at its beginning in the web, which was just, “Hey, we need to make these giant websites and we need to be able to do them at scale.”
It started more as like, “How do we templatize these things so that we can just fill it with content and use the same modules over and over again?” So I worked on that for maybe like four or five years there, doing large sites like Sony, Audemars Piguet fancy watches, Beyonce.
But when I worked on it there, it felt like I was only doing half the job. I was like, “Okay, cool.” I would build out these color sets and the componentry and I would hand that off to the company with hopes and prayers that it would come out how I intended it.
I kept noticing you'd give it to them, a year later it would finally come out and it would look completely different and just be this completely different beast. I was like, “There's something here that I'm missing. There's something here that I haven't quite figured out or latched onto in this agency world.”
So I went to Lyft because they were specifically looking for someone who was interested in visual design and quality through brand, which tends to be more of my background. Then when I got here I was like, “Okay, so where's the design system? Where's the rules I got to follow to do stuff here?” They're like, “Oh, we don't have that.” So here I started working on that from the beginning. So it's been great.
Wow, that's awesome. All right, so Linzi, let's get right into it then. Now you're in-house. You're at Lyft. Just come from the agency side and now in-house. What's the most difficult thing that you're facing now in relation to design systems? Get it out of your system?
I love that catchphrase. So I think the hardest thing right now is that we're about two years into our system. When we think about it, we have enough components that people are using them quite frequently. We're larger on the mobile side, we're getting up there in the web, we feel like a fast follow.
We recently had a retrospective, we do them monthly on our teams and I was like, “Oh, this is the perfect time for me to realize what is our biggest problem from my teammates versus just my perspective on it?” The topic that came up that I thought was really, really interesting and a reflection of how we're working versus the work that we do is this idea of us being too reactionary versus intentional.
What I mean by that is that we work so closely with our users, the designers, and engineers at Lyft that we end up in a place where we're getting feedback quite often. That feedback can come from various places, but when we respond to that feedback, however long or short we end up responding, it can feel very reactionary versus the intentionality that we may have when we start planning a roadmap and we have all these ideas around exactly what we want to finish in a quarter or a half.
All of this input and feedback from the people sitting right next to us are seemingly like throwing us off that original roadmap or a intention-based designing or building. I think that to me was an interesting reflection on how our team has been working and how our team essentially thinks about how we work and how we work as a way that's the most impactful for the company.
That is fascinating. So I work on the agency side. I run my own agency, SuperFriendly and you just talked about you coming from Odopod on the agency side and now being in-house. So a lot of the work that we do is with in-house teams and we were just having with one of our clients that we're helping build an enterprise design system, we were just having the same conversation, which was how do we be more proactive about the work?
Especially because in a agency environment we're doing what they hired us to do. So if they say, “We need you to help us build this thing, “ we go and help them build that thing. Part of the thing that we came to in our conversations was in order to be proactive we sort of have to do stuff that they're not asking us to do. But we sort of have to look past that and go, “What are the thing that they're not asking us to do, but where we can provide a lot of value and provide impact?”
So how do you think about that kind of on the in-house side where I guess when you're working closely with users, does that mean you have to be doing stuff that they're not asking you to do?
Totally. I think it can even be how we solve things differently or a way that we can approach support. So a really great example of where the problem shows up right now is, and these are all with the best intentions. So we have people who are dedicated on, we build, we maintain, we support, and the support aspect is like every day on Slack people ping us with questions or requests or bugs and sometimes the request or bug that comes in is totally meaty and worth talking about and super interesting.
People will come in with results of them testing our component and saying like, “Hey, we think that we actually should change this aspect.” Right now our toasts are not tappable, or they want them to be tappable and they literally tested how many times people tried to tap our toast. If they put different things in it and they're like, “This is amazing.” We appreciate the work that they're putting into it.
I think that where that comes in is we get excited. We know that we could be impactful by helping them right now by making our toast tappable. But if we were to take a step back and be like, “Hey, if we actually rethink our messaging flow and how we want this to show up across everything.” How we want this to show up across various parts of the system and not just solving this one use case that they have tested, it could be a way for us instead of being reactionary and fixing it for right now to take that step back, take that time and plan for it in a more holistic vision of fixing not only that component but the other components that led up to that component existing.
Discovering where the actual button should be, should it actually be in that thing? Should it be in the toast or should it be somewhere completely different? It's just that we're jamming something into the toast that may not need to exist there to help them with their particular problem.
Yeah. I got it. That's cool because it makes and it makes sense with the design system team and that you all have purview that a particular user or a particular product team might not have. You have a lot of context so it makes sense that you all could sort of zoom out and go, “Okay we know that the problem that's being reported is at particular level but if we zoom out or if we take a step back from it then perhaps that's just a symptom of a deeper problem.”
Do you ever run into situations where what a user would report or what somebody who was working on a product would report about the design system? Do you ever get in a situation where you just disagree with what they're saying?
What do you do about that?
I think that for us it's a decision between emotion and science and our team in many ways wears the science cap as our way of defending particular actions that we've taken.
Anytime that something is more emotional and that is typically on the visual design spectrum, we can go back to science to help ourselves out. So a good example might be someone comes back and they're like, “Oh, I don't like the padding that you've added into the tooltip.”
This is a literal real example that came back yesterday where they're like, “It feels too tight.” For us what we can do is come back and say like, “Okay, yes, totally understand that this may feel too tight in this particular scenario where you have a lot of ample white space on your page and you have it pointing to something that's very poignant and not covered with other UI, that it feels like a tiny thing.”
But if we take a different screen like the mode selector, which is where you pick the car type in our rider app, if we take that type of screen and we look at it on an iPhone SE and we have it in the tiniest space with a ton of UI and we put this tool tip in that space, then does it work for that too if we add that ample space back in if we make it larger?
That's just proportions, that's like, “Okay, Cool. How much other UI do we cover up?” Then that usually helps them see why a more visual decision was made to help them better understand that aspect.
A lot of times the feedback though is mainly around accessibility, the misunderstanding around how accessible we need to be or what color ratios we need to use or why something feels dark but they want it to feel lighter just relies a lot on education and just being like, “Hey, we did this because there's these best standards and there's these laws that we have to follow to get there and we're not being jerks and we don't like ugly things, “ but we're trying to make it look best with the constraints that we have and the more we can educate on those constraints I think helps people then take those internally and then they go back to their teams and then are also able to educate their teams as well.
Do you ever find yourself going the other way? Because what you just described was when people come with kind of an emotional complaint you use science to help quell that. Does it ever go the other way with people coming with data and something really scientific and you're actually saying, “Well, we want to rely on our intuition here, we want to rely on some emotional cues to be able to help guide us along”?
I would say it's rare that we would ever win that type of discussion, that if they're coming to us with straight-up science or metrics, it really depends on how far those metrics go, or if they're, if they're believable enough, if the research is good enough and there's not a lot of holes, you can punch in it, then I think it is worth us investing the time to really dig into that science versus us really pushing for the emotional side without having the backing to go against it.
Yeah, that makes sense. How much do you think that the role of a design systems team is to be reactionary versus intentional? How forward-looking should you be versus really being the team that feels, people are using this product in the wild or in their work and you all are supporting that product. It seems like part of the job is to be reactionary. What do you think is a good split?
Totally. I mean, and I think that's right now to me that is the hardest question that we're asking ourselves is are we at a point where we need to ... I mean we've put out a certain system. Like we talked about their support that comes in, but then I think that there's also this ... there's like this idea of perfection which we ourselves put onto the system.
So the system's been built over time. We've got smarter over time. We have more education. The components that we're making now are better than the components that we made two years ago, and we are re-examining this, the work that already exists.
We're looking at our color spectrum and we're like, “Well, is this actually good enough? Is what we had two years ago still valuable enough?” So we're throwing ourselves off our own roadmap or what we had perceived that we should be doing because we're realizing like, “Hey, there's actually some problems within what we already did and should we take a step back? Should we fix it now because we don't want to be perceived as liars?”
That we're like, “Okay cool.” Our complete color spectrum is accessible. Then if we find one color that's not accessible then we get very perfectionist about it because we're telling people that using our stuff is good and reliable and trustworthy. So if we find that one thing is wrong, do we immediately go and drop everything and change it and treat it like a bug or do we say like, “Okay, we'll plan for this, “ and we'll intentionally revisit this later?
So it's coming from that support aspect. It's coming from internal perfectionist aspect. Then I think the last one to consider is more around Lyft still treats itself as a startup even though it's a large company and these large business initiatives come in. The type of work that comes in will be like, “Hey, this is on fire. This needs to be something that everyone's working on, “ or a particular team is tasked with solving this really juicy, meaty problem.
In our case, what could happen is we could be more hands-off and stay with our intentionality and working on more future-facing problems or we can help them now so we don't have to clean it up later. They could do something where they can't use the system and then if we don't help them at this moment and get them to use the system, then later it'll be a much harder effort to try to get them back on.
When we do help them, when we do drop everything, they see us as incredibly impactful, incredibly helpful and they'll talk about us as being this great team to work with. So it's really hard to spring for the more forward-thinking initiatives even though we 100% can see the value in them because the impact isn't as strong in the day to day from a quarter or a half perspective.
We would see the benefit of that work maybe the next half or the next year. I think in particular the way that our company is set up, I think the initiative to be impactful sooner is definitely there. So I think we're trying to find that balance and I think we're talking about it more proactively now around how do we do the that far-reaching future work that sets us up better.
Well, you're already talking about it, so this might as well be a good place to end this. My last question for you then is, do you have tips for teams that are kind of in the same place as yours where they want to be more intentional rather than being reactionary? What advice would you share with them?
Yeah, I mean I think the big thing for us and part of what we're working on as a team now is we used to talk about 2020 vision as like, “Hey this is what we want to be in the future and this is where we want to go.” Now 2020 is literally around the corner. So we're doing 2040 vision project, which is more just like, “Hey, once the system is fully adopted and we do have all the pieces that we would want to have, what areas can we actually start pushing in that are beyond the basic system set up?”
How can we think about education in general? How do we teach designers and engineers to be better designers, better engineers? How do we think about the tooling processes that goes into the system versus the system itself? How can we look at these pain points that we're seeing where the system collides with just day to day work and honestly fulfill the mission of being the canonical way that you design and engineer at your company?
Because if the goal is that, then the system doesn't have to be solved the same way everywhere. You can rethink about it and come up with some crazy new ideas and then that is a vision that you can push all of your work towards over time.
I love it. Well, there you have it. The most difficult thing Linzi's up against regarding design systems is figuring out how to be more intentional instead of being too reactionary.
Linzi, thanks for getting it out of your system and I'm sure you're not the only one facing this. I'm Dan Mall from SuperFriendly and thank you for listening to this episode of Get It Out of Your System.
Mike Aparicio — Senior User Interface Engineer, Design System at Groupon