Design Isn't Actually That Hard [NO SKILL REQUIRED]

In this solo tutorial, Charles Postiaux shares the exact workflow that helped him grow from zero to $25,000 / month as a solo product designer for multi‑billion‑dollar companies. He begins with a personal anecdote, then outlines his three‑pillar design framework. The first pillar is a rigorous project scope: he explains why the scope is the foundation, breaks it into the classic "what, why, when" questions, and lists essential scope features such as customer feedback, edge‑case considerations, design‑system impact, inspiration assets, and technical questions for engineers. The second pillar covers concrete design heuristics – the "multiples of 4" rule for typography, spacing, and component sizing, hierarchy and list ordering, and a systematic approach to colors using shades and opacity. The third pillar focuses on building responsive, component‑based systems: he demonstrates using Framer (and Figma auto‑layout blocks) to define mobile, tablet, desktop, and widescreen breakpoints, explains block‑based layout for scalability, and shows how to handle edge cases like text overflow. Finally, he details how to construct a design system with reusable components, variants, and states (default, hover, active, click) for buttons, icons, tables, and sidebars, emphasizing the long‑term time savings. The video ends with a concise recap and a call‑to‑action to subscribe.
Chapters
I went from $0 to $25,000 a month as a solo designer working for companies around the world worth $2 billion. In this video, I'm going to show you my exact design process that I've broken down to 3 design pillars so that you can do it too. First, we need to outline the scope. The scope is probably the most important step when you design. This is what everyone will rely on for the rest of the project, pretty much. And so you need to be as clear and as detailed as you can so that there is no mistake and you can already plan what's coming up. Because when you design, this is not the time to think about, oh, actually maybe this feature doesn't need that. And I think that's what a lot of young designers or people who don't know design tend to forget is that they just jump in the designs and try to figure out as they go. But it's always difficult to balance it out because you need to be really focused on the design itself. And at the same time, figure out what do I need and why do I need it? The goal of the scope is to outline the project initiative. That's what pretty much this is about. And so there are 3 main things that you need to have in your scope. You need what? The why and when. So the what is pretty much what do we need? What is this about? What's the goal? Like, what's the goal? Where are we going? Do we need to design a flow? Do we need to design a feature? Do we need to make an update? A design project or design initiative should always be like this main goal, and then you break it down into smaller chunks. And each chunk is pretty much that, like what this is, why do we need it? So pretty much that's the next step, which is why. Why do we need it? What Do we want to achieve and why do we need to achieve it? And then we have the when. When do we need it for? I think usually asking the why in every step, like even the what, like why is this goal even something we care about? Why do we care about that? And the same for when. When do we need it? And why do we need it at this time? Asking those questions for the when is really important if you want to become more of a design lead or a strategic designer, because if everything is urgent, then nothing is urgent. You need to figure out which tasks, which initiatives are the most important for the business, for the team, depending on you as a designer and designers you work with. Is this going to be fast? Can we do it in a day, in a few hours? Can engineers do that in a few hours? Do they need more time? Do they need a day or a week to develop it? And so if you're able to already think about those questions early on and be as precise as possible on those things, then you're going to stand out a lot as a designer, but also make a really good a solid project. And then for a scope, we're going to need to have a couple of, I'm going to call it scope features. It's like things that you need in your scope to really make it work and make it as good as possible for you and the rest of the team. The first one is customer feedback. I think that's a really, really important one, which means, so coming from interviews with them, quotes, feedback, like written feedback, clips, anything that is related to your customers and your target customer. Like that should be also target customer. What I realized is usually customers And users only use a product for one or two features or one or two goals, and that's it. And a lot of products tend to over-feature their products, which means that they kind of lose their users or it makes it too overwhelming to use those products. And so what I try to do all the time is to remember what the goal, the very specific goal of the product is, and make sure that whatever we're working on, whatever we're designing moves us towards that goal and makes it even more obvious. And that's going to be really important when you think about user feedback, interviews, quotes, is because sometimes what some specific users want might not be what is good for the product, what is good for the business. And so I think it's always interesting and smart to add some perspective to that. Like, is this really relevant for us? And some of it could be not relevant, but maybe the bigger picture would be relevant. Maybe they could say, oh, I don't like this feature because there is too much friction. Well, maybe this feature is not that useful for the product, but the idea of Friction and having this feature being too complex might be something that we want to look into. This should always come from there, or that should be a direct source of information for decisions that you make along the way. And so you should always talk or have some previous interviews and discussions with your users. And you should always, you know, talk with them along the way on making sure that this is something that resonates with them. From that, we're also going to need ideally edge cases. It's not always the case, like some projects don't need that, especially if it's a V0. It's more like, what's the foundation? Where do we want to go? What's the big picture? And sometimes edge cases are not needed. But if you work on more granular, specific design initiatives or projects, then edge cases are really important. Like, what's the worst case scenario? Okay, what if the user is on this tiny little screen? What if the user has a super long name, right? Like, these are very basic edge cases, but it's just to put into perspective the idea that you need to think about those for your scope and your design projects. You are also going to need design system updates. Is it going to impact the design system? Do we need to update, change, remove, add anything in the design system? And that's something you also need to discuss with engineers because usually products have design side of the design system and then they have the engineer side of the design system. And so if you need to make updates because it's going to help with this feature, then you need to include it in the scope so that engineers are aware of it. Design inspiration is another one that I think is nice to have. Especially if you work with different designers, because this way you can kind of share together the big picture, like the design style, aesthetic vibe that you want to get for specific design. So that's going to be screenshots, visuals, products from competition or other products that you liked or specific screens, et cetera. And the last one is technical limitation or questions that you might have for engineers. So it's usually doubts or things you're not certain about that you need to discuss with engineers. So that's usually what you talk about once you're done with the scope. You're like, here is a scope for this thing that I'm working on. Can you review it and answer my questions there or make sure to address any things that you have as well, like any doubts or questions you also have regarding that scope? And then you can discuss. And so that's it. That's pretty much the scope. That's how you outline a project and make sure that it's as good as it gets. Because remember that this is the foundation of a project. The whole team is going to rely on it. Usually people are going to ask you about it. And so you need to be on top of your game regarding whatever project you're working on and whatever that scope is related to. Then it's time to design. I believe that anyone can design because there is a process that you can follow and that you can work on and improve over time. So the first one is multiples of 4. It impacts pretty much a lot of things or everything in design. So text, heights, spacing, most of the time multiples of 4 are really helpful as a general rule when it comes to design. So usually for text, it would be like 12, 16, 20, 24, 28, 32. These are like good numbers to work with your text. And usually when you create like a design system or some guidelines around how you use text, you want to start with the bigger one at the top and then go down pretty much like that. And you don't really need to change that very much. Sometimes there are going to be rules where you use multiples of 2 instead of 4, but that's some like very specific cases. Like for here, for example, maybe you need a text that's like 10 pixels. You could also have 14. Sometimes you could have 18 as well. That's more like granular where you need those multiples of 2 instead of multiples of 4. So that really depends on the And by the way, that's how you also use like 4 cards. Like it could be like cards here and then some cards there. And they could also rely on multiples of 4. So here those cards could be 12 and those cards could be also 12. And then you would maybe add a text here and the text you will try to space it a bit more. So whoops, maybe like here. And then maybe the text also has like a description here. So the text could also be like 4, for example. And then you could have again like 20 maybe. And so you can see that with multiples of 4, you can already kind of start designing something that would look better than if you just freestyled it. And it's the same with heights. Like I'm thinking about like buttons, for example, like buttons, you could define it as like it cannot be higher than 20 pixels. So that's 20 pixels. And then you could do another version where it's 28 pixels and that's it. And then you would have a small, and that's going to talk about, I'm going to talk about it a bit later, but this is how components and variations work when you want to design systems and processes that you don't need to change And that's super helpful to go faster and design more accurately for almost any design you want to have. So that could be our small variant and a large variant. And it's when you select your components, you can decide, do I want a small one? Do I want a large one? And then for those, we can dive deeper into it later, but then you would have states. So like this would be default, and then you would have maybe outline. So outline would just be that. And that's how you pretty much do a design system. And again, just with the rule of 4, you can already like do most things with a product. If you're not really good at design or you don't know much about design, then stick to the rule of 4. It's really good. And then based on that, you can kind of get the idea of how do I determine the hierarchy of elements. So for text, for example, you can see here, and naturally you can see it when we did that list, the bigger the text, the more obvious it is. And that's usually how you're going to read it from the biggest, most obvious one to the smallest, less obvious one. And that's how you want to think about it for text, for buttons, for dropdowns, even like a dropdown usually. It's going to be, you're going to have text elements in a dropdown, right? Perfect. And again, like you can see multiples of 4 for the paddings and the spacings. So you're going to usually have dropdowns like this. And what happens is usually people remember like the ends of, or like the edges of a list. They probably, it would probably be something like this with like opacity in terms of what they remember. And so you want the most obvious actions or goals to be on both extremes. And so usually at the bottom of the list, it's like the scary stuff, like delete, or more like actions that you want for like general actions and you want them to stay consistent, right? So you need to determine that early on. So like actions like delete, duplicate, share, and then at the top is more like open, view details. And so usually that's how lists work. And you need to think about the hierarchy of that. Like what's the goal? What's the primary goal? And if people want to delete something, they already know that they want to delete it, right? Make it very easy and obvious to access. And that's where interviewing users is so important because you need to know, like you can show them this. And then you can maybe do like another version, or you maybe do it like that. Maybe view is the top, then details, and open. And you're like, which one would you prefer? Which one you think is the best for your use cases? And that's how you, you become more again of a strategic designer. You use data to decide what designs are best. You don't just say, oh, I like it this way better. You are like, okay, this product, these users said they prefer this one compared to this one, so we're going with this one. And this way also stakeholders or managers or leaders, they cannot really say anything against it because you have proof, you have data for it. Then I want to talk about screen sizes and responsiveness. So here I am on Framer, and I think that's a really good example to understand how responsiveness and actually creating something that is real works, because you cannot just place anything randomly and expect it to be responsive and work on screens. You have to actually think about it. And be technical about it, I really like Framer for that. And I recommend anyone to start with Framer and just try to like understand how developing something actually works because it's more complex than you think. I usually try to rely on, on what Framer does for creating my own responsive designs on Figma. And so you can see like, for example, mobile would be minimum 390 pixels of width and maximum 809 wide. And so my goal when I design is always to design for the smallest possible width So that we have like the worst case scenario. And that's pretty much like edge case in a way, because if it looks good on this, then it probably is going to look good on like the wider responsive screen. And for tablet, it's going to be 810 pixels wide up to 1199 pixels wide. And I think the goal of being that specific is not necessarily for you as a designer, but also for engineers, which have to determine that they have to define what's the limit, what's the moment where we shift from mobile to tablet and tablet to desktop. If you just give a random number, you're like, oh, this is the desktop version or this is the mobile version. They're like, cool, but when do we transition? And that's why being a designer and the scope is so important because you have to give them the answers to that. And of course, this is like more like a one-time thing because once you've implemented that rule, then it doesn't really change. And then for desktop, it could be 1200 pixels wide minimum, or you could also add another one that's more like 1440 pixels wide and further. Which could be defined as a widescreen. And I think widescreen is also interesting because do we want to have the design scale with the screen size or do we want it to stay the same after desktop? And so one way to do that is to have a max-width. So I added a rule that said max-width, as soon as it reaches that, the screen size or like the design or the content inside the screen doesn't scale more. It stays the same and it stays centered. And so when you design products, when you design apps, you need to think about that use case and that specific scenario where What do we do when it reaches that? Do we want it centered? Do we want it on the left? And using Framer, that also brings us back to Figma and my idea of blocks. I think for designing, you need to think about blocks because it helps a lot for responsiveness. Like here, for example, like that's a block pretty much because it's like, so here it's not a layout in Framer, it's a stack, but it works the same. It's like, how does it scale with the design? For example, here, that's a design that I've done and you can see that it does not scale, right? It's not responsive, it's not in blocks, or it's not outlined well. And I have this other design here for Jasper, and you can see here that it's pretty responsive. Like it adapts based on the screen size, and that's how you're able to help engineers better do their work and make the design exactly the way you want it to be. Everything is an auto layout. It's like Inception, but for designs. It's like, this is a block inside the block. There is another block inside this block. There is a lot more blocks. The button is an auto layout, and then you just zoom out. And everything else is also another layout. And that's what makes it responsive. And you can see that it's a lot of work. It's a lot of details and thinking that goes into how do I make this design responsive and good on different screen sizes. And this, for example, could be an edge case. This text goes into 2 lines. What do we do? Well, option 1 is it's okay. We make it this way and it stays like that and it's no big deal. And option 2 would be the other ones that are 2 lines could also fill the container. So it stays pretty good looking no matter what. The last option that I can think about right now would be to add those 3 dots to say there is more. And so on hover, when you hover that text, it shows you the whole thing on a tooltip, for example. So that could be another option. And the last thing I want to talk about with designs itself and how to improve your designs without too much design skills, if I can say so, would be colors. But colors is a bit more like related to aesthetic and style. So it really depends on you. I think the only thing that I can really say about it is that one way to make colors work for you, even if you're not that good at color, is to use shades. And shade is pretty much the same as text. So the most important should be very visible and the least important should be not that visible. It should still be like, the contrast should still be high enough and you need to check that. But anyway, here for shades, just to give you an example, I'm going to put everything in black and this would be like the most important one. And then we just reduce the shades until the end. And so this way you can see that usually you would try to get the most visible one as the priority and the least visible one more like invisible or just full white. And yeah, pretty much like this. So that should give you a good idea. And then you can just change a color. And so it's a good general way to get started with designs. And a trick that I use also is to use opacity levels to get those colors. And then what I do is, because the problem is that as soon as you put it over something, the color kind of changes a little bit. Like you can see, it's not the same color between gray and white. Because the opacity is different. And so what I do is I duplicate it, then I select each square and then press I to pick a color and then pick the actual color for those squares. I need to up the opacity to 100% again. And that's it. And this way you have actual full colors and they look really good. And I think that's an overall good way to get started with colors and get something that looks good. And finally, I want to talk about systems. So we talked about it a little bit in Figma with the design systems and like how buttons and states work, but I can show you in some of the designs that I've made, like this, for example, for Folk, a redesign concept. You can see here that you always need to think about components and states. I don't think everyone needs a design system or complex design systems, but once you start scaling your designs, once you start designing for a lot of different screens, it becomes almost necessary to have a design system simply because it saves so much time. Like, for example, just an icon, if I end up not liking this base color, I can just change the component itself and be like, okay, so this gray should be slightly darker. And then all of these icons are going to change colors. And speaking of that, imagine that this would be a component, like this could be like a sidebar component, or even sidebar button, we could say. And then what I want to think about is the state. So you can see here that this would be like a default state, there is no background. So it would probably be like a ghost, or maybe the background is the color of the actual background, then I could have like a variant where we have like a little icon or little number here, this would be probably the active state. And then we would also need a hover state. Same thing with buttons, like all of these come from the same component. This is one button. And so the button could have multiple variants. And this would be like the default one. We will need also hover and a click state as well. And same thing for the table. And again, it's the same thing with blocks and a block within a block. Like the table is a component and inside this component, there are multiple components. So there is like the kind of header of the table. These are components and this could be like a variant 1 where you can select it. Then there is variant 2 where it's empty. Which is text, then variant 3 with maybe like an element, or maybe this is the actual like active state. And same goes for the rest of the table, like each cell. And again, the usual, like what happens when you hover it? What happens if you click on it? There might be a dropdown to select other ones. And so that could be a flow for engineers. Maybe that's maybe a description, like view this other flow to see how it works. It's a lot of details and a lot of extra work that you need to do upfront, but then the benefits on the long term are super, super good because then you don't need to think about, oh, what's the hover state for that? What's the click state for that? It's already done. It's there. You just have to click on a dropdown in Figma and change it from default to hover. And that's it. It's done. You don't need to design it anymore. So to summarize, remember that you need a scope where you outline the whole project, be as clear and specific as possible. Make sure to use user feedback to make informed decisions with your designs. Then to design, you need multiples of 4 for text, spacings, heights of like your buttons, your cards. Elements to make sure that they stay very organized and it looks aesthetically good. You also need to define list and hierarchy. How do I determine if it's something that should be at the top or at the bottom? How do I make sure that people can easily scan my design because of hierarchy? And again, make sure to involve your users, your target customers to know which options work best for them. You also need to think about responsiveness, like on Framer I showed you and use blocks to help you create designs that are responsive. And finally, I really believe that Once you're really satisfied with your designs and you see where you can improve, building a design system step by step could be really beneficial for your product. Having multiple components, multiple states per components is the way to go. Thank you so much to everyone who've been watching and subscribing to my videos. That really means a lot to me. Also, YouTube thinks you will like this next video, so make sure to watch it.










