Scalable Design Systems for SaaS Products

Yash Shah (00:02.914)

Yeah, says that we are live. Wait for a couple of folks to join in.

Yash Shah (00:19.754)

perfect. Awesome. Hello and welcome. Hello and welcome to Momentum Officers. My name is Yash, and I'm joined by my co-founders Harsh, Jay, and Koushik to discuss topic of the week, creating scalable design systems for SaaS products. Our goal is to provide you with actionable insights and practical strategies that you can apply to your own products. Throughout the session, we encourage you to ask questions, engage with us, and share your thoughts by commenting.

This is fantastic opportunity to learn from each other and gain new insights that can help drive your SaaS initiatives forward. So let's get started. Jai Harsh Koushik, how are you feeling? How are you doing today? Having some pre-Diwali celebrations at office and obviously finishing up the tasks before we hit on the... Going on a break, like feeling festive today and that's you might, like people who are watching this...

they might find us in unusual clothes but these are sort of Indian traditional clothes that we're wearing today. We had a pre-Diwali party and we had a desk decoration competition that happened in the company today as well. Unfortunately, no one from our part of the team won but that's okay, that's fine but we have Koushik here with us and we want to talk about

creating scalable design systems for SaaS products. So let's start with understanding the basics. What is a design system? Just let's forget the scalability piece for a bit. But what is a design system? So with respect to understanding what is a design system, so a design system is basically the skeleton as well as the muscle for what your product is going to

All the components that is going to create screens, create flows for your product is basically the design system. So it's the base structure from which your entire product is going to be built. So it could be buttons, could be field inputs, could be combination of them. So we will be discussing all that further. But so it is basically creating the entire from the...

Yash Shah (02:44.366)

atomic level of your products component to the entire pages is your entire design system basically. So great. What is an atomic unit of a product? Okay, so I'll come to that. So when you take your product, the design systems, can basically divide them into, it's more of a chemistry language, the way we categorize it.

Atoms, we have molecules, we have organisms, have templates, then we have pages. So your atoms are basically your button, your field input, even a label item is your, all those individual items are all atoms. Now, when you come to molecules, when the field input and the button come together to create a component,

That is your molecule. Right. So basically you put in your field. Because logically that combination makes sense. Right. So you put something in your field input and then press enter in your button. So it says that there is a logical application for that. Then when it comes to organisms, let's say there is a navbar, top navbar, which has the combination that I just explained as a molecule and also has other button links.

as links to the page and probably a, you know, icon, which it sort of acts like a home homepage redirection icon. And that makes an entire navbar that would make your organism basically. So, which is a combination of all the molecules exactly like in the language of chemistry. When it comes to templates, we are talking about the entire layout, whereas a combination, a series of combination of organisms that we just mentioned.

is basically would create the layout and series of layouts which will have a front flow, back flow or side flows within them would create waves. all these things, so this is the structural, so when I said that it is going to be the bone and muscle, so this is the arrangement in which your entire design is observed basically. Okay, there are two parts right, UI and UX right?

Yash Shah (05:12.088)

So when we are creating a design system for any product, right? So what are the things that we should include in this system design for UX and UI standpoint? So again, this is very specific to the product. So for example, at atom stage and molecule stage, would probably have 80 % of the confidence for all the products very similar.

would still have a button, would still have a field input, would still have a lot of common elements, would still have a toast message, alert messages, would still have accordions, would still have, you I can go on. So we have a list of items. With respect to the UX part comes in where, you know, it starts from the stage of layouts and templates and the pages that I was talking. So when the...

First is your layout design is where the UX part comes in which will have a combination of your organisms and molecules that I just explained. So when your entire layout is there, the layout should be designed in such a way that you know there's only so much room in the layout so you can't show everything at the same time. So you need to prioritize a few information over the other. So how you're going to prioritize, how you're going to use probably I could hide a few information, could conceal a few.

I could hide it inside a harvest state or I could hide it inside an open state or something like that. Now that's where the UX also comes in where it turns into pages. So the layout size as well as the pages side is where it becomes more of a core UX. But this is a very interesting conundrum that is very UI UX is there. It's not two different things. It's sort of two sides of the same coin which makes the coin.

So for example, a not well sized button, which is bad UI is also bad UI. So if you have sized a button that is 30 pixel or lesser than 30 pixels, for a mobile, let's which is again an atom. But in mobile, let's say that particular item is 30 pixels, it is not tappable size. So the optimum tappable size is 40 to 44 pixels.

Yash Shah (07:37.038)

and 48 pixel when it comes to Android, 44 pixel when it comes to iOS. So there are certain guidelines. So if you're not designing accordingly, it's bad UI as well as that. So it's a combination of both. need to, that's the little thing. People usually confuse it, thinking that they are two different streams. They are actually not. They are two sides of the same coin, I guess. But it's like...

The design system is that UI or UX? Or since you are saying it's the same, so then it's the same? So the creation of it is UI, Because in Sigma you are actually adhering to the product's brand values and then creating the whole thing. With respect to colors, with respect to the font choices. Even these again fall under you know, atom stage, right? So me choosing what font, what color still falls under the atom stage. That I just explained.

So basically, it is a complete UI system. But how I'm going to take it and use it is a complete UX part, turns out. So while I'm using it, my placement, my position, my sizing that I'm using it in is the UX part I'm talking about. Right. So, Kashi, is given that design system is mandatory for designing any product, for sure.

and obviously you understand the brand guidelines and lot of other aspects and research we'll put into it. But let's say someone is looking for building an MVP or like a very little larger version, another version after an MVP. In that case, what is the need for them to, you know, have their design system scalable? What's the need of scalability in design system at early level? Yeah, that's the And before you answer that Koushik, we have

a chat message as well endorsing the topic that we are having the conversation about from CX Connect Podcast saying this is a great topic. Thank you CX Connect but Koushik please go ahead. at MVP stage it's important because for two things, one is to maintain consistency across all screens. You definitely need to design this one. Second thing is that it helps you build and design very fast.

Yash Shah (09:54.87)

It's from a designer's perspective. Otherwise, I'll give you the other scenario. If you don't have a design system on app, so basically when you don't have a design system, every single time I create a scheme, I have to manually recreate my components again and again. So understanding this is why Figma even created the few features within Figma like components, design tokens, assets.

libraries, all these things were created to help designers and to encourage designers to move more into the direction of creating design systems because that would create utmost consistency. is one. And second thing is that it would make your life so much easier after the MVP is launched because we all know how much founders love to create features within their build, features upon features upon their products. So for you to

keep doing that and to even take a decision upon if this feature is necessary you have to design it first and test it with your own group or with the potential audience. Now for this thing for this element to happen if the design system is already in place before that while you created the MVP stage itself it's very easy to scale a new feature create a new feature using the same so I could it just makes life so much easier for everyone within the team.

to make shift and to get the product out as quickly as possible, which is the crucial aspect of running the product company. So with that in perspective, even at an MVP, if you had a design system at an MVP stage, it's great. If you didn't have a design system at an MVP stage, converting your existing design into a design system is something that you should focus upon and try to

And so, like if I can add to this, right, I sort of believe that as a business level, building a design system has a lot more impact and effects apart from the design team itself. So, very well, it makes the design more consistent, it makes the designers more productive. It also helps your front-end engineering team to iterate and build components faster as well, right? So, when a front-end engineer knows,

Yash Shah (12:17.902)

that all tables are going to look like this, all rows are going to look like this, all cards are going to look like this, all the charts are going to look like this. They are also able to create components in their code, which also helps the efficiency as well. So this is like equivalent, I would say like to sharpening an axe to cut a tree. So while you're sharpening the axe, other people might already start cutting the tree and you might feel that you are a little behind. But once you've sharpened it enough,

you'd be able to cut trees significantly faster, more efficiently, more productively and so on and so forth. Is what I wanted to very quickly add. So like, do you have Koushik something to show in terms of how for a founder who's not necessarily an engineering, for a founder who's not necessarily a designer or an engineer from a business side of things, and they have an MVP that's our, they've not created or they've not seen a design system, what could it

What could it look like? Yeah. So I'll try to show one of our own projects. I just had it with me. I mean, it's always there in one of the tabs. So this is a product that we have, which is equivalent to, I think we can think of it as like an equivalent to the can. So it has editor as a component dashboard and a number of modals happening.

So before the project arrives, what we try to do is we try to build a core element set and base components set. we decide what all, so core elements predominantly will stay the same for most of the products. For example, aspects like what color palette are we going to go for? But in this we very clearly define what are the error colors, what are the danger colors, what are the success colors and everything. And we also define

If there is text, what all color variations are we going to have for even for text elements? Because it's not going to be pure black. It's going to be some shade of or tint of black. So what it is going to be, we define all those individual items. And then we convert them into design tokens within Figma such that, you know, whenever a designer is using it would be helpful. Now, these are similarly we do it for here you could see it, we do it for typography.

Yash Shah (14:44.108)

We do it for icons. What are the icon library that you're choosing? We get all the entire icon library into the platform. Grid system, what amount of shadows are we going to go for and all those things. And then we get into the... So we have defined the atoms. The stage of... This is before atoms also. defining... Deciding upon what brand we are going to go with for this particular.

And then we work on, since now we have worked on quite a number of projects, we work on atoms, molecules, and organisms at the same time. So for example, individual items like banners, breadcrumbs, buttons, and all those things, we usually create them and we keep it. for example, and we also define state. One more very important thing is defining states because we are designing not documents, right? We are designing screens. So screens have states.

So that's where the user interacts with. So all these components from the atom level to the entire layout level, all of them have states. So even for an atom level like buttons, all the states, all the primary, secondary, tertiary components, everything are defined. And then if you go a little bit higher, usually what we do, the way we try to do it is

If there is a particular atom element that we have designed, we put an example showcasing how this particular element is going to come and where it is going to come. So if this is an atom and field input is an atom and email address is an atom, email address and field input and button together, this combination is basically a molecule. And then all of them coming together in one single layout, this particular model would make it an organism.

because you have a combination of buttons, have a combination of label, icon and all those things. And then they are all coming together in a screen would make it a layout, which makes you the create an account screen. And then when I click upon this, if it takes to the next screen, it makes the pages. So we usually arrange it like this. then so you can see all the components that would be possible. Now, there is a thing that one needs to mention, keep in mind is that

Yash Shah (17:08.002)

This is where wireframing would aid heavily with respect to designing a design system. If you have wireframe in a clarity level with the flows with respect to the product in such a way that, for example, let's say in wireframing level, you have identified that there is a file upload element in the product. Then when you come to design system, you would focus on designing how file upload aspects work.

within the product. So we're going to have a loading bar. So when is there a state where, let's say, when someone is loading, what do I show? Do I show uploading? Do I show completed? So if I'm showing uploading, am I going to have an icon for that? So all these decisions would come one after the other while you're trying to define the individual designs. And then you can very quickly get into the product phase where

If you look at this particular product, when we designed it, we just went really fast with it, with respect to creating scripts. Now, this help our design team to focus more on the flows and how could we make it better, rather than worrying more about, you know, is this color fine or is this particular state, you know, active state okay? Or should it be less brighter, more brighter? All these decisions...

None of our designers are thinking that when they are creating a product design stage. They are more focused on how could I design this layout, how could I design the flow. That is what they are thinking. So that is something that we had as a learning from our product design stages itself. During the course, had some learnings we had. Especially while you're designing the screen, the designer

and the team as well as basically the entire team should focus on the flows rather than thinking is this colour fine, is this going with the brand or is this in active state should I make it 40 % less darker or is the text in the right dark shade. So these things are not something that the team should be worried while they making the screens. So even though it seems like something that is very minute but it

Yash Shah (19:29.774)

It saves so much time and eventually it saves development time. there's also one more very important thing is that from developer handoff perspective, it makes life for developers so much better. So having a design system. I mean, like, so they don't have to go back to the design team, the to and fro.

is completely eliminated if you build a very good design system. So we have seen it again and again in all the products that we have done. It happened every single time. So yeah. Yeah. And the same thing, this also helps the QA team, right? If you have the guidelines, right? The QA team also makes several test cases for that. So that the testing will also be fast and the development will also be great. Yeah. Yeah. So I just have a thing is that

Just consider we are building an MV product and we created some design system for that. Now as we grow, it can be possible that there are more components, more style guidance are adding into our design system. And also possible case some of the components that we already have built, it can be changed. We have put some styles for button.

And after some time we have changed the style, right? So how you how we can keep this worsening thing that like if future if want to grow back the our changes, right? So how we maintain the changes in our design system components? So one thing is that if you it's more additive process rather than a replaceable process. If when you have a design system to explain it in much more detail.

At a very rare case, you would change your color of your product. It's a big decision. At a very rare case, would change the... You might change, for example, you might take a decision upon what should be the roundness of my button, which is also a very rare case. smaller decisions like that. It's typically like a rebranding exercise or something like that. That means you the entire design system.

Yash Shah (21:50.83)

But there will be cases, for example, I'll give you very interesting example, which we have encountered also. So there could be a field input, which you wouldn't have created with a drop down. So it's just a field input, but you didn't create the design system in such a way that there is a drop down attached. Now let's say you have launched it only in one particular country.

Let's say now you're launching it in multiple countries or a different geography. Now in your signup journey, you need to do the option for them to choose mobile. Right now you could either have a field input and then a separate drop down or I could combine both and create a field input in such a way that the field input has a drop down inside the field input itself. You might have seen that in many, many times.

So this I might not have created it. So that's why I said it should be an additive process. It shouldn't be a process where you change from the base. So now what all I have to do is I have to take my existing field input, create a component, create a variant of it in such a way that it has an option for mobile number drop down also. Similarly, in future there might be multiple use cases. For example, I could have a situation where

It should be, it should have not a drop down but just a fixed state within my field input, say, HTTPS just before as a prefix, right? So these kind of situations will happen and you have to create it in an additive way. So every time you have to create a variant within your component and keep improving. So that is the specific edge case. Actually, that's a good question because many people...

What they do is they go back and change the whole thing. You shouldn't do it because it makes everyone's life, it might be very, designers love spending time in sigma. To give you an example, they like to read the sigma files for long time. But that's why they love to keep re-overwriting on top of the design file again. But it will just make everyone's life because someone has to go there and develop the whole thing.

Yash Shah (24:16.334)

So let's not do that. So let's make it just an additive process. this brings me to another question. It is obvious that one should not change the whole design system completely. But then there are certain applications which needs to be done, as you mentioned in the recent example. So are there any processes or metrics there to evaluate the nitrate on the existing design system? And if yes, then upon what frequency does one update the design system?

I think it's at what scale of your company do you want to the decision? very genuinely think that I mean I've seen products which have created design systems and until they got acquired by like for example I can give you one example Superlist is one product Superlist is a task management team so they created the product this is the same design system that they had

they launched by the name MVP and even after the launch, even after Microsoft's acquisition, they still maintain the same design system. The company got acquired by Microsoft. Wunderlist. Yeah, Wunderlist. They changed it to Wunderlist and so still they maintain the same design system. But there are companies which went to an extent to change the whole design system and they went to an enterprise level platform. So for example,

I think Atlassian is a very good example of creating. They spent great amount of money and time into creating a very, very detailed design. Even Uber, for that matter, they had a very different UI. then it's also, I think one interesting metric or point is that if you are finding that your user is having a difficult

in using the application or the product at a very base level where they're having legibility problems, accessibility issues with your product, then it is definitely a time where you need to update your design. If there are accessibility issues, then it's a big, big problem because we have seen, because let's say if I'm an app like Uber or Cola, which I'm probably using the application two to three times a day.

Yash Shah (26:38.995)

And if the brightness in my screen, we can't expect all the devices to be at equal standards. different devices are at different quality standards. So even at a very bad screen, if your application colors are not visible, or if your button is not even seen, then it's a big problem. So.

Those are the things where, so it's also a question that when does a company reach to a level where they have this data? They do this user discretion, they have this data. yeah. And so just my chance, if you are that company and if you have a problem, please reach out to us at Momentum. We can create a design system that will for sure be accessible. We've done this a lot of times before.

And we make sure that your design system is as optimized as possible, as efficient as possible, as accessible as possible. And the experience of using the web or the mobile app that you're working on is that your users have or your customers or consumers have is as great as possible. And so we have a question from the chat here. Someone's asking, what are some great places to kickstart

design system. So are there design systems that are already created and then exist out there in the world that we could borrow from or we could learn from or we could improve upon them or build more things on them. So like if we don't want to start building a design system because it seems like a very difficult thing to do like to you know design each and every component or items as you put it. It might be a big task but we are you know founders of a startup we want to move things along very quickly.

And the question is not whether we can make an application that is the best looking applications or not. The question is much more profound, whether what we are about to build is that of value to anyone or not. So that's what we want to solve for. So if you want to start a design system today, are there any resources that are available that we can look through? I think that's the question. Yeah. So great question. So I think to start with, to begin with,

Yash Shah (29:04.781)

We have both Google and Apple who have made their entire design system open source. you can check out their guidelines. Google has human interface guidelines. Sorry, Apple has human interface guidelines. Google has Google's material design. So it's currently Google's material design 3. So you can check that out. So they both have their design systems out. So why I'm suggesting these both is because they are ultimately you have probably, if it's an app,

that you're designing, you're probably going to launch it in App Store or in Google Store. And if you don't follow these guidelines, they will not approve your app to be placed in their markets. If it's a platform, again, it's probably going to be in Google or in any of those. So still, has to follow and maintain those standards. And when it comes to

Apart from this, there are lot of other design systems. So we have companies who have open-source their design systems. We have Thread who has open-source their design system. We have Atlassian. We have Google. We have Shopify. We have almost all the large scale companies that open-source their design systems because they want people to build products upon their design systems and see how it works.

We have Microsoft, IBM also who have open-sourced it. Microsoft has been one step above and they have even created individual product lines. But you can see Teams design system. can see it's all out there. You can search it and you can find it directly. It's also available in Sigma's marketplace, Sigma's community base. And apart from this, there are also design systems that you can buy from.

You can pay and get them. There is Untitled that is out there in the market which is pretty famous. You can pay for it and you can get it. There are also a few of them which are much more towards the costliest side. Usually the paid ones are much more towards the costliest side. The reason being because they are very expensive and they are very often updated. So that gives you an advantage of the fact that you don't have to keep checkout.

Yash Shah (31:25.965)

But one thing that you should keep in mind is that no design system will be 100 % fit for your product. And then it would probably do a job from 50 to 70%. 70 % means it's great. I think at an MVP level, probably it do 70 % of the job. But that's why we named it Scalable Design Systems for your SaaS products. Because.

You could take any design system and you could build it each level of the product because it's going to have all items and even monitors that we just discussed. It's going to have all buttons, screen inputs, accordions, messages, everything. It is also going to have probably an entire navbar constructed for you and showcased. also have front-end libraries who have made their design systems and made it like. We have Tailwind who has done it. We have...

different print and libraries and design systems are done. So all these people even those are also from a developer's perspective the print and library itself is giving the results which makes it much more easier. So the point here is that no design system is going to do the full job for you. You have to at some point get the designer to scale it and create. Come to momentum right at some point you have to come to momentum.

to finish their design system. But that's great, right? So you can get started. I 50-70 % it's not the complete job done, but it's good enough to get started and to launch an MVP, get your first few, like the first 100 customers who love what you're building, who love what you're doing. And that's good enough to get there. And so for all the people who are, wherever you are watching this or listening to this in the comments, we will be adding the links to all the resources that Koushik mentioned, including Tailwind and Untitled and

Google's Material UI and so on and so forth. So you'll be able to find all of those things up over there as well. But with that, we have come to the end of the conversation for today. Hope this was a meaningful conversation for you and we able to, we may not have answered all of your questions, but maybe we've answered some of your open questions as far as creating

Yash Shah (33:46.795)

scalable design systems for your SaaS. Hope to see you in our next stream. tuned to Momentum91 and subscribe if you have not. Subscribe to the channel, subscribe to the account wherever you are watching this. Follow us. And the advantage, as I shared previously, of subscribing is that you will not have to subscribe in the future. So why put until tomorrow what you can accomplish today and why put

something off until today if you can accomplish right away. It's a harmless click of a button and I had a conversation with both YouTube as well as LinkedIn that your subscription and your followership will be given to you for free. So there are no charges for doing this. But thanks, thanks everyone once again wherever you joined us and hope to see you again next week. Until then, Happy Diwali to all of you and see you soon. Yeah, Happy Diwali guys. Bye bye.

‍