Ensuring Design Consistency Across Different Devices and Sizes

All right. I've got another question here I think is really good. How do you ensure consistency in design across different devices and screen size? So in the last discussion, I talked about my approach for designing for both web and mobile platforms. Now, just to elaborate, what I will do when I'm trying to design something is I start off with like no UI, right? It's like all words. I try to figure out the— where it's going to be using information architecture and the user flow and what the user is trying to accomplish and what information we need to show in that step. For example, if they're, if we're trying to send a direct message, well, first we need to figure out where are they, are they going to find the user, right? Like, are they going to say, hey, I'm going to start sending direct message. Who am I going to send a direct message to? So now I need to find the user. And now I need to input that message, send that message, confirm that it's been sent. And, you know, some kind of either way back or whatever. So that being said, I've now kind of figured out the flow. So from there, I'm going to figure out how that fits in into the UI. If it's desktop, maybe you might have a list of users on the side and then the messages, right? That's kind of like Facebook Messenger or WhatsApp or any of those like on the bigger platforms. But if it's mobile, you might see a list of contacts and then you go from there, the contacts to the screen. Now, how I ensure that consistency is by figuring out what information needs to go there. in these, these components or these lists or items together. Now, if you notice, both of those, like the mobile and the desktop, kind of had a customer list or user list that you're going to see. So I'm going to identify what needs to be there in order to, uh, in order to make that decision of what should be there. So realistically, I'm only designing it one time, and that same time I'll probably turn into a customer list component, um, with a customer CustomerListItem as a component, so the customer list is obviously a list of CustomerListItems, and that will be the one that's displayed on mobile and then also on the side of the UI for desktop or bigger platforms. So realistically, it's just good componentization, good understanding of what information needs to be there. Now, there— this is where things get complex or a little bit more advanced. It's where your components shift a layer layouts on different sizes. And this I, I learned in the past, I thought it was really cool, but you might have a component with two different variants, one being an inline versus a stacked, and you may even have three depending, right, depending on your sizes, depending on the responsive behavior. But I would still use the same component that's probably made out of multiple components to make a different variant for that responsive behavior and then switch it based on what's necessary. Realistically, the answer is lay out good components and you'll figure that out. But for example, you might have a search bar with filters and then some kind of button or something. I don't know, maybe it's a select type that's going to select the type of search, a search input, and then a button. Now on desktop, that might be— I mean, on mobile, that might be too much. So you may have filters and then a search bar and then a button below it, right? Well, it's going to stack them. So I would still take both of those layouts, put them together, and call it like search container, and then, uh, keep that consistency because you're keeping those same layouts on, uh, both mobile and desktop. So still having the responsive behavior ahead of time before just jumping into the UI and throwing screens together. Really, I'm thinking about it more of a componentization or modular section of the screen or of the UI.