A designer explains how to approach web and mobile design based on context. Start with responsive design as your single source of truth, then choose desktop-first or mobile-first depending on where your traffic comes from. For mobile's tight space, break content across screens and use accordions or progressive disclosure to avoid overwhelming users.
Chapters
Oh, and we're live! We're recording live and direct. Let me put this down. I was kind of just curious whether this remote was going to work, but looks like it did. Okay, so what I want to start doing more frequently, because I'm applying for jobs and I get some really good questions asked, so I'm going to start recording the answers because, you know, why not? It's good— it's good UX discussion. I've got one right here. Let's see. How do you approach designing for both web and mobile platforms? Now, I'm not even going to look at what I responded. I'm just going to kind of like, you know, let it flow. And truthfully, the answer is, is it depends. I mean, which is the answer to most things. But I've had situations where the web kept the same— well, the, the mobile, like if it was a native app, it kept the same design as the responsive web. So really, we were designing for responsive web that was translating to the native applications. Because that's really what you're, what you're going for, right? Like if it's, if it's responsive, then you usually design for all the breakpoints unless somehow you like split mobile and desktop. Now I have had that situation too, where we designed for desktop first because prime, the users were primarily, um, users on desktop. That's where we saw most of our traffic from. And then after that one, we would do different, different designs for mobile and then test those separately. But It really depends. That way where we went desktop first and then mobile, there's been times where we went mobile first and then desktop because we wanted, you know, the native application was the priority, and then we wanted to scale it up and figure that out, which is very popular. A lot of people like to go with mobile first. I think, you know, it really depends. Really, I think it's figuring it out, what needs to be there first, what information you need, what are you trying to convey, what flows and what are you really trying to solve with this design that translates to all the screens. Obviously, you have less real estate in mobile, so it means either you break it into multiple screens, or you add, you know, you hide and show things based on, you know, an accordion, the collapse, a different page, different information, different ways to kind of present similar information, but you may have to break it down into more steps, or kind of giving people what they're looking for before they before giving them everything, right? Before you get cognitive overload or you're scrolling for 9,000 years. So it really depends on your, your product, on your users, on the information, on the scope. I've had— I've worked with teams, like I said, that had a completely different team for native products. So we designed it responsive, you know, so desktop, tablet, uh, well, we had extended desktop, uh, desktop, tablet, and mobile, and it then translated to the native application. Uh, the good news is when they were working with me, it was pretty similar. Like, I already done the thinking to kind of translate it to that mobile, uh, the mobile platform, so they didn't really have to change much. They kind of looked at it, reviewed it, but not every team was doing that. Some were just designing for desktop and extended desktop and not doing tablet or mobile. I just was trying to go above and beyond, and because realistically I think your design should be responsive. You should think about how they're going to translate because people do have different browsers, different screens, and that's just kind of my thinking on it.
