Skip toΒ content

Sharing survey results: Design system pain points

11 mins

View Comments and Reply

Transcript

Show Transcript

Hey, everyone. Thanks so much for participating in the lens design system survey. I'm just going to go through some of the takeaways based on what I heard from you all.

And then also touch on like how I'm thinking we can all contribute to lens moving forward and some other next steps based on the takeaways from the survey.

So at a high level what I heard from folks is that some components seem broken. Designers mentioned a couple of times that they often have to detach from lens to use them effectively, and that it's sometimes frustrating that we're not keeping up with some of the updates from Figma, such as auto layout.

A lot of our components don't use auto layout. So I'm curious how big of a pain point this is on a daily basis.

Like, are you having to like, not use lens? Are you having to like frequently like recreate things from lens, et cetera.

Also folks really resonate including myself with the parody between what's in production and what's in Figma. That's like a big strength of lens especially compared at least personally to other design systems I've worked with it's.

It just really helps have a shared conversation between engineering and design. And it also helps me pick my battles when it comes to creating new things.

Like if I know something's built it just really helps me be more effective when it, when it comes to creating new things.

And then folks mentioned, you know, it's relatively easy to use lens and it doesn't constrain exploration. And then about half of half of the respondents, or is that a word about half of the people who responded mentioned that they are comfortable contributing the lens with proper explanation?

I'm curious once I quickly go through what I'm thinking, as far as contributing to lens, how we can all contribute to lens, if that increases, if you feel more comfortable and more confident or less.

So that would be helpful to hear too. And then if we ever dedicate someone to to lens in the future, like overwhelmingly folks thought they should focus on fixing and maintaining the system and then secondarily focus on things like usage guidelines and then creating new things that help us do our jobs more quickly, which I think that all got all makes sense.

In fact, all of these takeaways were super straightforward, but just great to great to hear and great to ground myself in before diving into solutions.

So the first thing I did as a next step that I wanted to share is just like I mentioned, the contribution model.

So moving forward, how can we all maintain lens as a design system? And then also I think we should also think about how to address this first takeaway of a lot of our components feeling broken or not up to date.

Like how can we all contribute to making our system better over time? And I think actually these two next steps compliment one another and I'll, I'll speak to why in a sec.

So what I have in mind as a first draft for how best to contribute to lens is the following. So I know a lot of this will be super obvious because we're doing a lot of this instinctively or based on our previous experience, but I wanted to just like, for the sake of this document, like just formalize, like, okay, like when should I be thinking to contribute to lens?

And I think there are three primary like moments or triggers. So the first is like, when you notice that something's broken.

So you know, I think we all frequently when using lens, just notice that something doesn't feel right, or maybe we're tuned into like what Figma is updating.

And, you know, there's always opportunities that we probably see in the moment, but we're just too busy to make lens better.

So I think one way to contribute to lens is just when you have a second, you don't have to fix our entire system, but just, you know, can you write a, you know, a to do for yourself that takes five to 10 minutes to fix, you know, that one button or that one form field that just isn't working as well as you want it to.

And that's, that's something I've personally seen a lot of folks doing proactively on the team, especially folks who are new.

I feel like they're, they're just getting acquainted with lens and maybe they're used to other design systems in their lives.

So I I've frequently seen folks hop into the lens design system channel and ask why something doesn't work a certain way and then also volunteer to to, to do the work, to make it better.

So I think, you know, I think the takeaway here is like, that's, that's the most frequent way we can contribute.

And it's also a way to address that, that primary pain point that folks mentioned. The other reasons to contribute are I think the, the more what's the word, the less frequent ones, but I think the ones that are also more top of mind.

So, you know, when, when you work on a project that impacts an existing component, like you should obviously have conversations ahead of changing that component in the lens design systems Shanell, talk about the trade-offs mentioned any designers who maybe also have used that component.

For example, if the company teams frequently using something that I'm thinking about changing, how can I have a conversation with the folks on lens and with the folks on the company team?

So that's one reason. And then another reason is when you're introducing something new that you believe will benefit the team.

And I think this is also a conversation because it doesn't always make sense to add something to lens that's new.

So for example, if you know, you talk in the lens design systems channel about something you've, you've invented with your team and engineering, for example, can't commit to it.

What are the trade offs like? Does it benefit enough designers on the team that it's worth accounting for in the Figma version of our design system?

Even though we know we're not going to get to it from an engineering perspective, or is it something where, you know, we can address it in Figma, but engineering is willing to build it later and we just have to have the conversation about when and help engineering account for it.

So TLDR a lot of these are just having a conversation in the lens design channel. So I'm just going to get into with, with that, like how I think we can all contribute to a lens and I believe this will be really straightforward, but we'd love, love any feedback.

So like I mentioned, first and foremost, whenever you see an opportunity to fix something, update something or add something new, I think just start with the conversation.

So hop into the lens design system channel, maybe paying a designer or two who is relevant to the component you're introducing, or a lot of folks in the survey mentioned that they weren't comfortable with changing the design system on their own.

And, and really you shouldn't feel like you have to do it on your own. Like the great thing about like using loom and using slack is if you want to introduce something or you want to fix something like you have that whole channel to help you get it done.

And you also have like all the designers on the team. So definitely like ask a designer to like, double-check your work.

Even if they have nothing to do with, you know, the change you're gonna make once, once you've had that conversation.

And it sounds like, you know, people are resonating with the contribution you want to make. It's time to update Figma and there are two potential options for helping us all contribute to Figma option.

One is how we kind of unofficially do it today. So basically once you've had this conversation about what you want to do in the lens design channel, you then can ask for temporary edit access.

And often you won't even have to formally ask this, like, someone will just give you it from the channel. So for example, when I've wanted to change something in lens Manda from the lens design system team just opens up, edit access for me, I make the change.

And then once I've confirmed that I've made the change, she just revokes that access. And it's not, it's not that we don't trust folks.

That's just like, because we're not actively updating it. And we're, we're more consumers of our design system. It would be a bummer if we accidentally mess things up for others.

When we didn't mean to. So option one is really simple. It's all about just like opening and closing, edit access.

And then it also, I would say option one works well for a really small team and we are a really small team.

So it might be somewhere to start is, is my thought option two is we invest in the harder, more rigorous route that probably will serve us in the, in the longterm more effectively.

So what if we invest in teaching and supporting branching and merging on the design team. So for folks who don't know this Figma supports the ability to basically control who contributes to a design system in house.

So what I mean by that is let's say I want to make a change to lens. I can literally on my own without asking, say branch.

So I branch off from the lens design system. I make my changes and then I have to press a button that says merge.

And once those changes are merged, someone who is assigned as a reviewer has to know to review those changes and then approve them and put them back into lens design system.

The nice thing about option two is that it prevents errors. So if you're in a hurry and you're just trying to fix something, you're definitely going to have someone who is responsible for reviewing the work you've done and then approving it.

Which, which is nice. So, you know, it's, it's not, not on you to really have all those chats and make someone sees it.

The, the downside is it's more formal changes would get into lens more slowly, but maybe that maybe that's okay. And also the learning curve is probably low.

If, you know, we create a quick how to like how to contribute to lens. So I think there are pros and cons here.

The more I talk this out, I think option one will encourage more folks maybe to contribute to lens, but then option two would maybe get us all used to this idea of a more mature design system which would help us as we grow.

So I I'm kind of waffling and kind of thinking maybe option two makes the most sense and why not just use the tools that Figma is giving us, but the downside would be that we would have to have someone on the design team or multiple people on the design team who are willing to approve all the changes and we're all super busy.

So that could be a significant con, but that, that might just mean like, you know, for example, if I was one of those people, I would just have something on my calendar once a week or whatever the cadence is to just check and make sure I don't have anything to, to approve.

Once you've, once you've made an update, I think it's also, regardless of which option we go with, I think it's just responsible to, you know, notify the team in that same channel.

So you're using the same channel, always the communicate, but lens design system one. So tell the team what you've done.

And just so everyone's on the same page designers who are looking at the channel know what's been changed, et cetera.

And then if something needs to be done on the engineering side, so there's going to be some changes that are just like for designers.

Like, let's say you just fix a button that just makes it easier to use and Figma, you don't really need to let engineering know, but sometimes there's work that needs to be done on the engineering side.

So for example, if you update a component or you create a new component that engineering also wants to include they might not be able to get to it right away.

So I'm going to work with Amanda to define the exact details here once we're all bought into this, but the, the, just as the last step you should do, if there is an engineering component to an update you make is to just create a ticket in linear for engineering to get to when they can, because the reality is we're not going to be able to maintain both the Figma instance of lens and the engineering instance of lens simultaneously.

So engineering might get to it later than we do or vice versa. So bottom line is just create a ticket as your last step.

So I hope that all makes sense and sorry for the super long loom, but let me know your thoughts.

Transcript

More than 25 million people across 400,000 companies choose Loom

My teammates and I love using Loom! It has saved us hundreds of hours by creating informative video tutorials instead of long emails or 1-on-1 trainings with customers.
Erica Goodell

Erica GoodellCustomer Success, Pearson

Loom creates an ongoing visual and audible experience across our business and enables our employees to feel part of a unified culture and company.
Tyson Quick

Tyson QuickCEO, Postclick

My new daily email habit. Begin writing an email. Get to the second paragraph and think 'what a time suck.' Record a Loom instead. Feel like 😎.
Kieran Flanagan

Kieran FlanaganVP of Marketing, HubSpot

Loom amplifies my communication with the team like nothing else has. It's a communication tool that should be in every executive's toolbox.
David Okuinev

David OkuinevCo-CEO, Typeform

My teammates and I love using Loom! It has saved us hundreds of hours by creating informative video tutorials instead of long emails or 1-on-1 trainings with customers.
Erica Goodell

Erica GoodellCustomer Success, Pearson

Loom creates an ongoing visual and audible experience across our business and enables our employees to feel part of a unified culture and company.
Tyson Quick

Tyson QuickCEO, Postclick