#12 UX Design systems
52:39 Share

Having this predictability, having this library established makes it so much easier for you to focus on problem solving rather than, you know, building visuals over and over again. Hello everyone and welcome to a new episode of Honest UX Talks. I'm Ioana, your host for today and I'm joined by my regular co-host Anfisa.

Today we're going to discuss a really exciting topic, that of design systems.

And as you all probably know, design systems have been all the rage for the past couple of years. And it felt like it's this buzzword that everyone keeps throwing around. And now I need to have a design system even for my personal brand. And so we're here to clarify what design systems are.

why they are important, when they're needed, and many other things around them. But before we move on into that, I'd like to respect our weekly ritual and invite Anfisa to share with us how her week went. ♪

Well, thank you so much for inviting me and welcome everybody to the next episode. Let's quickly really do a quick recap. We actually just had like a brief conversation on our past weeks. It was pretty strange. We shared with each other that we kind of have

Some symptoms of COVID, but it was not COVID because we got negative tests. So God knows what's going on right now in the world and why we have all those strange feelings and symptoms and headaches and fevers and whatever else, weaknesses and stuff. But luckily, reportedly, we both feel better right now. And that is a good news.

Other than that, there are small nice updates. For example, I'm finally finalizing the design system, which is basically a topic of today, the design system for my social media. So I hope I will quickly sort of cover how I went through the process. Maybe it will be useful for our listeners.

And yeah, right now I'm on this finalizing sort of period where I try to sort of conclude a design system from a social media because I was taking the break for two months from Instagram, from almost any other social media network. And it was literally just because I felt like

my system right now is the mess. I don't know. Like I had to spend way too much time, but the effort is high and the impact is very low. So I'm like wasting too much time, but I don't like the return on my effort investment. And I needed to optimize and streamline all the efforts that I'm doing to build the posts and content. And design system was just an answer, the perfect answer. Well, first of all, the answer was to create a new branding and

Then I was to find a helper assistant who will help me to use the new branding and the design system that would kind of make the whole effort of content creation much more smooth and, I guess, easier, more pleasurable, focusing more on content rather than, you know, building content right now on the internet.

So I'm in this final stage. Hopefully in March, we'll start posting something. I do have a lot of excitement. I can't wait to start sharing things that we were working on. But yeah, that is it on my side. How about you? How was your week or two since we didn't talk last week, actually?

Thanks for sharing your week with us, Nafisa. It's a way better week than I had because I had the most horrible week in a while now. Just like you said, I also had some really...

strange health symptoms. They debuted, uh, very suddenly on Saturday evening, I had this beautiful walk. Everything was going great. I was dancing around the house and then boom, high fever, horrible headache. Um, and since it didn't subside for 24 hours after on Sunday evening, I was at in the emergency room at a hospital trying to figure out what's happening. And I couldn't figure out what was happening. That's the strangest part. Uh,

But yeah, so I've started to feel better yesterday and since we're two episodes late, I said, okay, we need to do this. I'm going to jump in the podcast effort and pull it through. And in terms of my professional activities, yeah.

Yeah, I think that in the past few weeks, a lot of companies have reached out to me with recruiting questions. So I think that this is a very healthy sign for the design industry in general and for the market around me in particular, that companies are starting to hire more and more designers and there are open positions all over the place. So I'm trying to recommend people, but also the people are...

happy with their roles because I think it's a good moment in the design industry. I don't know what's happening. Yeah, so I've been doing a lot of recruiting lately. I'm working intensively on launching the UX Academy with my awesome team. We're planning on going live quite soon and this is also taking a lot of my time and the rest, yeah, clubhouse, social media, stuff like that.

So that's pretty much it. Let's not waste more time with the introduction and we can move straight into the juicy topic of design systems. I say that we could maybe talk a bit in general high level about what design systems are, why they're good, when they fail, and then we can dive deeper into our own personal experiences of working with or building design systems. So the first question for today, what are design systems?

I'm not sure if you want to start, I can go first, whatever, which way you prefer, my dear co-host. I think we can identify it in different ways, but long story short, and for me, personal design system is a single source of truth.

for your team and for your stakeholders or whoever is involved in the project or design that you are working on. I think it's more of a system, not necessarily a deliverable. It basically needs to be built in the collaboration with developers, with managers, with your design team. And I think the design system is really best used when you have a pretty sort of a bigger team involved

when you're trying to build a project or build a product. For example, if you are working in a startup, you don't necessarily need to have a built and established design system because you might actually figure out things together if you're sitting in the same room, if a team is like five people and you can talk to them without standing up from the chair, you can literally just

say, hey, how about that? And you can kind of figure out things together on the go. But you do need a design system as soon as your team starts growing and you maybe sit in different rooms, in different chairs, in different, you have different teams involved. And there, it's actually when the more people involved in your project, the more chances for things to be messed up. So if you don't have any design system established, no rules, no sort of rules

Stalina Mersin: style guides or pattern libraries, how we build things together, you can quickly build a Frankenstein design where different people interpret things in different ways and. Stalina Mersin: build up things that don't work together very well and it's just becoming a very big mess really quickly, so I think like design system.

is a very great, again, it's a system, not a deliverable, just to make it super clear. So design system is something very useful as soon as your team starts growing and it's this common source of truth that everybody knows where to find, refer to, and use in order to build products consistently. That's my intake on this. What about you?

I love your intake on this. I actually love the point about the Frankenstein product, which we all see so often, or we've been in companies where, uh,

even with the best intentions, things start, um, tend to end up like that. So getting back to my definition, it's quite similar to yours. It's universal. So basically a design system is just a collection of components that you reuse based on some guidelines or standards. And, uh, yeah, you create them in order to assemble them easily, uh, quickly and, uh, safely without errors. So, um, you've touched a little on, uh,

when it's a good idea to consider having a design system. And I agree that it's also quite related to the size of the team, the size of the company, the size of the product. And I will also link it to complexity, to the product complexity or the portfolio of products

So you probably don't need a design system to build a landing page or a portfolio website, but you will definitely need one if you're a big company that has several products or even just one product that's complex enough.

Quick point when you just said like about landing pages, I thought about that maybe for freelancers, it's important to still have a design system, even if you're a team of one. But if you're constantly building landing pages and, you know, you constantly build them from scratch, what stops you from building the design system that you can reuse for different clients and that would save you a bunch of time? So I think it still could be useful if you're a team of one, but you're kind of working, kind of operating with the same people

with the same components over and over again that could be really useful for you anyway yeah let's move on yeah it's a good point and i think that another point that i wanted to make in terms of when it's useful i think it can also serve as a very good uh solution or aid in uh in solving organizational troubles so design organizational troubles in the sense that maybe things are always uh

end up inconsistent or there are some communication problems, design system also can aid with creating a better collaboration and communication and culture in general. So I think there are a lot of use cases for design systems just to make sure that you need a design system before creating it and don't create it for the sake of creating it.

so another question that I would like to ask you Anfisa still on the practical definition side if you want what are the usual elements that make a design system yeah that's a great question I do think it's it could be also a little bit confusing design system just as I said it's not necessarily a deliverable I

I think in general, main components are, well, you probably need to start from a style guide. I call them tokens, where you would define basic things from which you'll start building up on top of those tokens. So let's say those could be typography styles,

different applications with each other on typography level, maybe colors, maybe even icons, some paddings, maybe, I don't know, grid system and stuff like this. So things that you kind of, it's like fundamental thing based on which you start building up your,

more reusable components. And again, as you have established colors, typography, grid systems, maybe layouts, basic things, you can then start building up the components library. So again, component number one is Trial Guides, the tokens. Based on this, you build the components library. And these are more of a reusable components,

symbols or components in Figma, if we really make it super tactical. So those could be, again, different components that you keep reusing over and over again in different contexts. There could be images, galleries, articles, navigations, buttons, all those things that you would use in, I don't know, web design or your product design.

And then after components library, then it comes to a sort of hat or umbrella under all of them that I usually would call something like rules and connections or the principles. How do we use

things together. When do we use, I don't know, this component? What are the rules? What are the states? Things like taxonomies, foundations, content principles, maybe even UX writing, like maybe some tone of the voice principles. But it's really like all possible combinations of things and how they are moderated and

with each other so that if let's say you have a component, you know that for example, it works in this context, but it doesn't work in this context for this or another reason. So it's more of this umbrella that rules your application on your styles and components, I guess. The basic thing is you always need to start from styles, then you move on to components. And then as you grow and as the product becomes much more complex, you need to start thinking about the guidelines and application rules, I guess.

I loved your answer and I don't have much to add on that. So perhaps before we move on into discussing a bit the pitfalls or what can go bad for design systems, perhaps before that I could add my points on the benefits of having a design system and then we look into what can go wrong because many things can go wrong as with everything in design.

So what are some benefits of having a design system? These are, of course, general. It's very much dependent on your context and on your particular problem, on why you decide to build a design system. So there is a lot of variety to this answer as well. But as a general rule, design systems are great for ensuring consistency across your products or solutions or whatever it is you're building.

They're also increasing the speed at which you can build and iterate on solutions, which is another good thing. And especially if you're a big company, it's going to be a massive improvement in terms of speed once you have a design system. Of course, there's also a higher quality to the outputs because you...

You make sure that there are less errors, less inconsistencies, less anomalies, Frankenstein solutions and so on. So higher quality. And also an important point, which I, from my experience, noticed is probably the most powerful one is that you build a shared vocabulary for the teams.

And so this also creates a common language, a common ground in which everybody kind of starts talking about the same things. And this word means the same for everybody on the team. Uh, but also it forces, if you want, it pushes people into collaborating more, collaborating better because you cannot build a design system without having, just like you said, having everybody involved and, um, uh,

Everybody needs to contribute. Everybody needs to use the design system and then inform the design system with whatever change or other element he has, he, she has implemented. And so, yeah, it's a great tool for encouraging collaboration in teams and companies.

And lastly, I would say that it also makes everything easier to test because you can rapidly prototype and then you can validate or invalidate solutions really quickly. So these are some of the elements that are the main benefits or general benefits of a design system. I guess what you just said is perfectly also aligned with me, but I also say maybe it's having this predictability, having this library established,

makes it so much easier for you to focus on problem solving rather than building visuals over and over again. So again, it's the problem that I had with my social media design system. There was no design system, basically. So if you have this

sort of things figured out, how things work together and all those templates and components established, you really don't focus anymore on visuals and constantly making another layout project, right? You're focusing on what matters most for the design, problem solving, or I guess the point that you're trying to make or visuals that like the message you're trying to communicate. So it really depends on

what you're trying to do, but you don't need to focus on the visuals, right? You focus on what matters for you as a designer. That that would be just my sort of, that's my feeling when I think about design system. That's my main reason why I would build design system to make it so predictable that you don't have to worry about things and how they work together.

really powerful and a great point. Yeah, thanks for making it and indeed I really love it and I'm probably going to share it in the end of the episode when we share our top three insights. So now let's explore a little this what can go bad space. I would love to hear your thoughts on why design systems can fail or what can go wrong when you build on or

the process of approaching interesting because I don't think like I have ever been involved in the projects where design system failed um there were definitely sort of issues on on the tools we were using um

So this one source of truth was not always the best one. For example, in one project we were using Zeppelin and it's not like it's great tool for maybe establishing tokens and some libraries, some components libraries, but it's not the most optimal way. It's very hard to regulate. It would quickly build up the mess and different projects and where things you can find things and stuff like this.

I would say that it all comes back to how do you communicate your system and how easily can people reach to it and find things in place. So it's not necessarily the design system fails. It's more of how do we communicate the design system, personal for me. But I would rather more focus on the part of

What is, I guess, wrong with design systems and what could be the limitations or constraints of design system? Because I think for me, it's what was the sort of a pain point in some cases. So for me, personal design systems could be sometimes limiting. For example, if you want to build something that you don't have a component, but you have this unique case.

And you're in this strange position where you have an idea how to communicate the flow or a point in a very interesting way and not, let's say, trivial, unorthodox way. But it's not a part of your design system. And you're like in the position where, okay, we prioritize consistency. Right?

but it's not working right now. If we pick any element from our design library, it's not going to work. So what do we do? Do we create another exception or do we go for consistency? So this is like a priority that you need to really understand what do you prioritize. And it's not like one size fits all. Sometimes you need to prioritize consistency. Sometimes you need to go for this unorthodox solution. And this is like this pain point I used to have in some places.

But also what is, what's limiting about design systems, it's not just exceptions and communication of this new exception that you keep building up and there is less constant conversation you need to have. Are we allowing this exception? Are we not? And, you know, how do we regulate those new components? But another point or pain point, I guess, is all about like, again, regulation. So, yeah.

What's the way of us moderating the system? Who updates the system? Who has the right to update the system? What are the steps to do this? How we are approving it? How people know about, you know, system being updated, the new rules and applications. So the whole updating process and regulation process is another step.

sort of pain that I didn't personally figure out how to do it best. I think I'm definitely looking forward to hear some experiences from other designers who went through the process and figured it out. So this is for me still like a big question on how to make it more effective for the whole team. But yeah, other than that, I think design system worked pretty well and definitely it's better to have them than not having them. What about your opinion?

Thank you for sharing your thoughts on this. Very valuable points indeed. I'm going to share my two cents on why design systems might fail. You mentioned one of the heaviest points, if you want, or the most important ones, not being socialized enough, if you want, not being communicated and, yeah, evangelized enough in order to increase the adoption. So I think that another point

pattern that I've noticed in companies is that there's this initial effort and push to create a design system and then the design system is finally there and then that's it everybody kind of forgets about a design system I mean they may start using it they're using it but still it's kind of

get messy real soon again because i think one of the main challenges around design systems is to understand that it also needs to be maintained it's not enough that you create it and you do this one-off effort and then your all your problems will magically disappear forever it actually needs continuous work continuous updates just like you said maybe there are some instances which weren't covered or maybe there are some exceptions that need to be made and

that should inform the design system back. And so I think that it's a continuous effort. It shouldn't be viewed as a living organism that's ever evolving. And yeah, people tend to look at it as a one-time project for building the design systems and that from that point on we use it and that's that. When in fact it's totally not.

Another problem would be that many times people don't know why they're creating a design system and this affects the buy-in, the excitement, the adoption of the people on the team. So I think that I've seen teams or companies or people that are just discussing design systems because everybody is discussing them and because, okay, maybe they will solve some problems, but we're not quite sure which.

I think that you need to be clear, just like you shared in your story with the social media, you need to be clear in articulating why you choose a design system as a solution to your problems and which are the problems that you're trying to solve by building a design system. Yeah, so two quick points that I'm going to make on this question and then we'll share some personal stories.

Yeah, I think that another thing that can go wrong is that companies tend to underestimate the amount of effort it takes to build a design system. It kind of feels like, okay, it's a style guide, it's a library, this guy can do it in two weeks, please go ahead and do it. And in fact, it's really a tremendous amount of work because you have to look at all the products, all the discrepancies, all the Frankenstein things

Now I have a new obsession with that. You have to look at everything across the company, see and then understand why it's not working, what we should do for it to work, what are the best solutions or possible solutions that we could choose for each and every component.

So it's massive work. It's massive work and companies underestimate that many times. So I think that not mobilizing enough resources could definitely hurt the success of a design system. And I think that I read somewhere once and it had an impact on me that a design system is in a way a product in itself and it needs its own roadmap and its own people in charge

And another and the last point, and this really is a quick point, is that, yeah, you also need engineering buy in. So I think that people look at design systems like it's a design deliverable or it's a design effort, but it's actually more of an engineering effort because the engineering team needs to build this component in order for them to be reusable and to quickly

build solutions with them. So I think that there's a lot of work that needs to be done in advocating and convincing and getting buy-in and making the engineers see the benefits of building this design system because it's just like I said, it's a big effort. It's not trivial.

I want to add five cents here. When you said we need to buy in, I feel like, well, I had a little bit of experience with there. And like in my previous company, we were building a design system and it was exactly like you described. We build it and it was like pushed down to developers later on. And there were people who were very easy on this point and very kind of open to build what we have suggested. But there were people who were resistant to the design system and, uh,

Had a lot of questions, I guess, and negativity move into it. So I think what I've learned from that experience was that maybe, and I have not experienced it just yet, so I'll probably report on my experience later on, but maybe one way to go about it would be to not just build a design system in your silo, sitting with your team and kind of collaborating on how do you want to build things, but actually involve them early on, like we said, like in any design project.

And maybe even do some collaboration workshop where everybody has a voice and can sort of contribute and explain how they think things could be built more effectively and could work together better and for what reasons they think they could be work together better in this way.

So I think maybe it could be a workshop where everybody have their voice and it could be heard and it could be voted upon if it makes sense for everybody. This way, you don't exclude anybody from the process. And this way, maybe you can ensure that the engineering decision makers are interested in communicating it to their teams, but also explaining the value of it in the more...

influential way, I guess, if we can call it so. But for sure, the point is that we need to have all the people being involved in this process. Otherwise, it's going to be very hard to push it down and see this system being used and blossom and being super helpful and effective for everybody. Especially if you have a big team, it's going to be very hard for you to do. But yeah, we are only about to do that in my company right now. So

and we'll see how it goes and if this workshop could even make sense in general we'll see

Super valuable points on FISA. You already shared some bits of experience, for example, the social media struggle that you had and discovering that you need a design system and working with that team where you built a design system and then just hand it over to developers. And some of them are okay with it, but some of them were kind of like, what is this? Why were we not involved? And maybe they didn't even know that they wanted to be involved from the very beginning. So yeah, extremely important points.

I'm curious to hear if you want to share anything else in terms of what your past experiences or current currently happening experiences with design systems are so some personal stories or takeaways or anything along these lines yeah sure I would say that I was involved in my past in three design systems um

And they were very different. One system was when I was a designer freelancer and building my own design system so I can, as I said, like make it super easy for myself to reuse them in different contexts for different clients. So I built a personal design system, not for collaboration, but again, for more effective work with the clients.

and kind of saving time for future projects. That was the first system I've built. The second system I've built was for a bigger company. It was the company where we had around 100 people and I was working there for one year as a contractor. And we basically were like having an interesting situation because we had three designers and

and we had 100 developers so the ratio developers to designers was crazy not equal at all so we were preceding like in every normal project we were preceding the development effort so we had I think two months in advance to build sort of just establish foundations for design system before developers would pick it up and

that's exactly the project when I said like not every developer was happy at the end. And you can imagine when you have 100 developers and most of them are newcomers, it was a contracting project. So most of the people were coming in a matter of like three months, every single day, there will be new developers. You don't even know their name. You have never seen them, but it's a mess. It was a pure mess. And we still didn't even have like a design tool for that. And at some point we finally got our Zeppelin, but we almost didn't have time to

let's say, find the best practices to how to use it. So we were throwing that this and I think we did our best at what we could do three people, 400 developers and a tool was kind of thrown at us later on, but

As I said, I definitely learned from my mistakes of not having an effective system and an effective tool to communicate it. But then also, if you have new people every day joining, you really need to find a way to communicate your system in an effective way. I think what I've learned from this experience is that you need to have

a really important place. It's not just a Zeppelin that some developers have access to, some not. And just because you don't know that people are joining, they don't have an account, now they cannot access your design system. That was a mess. But also you might want to shoot maybe some videos, some library where you can say,

Here is an onboarding process for any developer. If you want to find this, this, this, this, this, this is where you go. Here's how it works. Here's how you can get your specs and stuff like this. So it needs to be a very effective communication process, especially if you have newcomers every day for your project, maybe build some videos, whatever else that could help you to streamline the communication process because making presentations every day for new developers is not effective at all. And of course,

The design system is not necessarily needs to be pushed down to the team of developers. You need to have stakeholders, representatives from every team, from any silo that you will work with together. And in the perfect case, I would recommend to have those people collaborating with you on building this design system early on.

But to quickly share my story on the third design system, which I just mentioned, and that is the system for my social media.

And, well, it's a long story. I think the social media presence in general could be another topic again, which we can cover somewhere in the future, but I'll try to be super brief here. So, as I said, my main problem, my basic problem for, you know, continuing my journey in social media and content creation is,

Was that, okay, so I've been doing for a very long time. And every year I felt the same struggle. I felt like I'm constantly spending two, three hours, if not four, to build one post that would be seen for three seconds. And the impact of it was just...

I guess in decreasing every single time and I felt like it's just me spending more and more and more time but not having any impact because I am not consistent I'm building I'm basically finding craving time and in any possible moment I don't know find three four hours sometimes is a luxury so you you spend a lot of time you kind of put all your free time into building this post but it's not

And it's not consistent, so it's not like people know that you will post them or it's not predictable when you post, when you have this free moment. And all in all, social media platforms will punish you for not being consistent and not creating posts more frequently. If they are not consistent in your social media,

Your reach is dropping. There are more content creators that are more consistent. Your visibility drops and the impact that you are bringing is just decreasing with the time. So, overly, I realized that simply because I always have to scrub these four, three hours to build one post that would not have enough impact and with every next post it would be less and less and less impactful or reached.

It just became much more frustrating to me to invest my time into it. So with the time, I realized that I tend to not find this free time, to not invest my time in this at all. And it was a sad story because, again, I have ups and downs. There are times when I would build up

pipeline of posts and push it. But then there would be two months when I have zero time and I would not push anything. And it's just like up and down. You're visible, you're not visible, you're visible, not visible. So social media is, it's a little bit of a frustrating game if you don't have free time. And before that, I was a freelancer, so I had more free time. But right now as a full-time person, I

I have very little free time. So I need to, I realized very strongly that I need to build a system that is reusable, that could be picked up by anyone. Let's say if I want to delegate some posts to be built by the person I'm working with, that person can do this, but it still will be me. It's going to be my style. It's going to be my company.

visual communication principles and it's going to be almost like my voice but the time that will be spent on putting together some bits will be spent by somebody else because I don't have this time but it's still going to be consistent so just because all of those frustrating experiences I

I strongly realized that A, I need a better communication visual principle. So I hired a branding designer who helped me a lot to understand who I am. And that was a long process because I did some strategizing. I did the research on who is my audience? What are my communication style principles? How people interpret me, how they see myself? What are my, I guess, attributes of the personality that I want to communicate?

And also what types of content or posts I want to communicate, what I need to be kind of known for. And after that, the social media designer helped me to build the tokens, let's say so, the colors, the typography, the...

icons let's say strokes and different elements that will be reused in posts and after that i picked it up and built this design system just like i said with using those principles so we have fork tokens now i started building the components um different reusable elements and then i've built templates for that and i already knew what kind of posts i will be posting so uh i don't know cover cell principles quotes principles gamification posts storytelling type of posts so i try to build

them all and kind of patternize them so that it could be like a template that the person I'm working with will pick it up and just put their content. And this way, again, right now it's still in the process because I think design system, it's very hard to build it in a predictable way that fits all types of content. But

I'm trying to make it almost plug and play type of system, but we will see with the process because I think like once we start posting this, it will be clear if it's effective or not. But so far I kind of have like this Figma file as a deliverable myself. So I have this kind of Figma file with tokens, with principles, with templates and

The last point I still need to do right now is to communicate this design system and how do we use this to the girl I'm working with that will help me with posting. So that's currently where I am right now with my last design system, the social media design system.

and I'll probably keep you updated on how it works later on. How about your experience? What were your projects in the past and maybe what lessons you've learned from working on them? I've worked on two big design systems in big companies. So companies with over 1,500 employees, I don't know, maybe 10,000 in the bank I worked in and

3000 in my car with my current employer. So huge companies, not so big design teams. So in the bank, uh,

the local team in Romania. We were building a design system for ourselves because the app was also a local product, so it wasn't a global solution. We built it custom locally with our engineering teams and team of designers. So we were not that big of a design team. It was the first time we were exploring building a design system. Design systems

just started to emerge as the new popular trend and you need to have a design system. So everybody was kind of doing all this experimentation trial and error approach and so we weren't very clear about what we're doing and if we're doing it right. But what we set out to do was to create these Confluence pages where we documented every component, all the decisions, the design decisions that we've made

And so everybody on the team kind of got to pick their favorite components to work on. Some people wanted to work on buttons, other wanted to work on controls and so on. So everybody kind of chose their favorite elements to work on.

the takeaway and what we saw happen was that we were moving quite slowly. And I think it was because nobody was the clear owner, just like you mentioned earlier, there was no clear official owner that was driving, pushing the design system. So it was just us trying to encourage each other. Hey, can you do the calendar component this week? Cause we kind of need it for whatever other project

So it was this conversation between us. There was no buying from stakeholders or managers or anybody above us. So we were organizing ourselves. And at the same time, we also needed to deliver on the day-to-day work

projects we were working on. So this was another challenge, prioritizing working for the design system. So if I were to do it again, I would say this is the person in charge of the design system and you're responsible for driving the creation of the design system and monitoring the Confluence pages, what's missing, what needs to be updated, so and so on. And

Yeah, the Confluence pages were complemented with a sketch library that we started using. But it wasn't necessarily a success story. It was more an experimentation story. When I left that company, we were still working on the design system, so I didn't see it finalized. With my current employer, also, there were a lot of...

yeah, inconsistencies across products that needed to be addressed. And this was just one of the problems that called for a design system. Another one was the fact that the design team was very globalized. We had designers in India, designers in New York, designers in Seattle, designers in Europe. So there were, we were on all the time zones possible. So misalignment,

making sure that we're building aligned solutions became quite a challenge. So we decided that we need a design system and we started working in Figma, which is a great tool to build design system because it's super collaborative and you can, everybody can work at the same time on their own, um,

box of responsibilities in the Sigma corner. So I think that it was a great choice for building a design system. In the beginning, we were moving quite slowly for a very long time. And it was for the same reason that I mentioned, there were no clear responsible designers for the design system. Everybody was expected to work on it as a side project, but everybody was also swamped and worked. So when...

our head of design kind of named the people who will be in charge or who need to drive this project, things started to move faster and they felt empowered and they

they felt responsible for the success of this effort. And so things started to move really quickly all of a sudden, and then bam, we kind of had a design system, which I want to say that is never over as a project. So it's not that one day you say, okay, done.

This is done. I'm done with it. Not only that you need to maintain it, but there will always be some open questions around it. So there will always be some things that were not clarified that need to be revisited or solved and so on.

So these were my two experiences with design systems. And before we move into our final points, sharing our favorite takeaways from this conversation, I would like to ask you a more playful quick question.

What are your favorite design systems, if you have any? Yes, for sure. Love this question. In my practice, took a lot of inspiration from atomic design system approach from Brad Frost. I really love this approach because he kind of took a very...

tangible example and sort of association to help you understand the design system. He called it atomic design system because he kind of took inspiration from periodic table where you would have different elements and

Basically, what he suggested to use in the system was using atoms, then molecules and organisms and templates and pages. And I kind of tried to use it in my...

systems I was working on because it's very easy. The atoms are buttons, for example, molecules are buttons and forms, for example, organisms is bigger amount of combinations of elements. And then you have templates, for example, right now for social media, I will be using templates or pages, for example, one source of truth on how our homepage looks currently, for example.

So it's a very easy approach and sort of thinking to pick up. And when you work in this, however, I added there like this token element such as style guides, because I don't think the atomic design system is kind of thinking about tokens and stuff.

what goes before we use Atoms. Another system I really took inspiration from was the Google material system. It's a shared labor library. It's very easy to pick up. It's a very common library. So if you, for example, don't even have design team, you can go to Google material resource and find everything you just need in order to build a consistent and predictable user interface that any user will know how to use.

And they have such a great examples and principles, how to use, how to not use things together. So I think it's definitely a great inspiration for how do you want to document your system. It's very advanced. So not every company needs to build such an advanced documentation, but it's a great sort of inspiration to look for. And two more systems that I kind of liked when I worked on,

when I kind of needed inspiration for my design systems was Atlassian Design System and the Shopify system. I think they called it Polaris. It's definitely interesting to keep looking for them and kind of find inspiration in those. And another book that I would like to plug here was called Design System Handbook. And I think it was published by InVision. It's like an ebook that you can download for free online.

So yeah, it's another great source to maybe look for if you are about to build your design system. What would be your suggestions? I'm going to piggyback on the resource thread and share another resource for everybody who wants to explore different design systems. It's a design system repository that has helped me a lot in discovering

new design systems to look at. And before I name it, I just want to say that this is a very valuable exercise that everybody needs to be doing. So I don't think there's this ultimate design system that has all the answers and you look at it and it's complete and that's it. You don't need to check other design systems. Maybe if I were to choose one, that would be material design indeed. But I would encourage everyone to

go out and explore as many design systems as possible because each and every design system has a different perspective, solves a different need for a different industry with a different flavor. So you will always find something valuable to learn by looking at the public design systems of companies. And for that, I would like to recommend a repository called Adele, like the singer, but it's not named after the singer. So Adele.com.

uxpin.com and it's yeah just like i said a repository of design systems linking to their pages and there you can start your exploration of design systems and choose your favorite for your own um i don't have an absolute favorite i'd say material design is the bible of design systems if you want uh

I also like Adobe Spectrum that was launched, if not last year, I think the year before. IBM's Carbon Design System was the first one I discovered and I was in awe, like, oh my God, these people are so organized. But everybody should go out and explore as many as possible and choose informed. Okay, so we're at the end of another awesome episode. This was a conversation, I think one of my favorites today.

So yeah, I would like to hear your top three insights from this conversation. Yay, I'm gonna go first today.

Okay, so my top three points. I actually did the sticky notes. I'm going to just read from it. Point number one. I think that it's very important that design system is a living document and is updated. So it needs to be a living document that is updated, that it's not once and done because otherwise it's going to be very hard to build one system that fits all purposes. You do need to think not just about the foundations, but how do you want to update this and how do you want to moderate it?

Second point was that system, maybe systems needs to be built in conjunction with different teams, different stakeholders or decision makers, if you will. And it's not, I think, at least in my experience, it's better if it's not pushed down from top to bottom to other people who need to adopt it because people

work in different ways and it's totally normal we are personalities we have different thinking processes and we might prefer different ways to work so we cannot expect if you push something down people will instantly jump on it and adopt it

like that so i do think um conjunction is important when you try to build such a big and sort of massive thing for your company and another one point that i really like uh that was made by you was that you might want to have a ovener like a home ovener for the design system

project owner for design system who maintains the progress, the updates, how living is this document, maybe defines the process of updating it, the roles who have a voice and rights to update it so things will not get messed up. Because if you allow, you know, open the stores,

for anybody to bring something in. And if somebody just goes inside and changes something, but other people don't know about it, there is a huge chance that you will mess up things and people start building up not a very well communicated system. So I think that moderation is very important. And it's a part of this maintenance process that needs to be established as early as possible.

And a small other point that I just liked that you literally just did was that every design system that you find online right now has its own flavor. And I think it's very interesting that you can look for how this particular industry adopted the design system for this industry, like Shopify, right? For e-commerce. It's a great example. And it's specific industry, specific niche. And I'm sure you can find an interesting elements there that you don't find in other industries.

industry systems. So it's definitely a great exercise to look for those nuances and how can those nuances be really different in different contexts. Okay, that's it from my side. What about you? My first one would be that one that you mentioned and that of the fact that the design system will enable you to focus on problem solving instead of building visuals or solutions or building, yeah,

actual UI decisions. So it's a great way to make sure that you're looking at the important part of the design process and not that also important, but not so important parts. Okay. Another one is that

Design systems will be successful only if you communicate them, socialize them, get everybody on board with them, make sure they're easy to access, they're public, everybody can use them, and so on. So socializing the design system continuously is a key point in its success.

And the last point is that I would say to anyone looking to build a design system, don't underestimate the amount of effort it takes.

It can be tremendous work, depending on the complexity of your product and the size of your company. So make sure you set aside enough time, you mobilize enough resources and treat it as a very serious project in itself. And on that note,

I would like to thank everybody who listened to this episode. Thank you, Anfisa, for another awesome conversation on our Honest UX Talks thread. And yeah, if you have some final closing remarks before we say goodbye.

No, I just wanted to say again, also, thank you so much for all your great points. I really love your experience and your points. I do hope it's going to be helpful or useful for our listeners. If you want us to talk about more specific topics, maybe niche topics, just go ahead and find us online in iHeartRadio.

in our social media we use instagram and you can find us as honest ux talks and just dm us we will try to cover your topic or your specific question request as soon as possible and that's it from my side thank you so much for listening and i hope to see we hope to see you in the next episode goodbye everyone bye