Design Systems at a Small Scale | Design Aloud 🎧

In this episode, we have a conversation with Sándor Zelenka and Benedek Göbölös as they share their experiences developing a design system for UXfolio. UXfolio is an online portfolio editor catering to UX/UI and product designers. Listen in as our co-host and design system expert, Gabor Szabó, helps unravel the story behind building a system for a small, dynamic team.

"Maintaining the design system is a continous job for all designers in a samll team"

Design Aloud Podcast | Season 03 Episode 06

Listen and follow Design Aloud:
Spotify  | Apple Podcasts | Google podcasts

Episode details

🔍What can the listeners learn?

1. Listeners will gain insights into the challenges faced by small teams in creating design systems and learn strategies for overcoming them. From Sanyi's initial vision to Bene's iterative enhancements, discover how they optimized their workflow for efficiency and consistency.
2. The challenges they faced and future plans for the design system

Transcript

Karthik: [00:00:00] Hello, everyone. Welcome to Design Aloud. This is episode six. And today, we are joined by Gabor, Sanyi, and Bene. Gabor is a co-host in this episode. And introducing our guests now is Sanyi and Bene, who work for UX Folio. So hello, guys.

Could you please introduce yourself a bit?

Bene: Hey guys, my name is Bene. I work for UX Folio as a product designer.

Sanyi: Yeah I'm Sanyi, Sandor. I will be referred as Sanyi. And yeah, I also work for UX Folio. I'm the product lead at the moment. Before that, I was a product designer on a different product called Copyfolio, which is pretty similar.

And we're also going to discuss design systems for Copyfolio as well.

Gabor: My name is Gábor. I'm a product designer at UX Studio and [00:01:00] specialized in design systems right now. So that's why I am here as well.

Karthik: Awesome. Thank you. So folks, as you might have guessed, we're going to talk about design systems today.

But before that, I'd like to know a bit more about how you got yourselves working on UX Folio. How did this journey happen?

Sanyi: So I started on Copyfolio, as I mentioned, it was a new product. And I'm mentioning Copyfolio because the whole design system topic that we're talking about today came from Copyfolio.

It all started with building a design system there. How I got there actually was basically a ton of products and projects before that. I worked for UX studio, and I built design systems there. And basically, our CEO approached me and asked me to start working on a product.

And it sounded interesting because it involved [00:02:00] building a design system from nothing. And at least at that point, it seemed like it's going to be bigger than anything that I've worked on previously. So, obviously, I said yes immediately. And that's how I started on Copyfolio.

And after a while I moved on to UX folio. As a product lead.

Bene: Yeah. For me, it's roughly the same. I joined UX studio, the company that has all the Folio products. For the listeners, there are three Folio products and one product called Ranking Raccoon.

I got the chance to do design on Archifolio, the third Folio product that we haven't discussed yet. I was working there for about two years. Yeah, roughly two years. And then, there was a shift in teams, and I got the chance to work on UX Folio as well, which is the biggest product of the branch.

So it was like a really cool experience for [00:03:00] me. I was working on design systems in the service team as well, like the agency part of the UX team. I had two or three projects where I had design systems involved, and then on the Archifolio, of course. With the product, especially with like a small team, you have to have a systemized way of designing features and updating the design system.

So, essentially, I had a lot of experience, which I could transfer to UX folio.

Karthik: Yeah, it seems like a very natural and passionate transition towards the product side. So, for the listeners out there: at UX studio, we have two verticals; let's say one is the service side, and the other is the product side.

On the service side, we have a lot of client work happening. And on the product side, we build our own products. In a nutshell, Bene and Shanyi moved from the service team to the product team. And we have Gabor who is specialized in design systems with the [00:04:00] service team. So I'll let him take over now.

Gabor: Let's start with the basic question. What do you think a design system is?

Sanyi: I heard the same question, I believe, like four years ago or something like that. And it was a pretty interesting question. Nowadays, at least like again, four years past, I don't think people think that design systems are all about components and UI kits anymore. But I think it's important to basically highlight that design systems should be about the team, I believe, at least.

And I see them as tools basically to synchronize work and create consistency. So how I would approach it is that a design system is a tool [00:05:00] that basically helps us design.

Bene: Yeah. And what you said about components and design libraries and stuff like that. It's more than that. So what exactly is it? Aside from like the component kit, all of the rule sets that are in the design. So from where the primary save button should be, where the secondary should be, how do modals open, or what is the relationship between naming conventions inside of the design system. Or how is it with the development side.

And I think the most important thing you have mentioned is synchronization. If we didn't have a design system on Folio, and these are quite small teams, so we are not as big as, you know, 15 or 20-person design teams. But we would still be able to sync design with development and have all the naming or styling, all the rule sets and the components [00:06:00] and the colors and the fonts, you know. These styles just really help us move much quicker because if they weren't there, we would need to reinvent ourselves constantly and just, you know, like figure out the systems over and over again with a feature-by-feature basis, which is just too much time.

So that's why design systems help us. Build products better and faster.

Gabor: What is the background of this product? What is UX Folio, and what are the other products that are related to it?

Sanyi: We have three products at the moment, at least in the website-building space.

We have UX folio, Copyfolio, and Archfolio. Basically, these are all websites slash portfolio builders. They are pretty niche in terms of target audience. So UX folio specializes in portfolios for UX designers, UX researchers, basically UX people in the [00:07:00] industry. Copyfolio is kind of the same for copywriters and marketers, and Archifolio is again the same, but this time around for architects and people working in that field.

And they're pretty similar to each other. So the premise is the same. You start with a template and where we differ from giants like Squarespace, is that these are not generalized tools. We focus on the specific target audiences, and we figure out what makes a portfolio good in that space.

So we talk to recruiters, industry professionals, and we see what makes a portfolio good. We help people build portfolios there. So for example, if you fire up UXfolio or Archifolio, whatever, basically what you will see is that we help you write the copy, what's going to be important for recruiters, We help you design in a way where it will perform well I mean the portfolio.

So basically, these are the products that we're [00:08:00] talking about.  

Gabor: And all of these products have the same design system, or are they separate?

Sanyi:  Actually, there's a pretty good meme for this that I can show the listeners. The answer is yes, but actually no. So basically, that's why I mentioned earlier Copyfolio - it all started out with Copyfolio. So Copyfolio had a design system in the beginning. I was really basically keen on building this design system. We named it Kite. I don't know when. Don't ask me why. That was the first word that came to us. I think we named it after the component logo or icon that Figma has. And if you look at it, it kind of resembles a kite. So that's why it's called kite.

And we started that way. And when our CEO wanted to start Archifolio. We basically started using Kite on Archifolio as well. But I can tell you more about that period. And after we [00:09:00] used Kite on Copifolio and Archifolio, we started building something similar on UXfolio, which ran without a proper design system until that point, at least. And we started working on it pretty heavily in the past few months. So we're basically adapting Kite to UXfolio and that's also a big challenge.

Bene: Yeah. Sanyi and I have different point of views for Kite, because Sanyi was the one who established the whole thing. So, you know, just setting up all of the pages, all of the systems that I essentially had to just maintain.

But then the maintenance is something different. I'm sure we will talk about what the difference is between these two. But from my point of view on Archifolio, maintenance was the key just to synchronize with multiple designers because how our teams are set up is mostly, we are designing a product, like one designer on one [00:10:00] product.

So, the design system's purpose is roughly synchronizing between development and design. But when Archifolio became a thing, and I started working on Archifolio, and then Sanyi was still working on Copifolio as a product designer, like he mentioned, we had to start synchronizing the two products between designers.

And like mentioned before, since these products had different target audiences, they might have had different features as well, but the engine was the same. So, most of the features that we designed and the guys developed at the development side, both of the products could benefit from each feature because both of them were basically released there.

But the challenge started to arise, when these two products started differing because of the target audience. Because we were making products that were niche. And that part was a bit challenging, but I [00:11:00] think we can talk about that when we talk about maintaining the design system and, you know, just going deeper to it.

So yeah, it was like a really interesting journey. And Yeah in terms of the UX folio design system, it was like a continuous effort when I joined UX folio, I helped out and now the design system is kind of finished. Of course, it still needs to have all the updates that it doesn't have currently, but we are on the right track.

So yeah, building and maintaining are completely different things.

Sanyi: I just wanted to join in on that for a second. I think that what you just said kind of explains a question that product managers and managers always ask. Or at least I see them in articles, these questions like, should we start with getting a design system ready when we're starting a new project or a new product?

And I think this kind of answers it because Copyfolio [00:12:00] started with a design system. I personally spent a lot of time figuring out the hierarchy and how it should work. We can talk about it in a second. And since we had that, the whole development process started with this common understanding of what we're talking about, how components should work, and how they're built up, and whenever it came to the actual development part, we understood each other.

So development went, really smoothly. Now, the challenge on UX folio is that since we did not have a design system set up, at least not in this way, the problem is that we're trying to fix this after the fact. So we're going back and trying to figure out certain components, how they should work because they're already built in code and we're building it in design.

After the fact. So this is a completely different challenge. And I think at least from the managerial point of view, it adds time. It adds a lot of time. So I would say personally at [00:13:00] least, it's a good investment to start with a design system already. And you don't have to start from nothing because nowadays there are really good UI kits already out there, both on Figma and development side.

Or radix xxx, there's like a lot of stuff out there, which you can use for the initial components, but the components, the UI kit is not the design system. You will have to figure out how you put together these components because there will be specific components for your specific product. There will be lists, sure.

There will be windows. But there will be other features that won't be covered by these UI kits. And if you have this system in place by the time you get there, it's going to save you a lot of time.  

Gabor: Let's go back a little bit to the time when you started working on the design system itself. What decisions did you make, and what challenges came up during this process? [00:14:00]

Sanyi: It was a long time ago, but I remember the biggest challenge was that we barely had time. So basically what I started doing at that time is I just started copying stuff that I could, at least for the UI kit, because that sped up the process.

And where I spend most of my time was to figure out the hierarchy, like how it should look like. I realized that we don't have a lot of time and we're Going to use this design system for other products as well. So I wanted to come up with a hierarchy, like a structure at least for the component kit. A structure that is familiar but that's not convoluted and overly complex.

So I did not ditch the good old atomic model completely, but I figured the best way to structure this would be to use only [00:15:00] two layers instead of, you know, those really scary trees that you work with in Figma in big design systems. So I figured there will be only two layers and those will be basically based on logic. So they were not based on.. how to put it nicely..., like the structure, I guess, complexity, complexity levels. Like atoms, molecules and then organisms and stuff like that, but they were based on functionality.

So if you open up Kite at the moment, how it basically looks like is that you have big families like inputs and buttons on the overlays, and these contain elements from each other. So there's no clear structural hierarchy or complex hierarchy. They're basically based on functionality.

It's really hard to describe it, but basically, I did this. So there's no actual like three systems [00:16:00] that you have to go through when you're adding components on, or when you're using assets from the design system.

And another aspect that was really important was properly naming things and and tagging the components because this way, whenever you're using the asset panel, for example, in Figma, you can find stuff easily. And I spent most of my time there to put this logic together.

And I think I can pass the mic to Bene because he was the one who actually got on boarded to this design system. So his point of view will be obviously different from mine. He already got something at least, it was still a baby, but he already got like a system to start with.

Bene: Yeah so I felt a bit confused at the beginning, but then when you start using the design system, of course, in hindsight from two years, of course I got used to the whole thing.

But I wanted to give kudos to Sanyi just because of how he set this up.[00:17:00] The atomic system is really good when you are making a generic system or really, really, really big one for multiple teams. Because you know, like at the end of the day you can divide any type of component into complexity because you can just look at it.

You see that, yeah, this is something that you click once, and it does one thing. That's an atom, let's say. And then, if something is a bit more complex, that's a molecule. If something is like a page or a section, that can be an organism. But here we were just focusing on one type of example, portfolio designers. So we could really narrow down these logical namings to buttons, inputs, panels, and overlays because when in the products' context, I am thinking about overlays, I already know what I'm talking about because I have the contextual logic of the whole product.

So when it [00:18:00] comes to making a design system from scratch, when you don't even have components, you can just start from atomic because that's a really good tool and a starting point. But as you start growing your design system and making it more contextual to your actual product, that's when you can try to make things simpler and ditch vaguer naming schemes into something that's more product-oriented.

And then what I wanted to say as well is that if you have a product that has a UI library, but doesn't really have a systemized thinking of it, it is still really good to start with atomic levels because at least you have some structure when it comes to your components. It doesn't really have to work out of the box like what Sanyi did.

Indeed, we had the experience from UX folio, our first product, which informed the design of Copyfolio, our second product. So [00:19:00] Sanyi could have the foundation as to what Copyfolio needs to be, because these products are not just similar in terms of what they want to achieve. But they are similar in usability and UX and just how we research things.

Because it's inside the company, we could share these over time with each other. Knowledge sharing. So yeah basically that's it. It was really easy to work with, and really easy because it's contextual.

And you said naming the layers, naming the components themselves. That's something that with big design systems, it's really vague, but for us, because we have some sort of logic to our new features that it has to be not just useful, but engaging as well. Sometimes you are making new components, which are essentially, you know, like buttons, essentially list items or cards. So we need to have like a naming system that handles multiple [00:20:00] types of these components. inside one basically family of components.

Let's say list items. You have list items for picking colors, but the list item for picking fonts is different. List item for I don't know, like handling menu points or toolbars or something like that. They are all different looking, but they have the same naming scheme, but different enough that you can just search them really quickly on like other files.  

Karthik: A quick follow-up on that. Maybe it'll help the listeners a bit. Could you give us a small example?

Like you mentioned, picking fonts versus picking colors. How do you name that? And what is the general search process of adding that asset.

Bene: So let's say instead of molecules we use this term called panels. Panels are basically cards or headings or these bigger elements that don't serve necessarily an [00:21:00] interactive function. And they are not overlays because they don't overlay on the product, like a modal or like a pop-up or like a tool tip. So for there, we have these really vague terms like menu items and list items, because when you are maintaining the design system, it's easier to go with these bigger family names.

So when it comes to a component, like a custom font list item, how we name it is list item slash custom fonts. And then, because we know that I am looking for a custom font, I can only just write in custom font into the assets panel, and then I can see. But when I am trying to maintain the design system I don't have to go and then put custom fonts as their own family because they are already list items.

So I can get the best of both worlds, basically. So you have the list items, which is easier to [00:22:00] maintain because I know what the list item is because of these vaguer concepts. But when I am searching for these, I don't have to go through tens of list items because there are so many in the product. I can just search for custom font or advanced font or something like that. And then it just pops up. So really easy to search.

Sanyi: Another example that I could mention here how it's different a little bit from atomic is that you have elements on the same hierarchical level within the same family. So what I'm talking about: if you think about a tooltip for a button is really small. It's usually like a frame, and there's some text in it, maybe like an arrow or something like that.

But that's a tooltip, and it is on the same hierarchical level as a window. Because both of them, at least in our system, overlay other elements in the design of the product. So that's why we call them [00:23:00] overlays. So whatever is basically over other stuff in the product, it's an overlay. So this way, when you're adding new components to the design system, say I'm adding a button that is a button essentially, but in the end it gets basically wrapped in a component that's over other elements. That will go into overlays.

And this way you always know that whatever you're adding, if it's overlaying other elements, it's going to be an overlay and hierarchically. I think at least how I remember they're on the same level. So if you go to our design system, there's overlay slash (that's the big family), and under it, there are windows and there are tooltips because they're both on the same level.

They're both serving the same function. They're overlaying other elements. And this just goes back to what Bene has said about searching and finding stuff. So if you're looking for something and you already know what you're looking for, you're looking for a tool tip. You [00:24:00] can enter the tooltip in the asset panel and just use it.

But if you're in the creative phase, which happened to me a lot of times, and I don't know what I'm looking for, I don't know what kind of stuff I want to use, but I already know that it's going to be over other items, I just enter overlay, and then I look for stuff that I could use. And there are many things in the overlay family.

For example, there are sidebars, there are windows, there are popovers, tooltips, formatting, toolbars, whatever. And I can use this in my creative phase. So I wanted to highlight this is why I think it's important, or interesting at least, that we use the design system in our creative phase already. So it's incorporated.

Karthik: I like the idea of using it in a very functional way like you mentioned, I think it helps most of the time even I end up going back to the main file of the design system and looking [00:25:00] for, especially in the creative phase, looking for what I want to use that resembles to what I want to design and just closest to it and then modify it.

But in this case, it's easier that it's an overlay and I can just click on overlay and use it.

Gabor: How does this work for newcomers

Sanyi:  It was interesting because before Bene came, I was really nervous about this, if people will understand it. And actually one of the UX folio designers back then, Luca, took a look at it. She was a senior designer back then. And I think I just moved from junior to medior or something like that. And I was really nervous about what she would say.

She tried it for like two days or something, and she said that it was pretty easy to use. First, as Bene mentioned, it was a little bit confusing how it's kind of atomic, but not really. But then, when she started actually using it, she mentioned how it was really logical. [00:26:00]

But for this question, I think Bene is the proper person to answer.

Bene: Yeah, so it's really easy when there's a designer next to you. And Yeah. So, this episode of the podcast is about design systems on a small scale. So we can only talk about, you know, small teams.

That's why this works because this is a really specific design system for a specific product, for specific size of teams.

About my onboarding: so Sanyi walked me through the whole thing. And of course, like design systems that are really big. Even though we are small teams with like a fairly new product, these design systems are large nonetheless. You will still have, you know, like phases that you might need to search for certain components for a little bit more time here. Maybe at first it's a little bit more confusing because it's not like complexity based.

You need to know the product itself to get [00:27:00] around. But then if you are designing for a product and not just looking through it as a Figma file, let's say. Say like base or the, I don't know, like the IBM design systems. Those are, those are more understandable for the first timers, but for us, it's really like much faster to iterate and just maintain it, maintain the design system because we know the product as well.

So yeah, I guess that's an answer to the question. And then after me, there were other people who got onboarded to the design system and they had roughly a similar customer journey or user journey at the beginning. It's just a bit different, but it doesn't mean that it's not more efficient on the long term.

Sanyi: And I think with standards, you can onboard pretty much anyone to it, like designers or developers. The main key thing [00:28:00] here is that you need to basically prepare the person who's going to use it, whether if it's a designer or a developer, you just show this whole thing to them.

But I think what helps is to actually look at the design, which is already ready, like a screen, which is put together, and then you can break it down how the components are structured. And this helps a lot. And I would also add that It's really important to talk about the design system itself openly, not just with designers, but with developers as well.

So you can constantly evolve it like rename classes or restructure stuff. If you think it's illogical there. It might be illogical for other people as well, and you don't have to stick to that convention just because that's how it is. You constantly have to challenge that. And this will go to the maintenance part of a design system, but I still wanted to highlight that it's something worth doing.

Because if you don't do that, you will basically stuck with a design [00:29:00] system that's outdated, really hard to use. And at least what I believe we did right is that we constantly challenged it. So we moved stuff around, we renamed stuff both with designers and developers. So that helped a lot.

Karthik: Before we go to the maintenance part, one thing that we could all probably see as an improvement here is when we are onboarding, maybe it's a good idea to have some sort of a Figma playground style onboarding where, like you said, you can dissect a screen or help them build a screen through components.

I think that's also a really hands-on idea for getting onboarded to a design system.

Bene: Yeah, for sure. And, If I imagine correctly when you are getting on board, you have like a starter task, right? Which is like smaller in impact, smaller in scale, smaller in [00:30:00] complexity or, easier in complexity. So it's easier to start learning the design system because you will work with it for the rest of your time here.

So that's why these, you know, hands-on approaches are really good because it's one thing that someone tells you about the system that you don't even understand, and it's another thing to actually try it with a relatively safe environment. Of course, it's not like a playground it's an actual feature. But it's a really good feature to ease yourself into the whole thing of working here, which we really want to strive for and just maintain, you know, like the whole thing, not, not just in terms of the design system, but yeah, this is the part of the talk that we are talking about design system.

So this is relevant for now. But the whole onboarding should be really seamless and based on doing stuff, not being told stuff.

Sanyi: Exactly. And I would also add that what I mentioned previously is really helpful when you're learning a new design [00:31:00] system. About the creative phase that I mentioned.

So if you use the design system in your creative phase, then you can do a lot of stuff with it. So first of all, let's say you need to put a feature together. You don't know what to use basically. So you look at the design system, what you have already and say you realize there's something that you can already use. That's great.

But if you realize that there's nothing like it, then you can start with components that already exist and modify them in a way where it will basically retain the logic of the design system because you're using stuff from previous components. You're detaching it, you're modifying it a little bit, and then you're putting it back to the design system, but it already has that logic, that structure, so that way, getting up to speed and learning how to add stuff to the design system and how to modify it. That helps a lot.

And I think that comes in in the creative phase when you're thinking about stuff and you're not 100 percent ready with your [00:32:00] design and just trying to figure out how to put stuff together. And I think there were a lot of instances. At least in my case where I realized that I try to use a component and I realized that, Hey, this won't work here.

And then basically the gears start turning in my head. I'm starting to think about: should I modify the component that we already have? Because it's just not suitable for this task. Or should I create another one? And that way, you're constantly challenging the design system, and you're in it. You're not just using it. You're actually in it.

Bene: Yeah. And that leads to iterating on the design system as well. So the good thing about smaller teams is that it's easier to maintain systems like these because it's not maintained by a team who don't design features, or it's not like a larger organization when different teams who don't even talk to each other need to work with the same design system.

Because, you know, at that point, no one really can update it other than [00:33:00] the people responsible for updating it. So here, because we were just so few designers working on this design system, it was much easier to communicate these changes with each other, and it was easier to sync our ideas up.

So, for example, when Sanyi said that, yeah, I have this feature, I can use this component, but it won't be, you know, like a hundred percent good. What if I just changed the component itself? Because, you know, those can happen. Of course, it would change the components all around the product. But since we have like a small enough team that we can discuss these, it was easier to iterate on these.

And it's much faster to redesign stuff. or just recolor stuff because the communication doesn't really get lost in translation between these big teams that certain companies have. So yeah, again, small scale really shines through this time as well in terms of iterating.

Should we start talking about [00:34:00] iterating? Or I think we already started.

Karthik: I have a follow up to that. So two questions: one is how does this fit into your regular sprint cycle when you get new requests? Modifying design system - is it part of the sprint cycle? And two, what is the role of a developer in it?

Bene: I think yes, it is part of the sprint.

Let's say I'm designing a feature. And the reason I try to update components inside the design system is because of a new feature. So yeah, it is part of that.

And, your second question is really a good one. Specifically because we can sync ourselves up with Sanyi, or I can sync up with Copyfolio's current designer, Janka, but it's harder on the dev side. But because these updates [00:35:00] are more often than not linked to the feature itself, then it becomes part of the feature design phase, the sprint.

So nothing really gets left behind and there doesn't need to be time, you know, like specifically for maintaining the design system because feature by feature, we are doing these as well. And this doesn't really, you know, like exclude options or like exclude times where we actually. just maintaining the design system, but it's like really a good idea to just bundle them inside like a project or like a feature design phase.

Sanyi: About the role of a developer. I think it's really interesting, both from management and design perspectives. Basically, I realized that it's really important that this whole mindset, the design system itself applies to the team and not just the design and the designers.

So to be able to do what [00:36:00] Bene has said the design system needs, to have that exist on the code level, and this is really important because if you don't really have the design system on the code level, then there's going to be this slight misalignment where you need to figure out how to translate a design to code.

But if it already exists on the code level, then you're talking about the same thing. So, in our teams, at least thanks to the small scale that Bene mentioned earlier, when one of the designers say that I want to put like an overlay here or stuff like that the developer automatically knows what an overlay is.

Same with, for example, popovers. We know what we use popovers for, what they are, but this is really important because the developer already knows what they are. That this component exist, how it should behave. And this, I think also saves a lot of communication time, documentation time, where they just know how it should work and you need to put like active work into that.

[00:37:00] So they also learn the design system and you don't have these slight misalignments within development. And I also wanted to add that I think naming conventions are really important here. Because if you name your stuff properly when you're talking about a certain component or element on the UI, They, the developers will automatically know what you're talking about.

And this is just like one fine example where the development's role is really important in this. And I think it needs to be pushed from both sides. So a design system should be, I think at least a result of a mutual work between development and design together. So it works at least so well.

Bene: But so when we discussed that, yeah, I just update the component and that's it.

It's like a really big task outside of the feature design itself. So when we make these decisions, we [00:38:00] we try to include this in the timeframe, in the roadmap of each feature. So it's not like just the. general feature design itself, but it's the feature design and maintaining and you know, upgrading the design system.

So this way viewers could think that features take more time. And yeah, they do. But in terms of like a really complicated product, like a website builder, we need to be really cautious when updating these. So we cannot really iterate that fast. We need to move a bit slower, but more thoroughly.

When it comes to each iteration and yeah, because Copyfolio and Archifolio are working on a much newer code base, iterating development-wise doesn't take that much time because we could learn from the experiences that we had on UXfolio, again, the first product so we can iterate quite fast, even though we have this quality control working basically 24 7.[00:39:00]

So yeah, we don't have hackathons for that. We don't have you know, like every two months we just look at the design system and try to maintain it. It's like a continuous job from all designers which in a small team, You have to do this basically to maintain your to maintain your product.

Karthik: Yeah, I guess it's good for scalability and long term maintenance.

Bene: Oh yeah. Yeah. Like if we didn't do these there would be really big, you know, like designing consistencies. Or bugs or glitches, or just, you know, like if something is not named correctly, or if there's a button that looks like one button, but it's actually developed or used in design multiple types of ways with multiple types of code, multiple types of logic, like that in and of itself is a ticket.

And we don't really have those at least not that many on Copy and Archi because we are, you know, like consciously updating them as they go by. Which in hindsight, I feel like it's a good decision. [00:40:00]

Sanyi: Yeah. But I wanted to join in about scalability and, and, and maintenance, what you mentioned, because I feel like they're basically the biggest challenge of this whole system lies.

is is the future. Like I think we built something that's on pretty solid foundations, but I would be really interested to see like multiple designers and by multiple, I mean, six, 10, eight, 10, 20 people working on the same design system, because that will be a completely different challenge to keep this basically so cohesive and So well documented and so well understood within the teams and yeah, not just designers, but also developers.

So I think scalability is going to be a pretty big question in the future for both of these design systems. I feel like UX folio, UX folios design system. Has basically a head start in this because we're in a [00:41:00] phase where we already have multiple designers working on the product. So we can figure out as we go like live how we should like build this thing.

What rituals and basically practices we should build around it. For example, the thing that Bene mentioned that this is done constantly and not just, I don't know sometimes, but like constantly there are design reviews where we go into how components are built and how they should be put into the design system.

But this, as I mentioned, might get convoluted with multiple designers. So you can't do design reviews with 20 people. You have to find a way to solve this. And I think this is where we're basically falling out of the original scope small scale, small scale design systems, but everything rose. And at some point we will have to deal with this.

Yeah.

Gabor: And now we mentioned the future. Do you have any plans for the future to, [00:42:00] to add to the design system or, or something new on the way?

Bene: When I think about potential new stuff coming to the design system, aside from features and new components, because you know, like we have to maintain it is to graduate it from just Figma.

Yeah. We didn't mention, it's not like Not like a website which has the design and the code side by side. And it's you know, like not super high quality or, or like high complexity because of the small scale, we didn't really have to do that. But as especially UX folio grows, like we are a team of nine or 10, but let's say.

in the future, it will be like a team of 25, you know, with like eight devs and six designers or something like that. There needs to be a way of just having this synchronization between design and development much stronger. And I feel like a lot of products and a lot of yeah, like web based alternatives, not just Figma [00:43:00] are like a really good like a really good option to grow.

This is not like in the future, like a thing that I technically, like essentially am planning to do, but if we grow enough I think it's a possibility.

Karthik: I just have one last question. Can you give let's say top three learnings for our listeners on how to start a design system from based on your learnings?

Bene: Oh, okay. They want to start or two each.

Sanyi: I say I start, then I hand it over to Ben, because Ben is building one right now. And I think it's really interesting, at least from my point of view. One of the lessons is that you have to push for it. So whenever management comes to you and challenges it, why do you spend so much time on it?

What you should do? is you basically push back and tell them that you're going to need this because it's always worse to do it from the other end, do it [00:44:00] postponed then do it. Because that way, when you're doing it up front, you have the chance to basically modify things. And especially because usually design comes before the actual development part.

So if something comes up, you can still modify it before it gets developed. And you can set up the proper systems between design and development to make this work in the long run. So I think that's one lesson. The other lesson at least that I can give from my end is that you need really good documentation.

So a lot of times this is kind of like a confession from my end, but a lot of times I was like, Yeah, I'm not going to document this because I'm the only designer on copyfolio. Probably I will be for at least 10 years. Like a year or something like for some time. So I don't really need to put the proper documentation in there and our developer already knows how it works here.

He has seen the prototype and he also attended the usability test that we did. So basically he knows how it [00:45:00] works. And then two year, two years go by and another designer takes over or not even that is just two years. And then you have to do something with that component and you're like, Oh, what should it look like?

Like how should it exactly work? And it's not necessarily just the design it when it comes to the mechanics and the logic, how it should work and what it should do. where it should lead, what it should open and stuff like that. If you don't put in the proper documentation, yeah, there's going to be problems.

So when you feel like you can spare some time and cheat off a few sentences or just a few words, don't do it. Just do the documentation. You're going to regret it later.

Bene: Yeah. And starting the first lesson with basically just an addition to, Both of Sanyi's points is that you should start documenting and then just the design system as soon as possible.

And then it's really, really, really good that you [00:46:00] said that you have to push for it because sometimes, not sometimes, like most often, of course I think our listeners will agree that design systems don't really like higher ups don't really consider design systems as a ticket itself. It's like an addition that the, that the designer just does.

In there, I don't know, like free time. So if there's a pushback, then you need to push forward with the design system, because especially if it happens, but later on in the project, it's really, really hard to systemize things that weren't systemized before. So you should avoid doing everything later. So do them now, because if you do it now, then it's easier to iterate than just setting up the whole thing in hindsight.

And for the second is that you shouldn't, like, if you have a strong foundation. You shouldn't worry about making the whole thing perfect because at a certain point, you achieve [00:47:00] your your purpose when it comes to just the product looking good and looking like it's designed and developed the same way because, you know, like most times if the design system is really bad, of course, like the development will look nothing like the design because it's really hard to work from them.

But at a certain point, you can just, you can just. you know, do the features instead of just making sure everything is pitch perfect because at a certain point it doesn't matter. So, yeah you need to work on design systems on for, you know, like, Until a certain time. Yeah.

Sanyi: I also wanted to go back to that because that resonated like so well with me.

When I was working on the design system, I always felt like that, I need to do this. I, maybe I have to cover that edge case because what if we come back to that and there's like no documentation, no edge cases for that. And yeah, you have to cover edge but you have to find [00:48:00] at least within yourself a fine line.

Where you just say that this is the point where I go and this is the point where I won't go. And I won't go over that point because one of the problems that I had when I started this design system is that I had this word like design system in my mind. I was like, I'm going to be judged for this.

Like others will be working from this design system. So I have to put it together so well. And, and I have to document so many things and you don't, you don't. So I have a really simple example, for example. I have a really simple example input fields. So I started with a really simple input field and I spent almost a day figuring out how stuff should work like within that input field.

And I don't want to go into too much detail here, but I spent so much time on figuring out certain parts, like how the error should work. [00:49:00] What if it's on mobile, stuff like that. And then it turns out our editor is not supported on mobile. So I spent a lot of time figuring this stuff out and it's not even in the product after, I don't know, like three and a half years.

So it's good that it's there. I'm still proud of it, that I thought of that edge case and I worked around with it. But I spend basically useless time on it because we're not using it. So one thing I just wanted to go back to is this, that you have to find this line, you have to go the extra mile, but then you have to find a point where you put it down and you say, this is functional enough.

We can work with this.

Bene: Yeah, and especially, again, in small teams like small teams and teams with really few designers have this hardship where designers have to do a lot more things. Not just design systems, not just feature design, not just research that you have to move on to the second task.

And yeah, it's just a matter of balance. It's just a [00:50:00] matter of like a fine balancing act between your responsibilities. So yeah, design systems are really helpful, but they are not the main purpose of the product because you're not building a design system. You're making the product. So yeah.

Karthik: That's it.

Thank you. So let's end on that philosophical note. If Buddha was a designer Gabor, do you have to add anything? All right. Thank you. Thank you, folks. Thank you for joining. Thank you, Shawnee, Bene, Gabor.

Bene: Yeah. Thank you so much for inviting

Sanyi: us guys. Yeah. It was great talking about this stuff. I always get like so passionate about this.

Yes.

Karthik: Thank you very much. Let's hope our listeners take some insights as well. So yeah.

Bene: Enjoy. Yeah. Take care guys.

Sanyi: Take care.

.

Want to learn more?

Listen to other episodes of Desing Aloud on Spotify or Apple Podcasts. If you want to learn more about UX design, UX research, and our experiences working on projects, make sure to check out also our UX design blog. We share valuable insights, tips, and best practices to help you grow your skills and knowledge in the industry.

‍