Jason Grigsby – Responsive Web Design with Mobile in Mind
Podcast: Play in new window | Download (Duration: 26:39 — 13.9MB)
Subscribe: iTunes | Android | RSS
Check out Jason’s daylong workshop from the UX Immersion Mobile Conference, now in our All You Can Learn Library.
With the mobile web, specifically m dot sites increasingly becoming a thing of the past, responsive web design has become common practice. The ability for your site to display across screen sizes and devices, reduces development time and allows for one design to work anywhere. However, this shouldn’t signal a shift away from mobile-first thinking.
Jason Grigsby, of Cloud Four, believes that there are considerations that responsive design alone doesn’t address. The total experience of your site is more than just what it looks like. Simply using media queries to optimize your site’s design for different page widths is not a viable solution. Page weights, image sizes, and network speeds all need to be factored into the equation.
In Jason’s mind, performance is a key differentiator. He says that you can have a beautiful design or the perfect user experience, but if your performance is bad, people won’t use it. Sites that look good and work well on the desktop may feel slow and bloated on a mobile device. Starting with performance in mind and considering mobile-first avoids these problems early in the process.
Recorded: December, 2013
[ Subscribe to our podcast via 
←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]
Full Transcript.
Jared Spool: Hello there. Welcome, everybody, to another episode of the SpoolCast. Today’s a great day, because I’ve got the fabulous Jason Grigsby with me, talking to us about responsive Web design and the designer’s view of that.
He’s going to be speaking at the UX Immersion Mobile Conference, which is going to be April 7 through 9 in Denver, Colorado, and he’s giving a full-day workshop there, talking about what it takes to do mobile-first responsive Web design. Jason, how are you?
Jason Grigsby: I’m doing well. How are you doing?
Jared: I’m doing great. I thought we could start with some of the idiosyncrasies of responsive Web design, particular this one that’s really come into my focus lately, which is that things that you would think are easy, moving things around on the page.
On the left or the right or someplace like that suddenly, just simply moving something around, or things of that theoretical simplicity, suddenly become really complicated for the developers.
This is a mystery to me when it comes to responsive Web design, how these things get complicated underneath the covers so quickly.
Jason: I think some of this is they are things that have always been difficult, it’s just that we’ve never been asking browsers or desired browsers to do as much moving around of things as we want to do now.
In responsive designs, it would be really awesome if, depending on the size of the screen, we could move a particular block or an element from the top of the screen to down below. Really, to pull that off, we either need to have something in CSS that enables that.
Because doing so in JavaScript is a bit intensive. It’s a lot of work that you don’t really want to do. We’ve got stuff on the horizon, like Flexbox and things of that nature, in CSS that might enable it, but in the short run, yeah, it is more difficult than it seems at first.
I think, more importantly, responsive design as a whole really requires more collaboration between the people who are doing design and the people who are implementing those designs, because one, a lot of the decisions that you need to make about design only really happen.
Once you get stuff into the browser and you’re able to figure out where things start looking bad. It just doesn’t make sense, for example, to do wire-frames for every single break point, and in a lot of ways you won’t know breakpoints until you actually see the content in the browser.
The other piece of the puzzle is that, if you have teams that are working well together, where designers and front-end developers are collaborating closely, then things will come up, like us doing a workshop. It was a corporate workshop where we were working with a client’s website.
And they had a simple thing, search results, right? These search results had content and then a photo associated with that content on the right-hand side, and this was desktop-based search results. Totally made sense, looked great.
When we moved that down to what we would want to do for mobile, it made the most sense for the images to be on the left-hand side and the list view, typical disclosure, little arrow on the right.
Because now, if we tap on it, then it’s going to slide in from the right-hand side, all those things that are UI conventions that we’re accustomed to seeing on small screens.
Programmatically, moving the image from, and not just one image, but 20 or 30 images on a search-results page. From the left-hand side on small screens to the right-hand side on wide screens was a lot of work, a lot of effort being done.
For something where, if we simply just moved the images to the left-hand side on the wide screens, it looked good and it made everything easier. It made the CSS simpler. It made the JavaScript simpler. It made everything simpler.
If you just simply design things without collaborating with the people who are coding on the stuff, you’re not going to see that.
That’s the simple example of the sorts of things that we see all the time, where understanding not just how this design is going to work on one size of a screen but understanding how it’s going to work across the continuum makes you realize that, OK, well, this may work on a big screen.
But it’s not going to work on a small screen. We can accomplish the same design objective in a different way as long as we’re collaborating with the people who understand the limitations.
Jared: This has lots of implications in terms of knowing about how things are going to translate across this myriad of devices, but at the same time, keeping a flexible approach to what we’re designing, because you can’t possibly know every possible size of device.
You can’t just go back into Photoshop and just do up your one or two or three comps and say, “This is what it’s going to look like.”
Jason: Yeah. I think, at a high level, I believe that Web design is moving towards designing systems of component objects that have design integrity to them. This isn’t new. People have been talking about this for a while.
I remember 37 signals blogging about this almost a decade ago, talking about how they design little pieces of designs, to make sure that those pieces work regardless of what’s around them, and that by focusing in on the details that they would create better designs.
Now what we’re seeing is, OK, we need to do this, but we need to figure out, “What does this component do when it’s got a small amount of space? What does it do when it’s got medium space?
What does it do when it’s got a large space?” and then constructing things that pull those systems of components together.
Part of that, I think, is that you can set design intent and design direction, in wire-frames and Photoshop and things of this nature, but because of the fact that those design tools are not fluid and the medium that you’re using is fluid.
The only way to really get a sense of what these pieces are going to look like together is to get them inside the browser, where they are fluid, and start to interact with them.
Jared: Understanding how to design in the browser and how to do that collaboratively is actually, really, the superpower that a lot of designers are going to have to have going forward, then.
Jason: I think that there are different ways that people will respond and modify as they start working in responsive design. I think that there are some people who will look at what’s going on and they’ll say, “OK. In order to be able to participate at the level.
That I want to participate in the design decision-making process, I need to gain some fluidity with CSS.” Maybe they haven’t done a ton of it in the past, but they think, “Hey, the way that I need to be able to respond to this stuff is to be able to make portions of code happen.”
I don’t think that it’s necessary for everyone to be able to do that, but I think that some people will feel like that is something that they want to do. If they do, more power to them, because then they’ll be able to participate in more of the discussions.
Or maybe they’ll learn how to simply use the browser’s inspection tools to be able to make adjustments real-time and then be able to show those adjustments to the front-end developers to say, “OK, this is what I was thinking.”
I think that there are other people who, basically, maybe their skill sets and, really, their time doesn’t allow them to really consume or to become experts in CSS or even just dabble in CSS, but what needs to happen for them is that the process of design needs to change.
Their organization may work in a system where they do wire-frames and they get the wire-frames signed off on, and then somebody’s doing a comp and the comp gets signed off.
Now this is treated like gospel, that this is a document that shows exactly how it should be represented when it gets to the site, and if there are deviations from that, those deviations have to be explained.
Instead, what has to happen is that they need to move the organization from a process perspective towards, “OK, we’re going to be designing these systems, and we understand that we’re not going to have complete fidelity at these steps of the process.
We’re going to shift our process so that we know that there’s going to be iteration and feedback, and we’re going to collaborate.” I don’t necessarily know CSS, but I know when stuff looks bad. We’re going to work together to figure out where it looks bad.
And then maybe I go off and sketch some things to show the developers what I think needs to happen at this particular breakpoint because the masthead looks bad at that size.
We’re making design decisions. That person’s not actually coding them, but they’re actually participating after the designs are done.
Regardless, I think that any organization where there’s been this separation, where people are just doing UX and design and then handing things off, when they move to responsive design.
The designers have an obligation and will need to figure out how to participate in the design decisions that happen once it’s inside the browser, because that is where a ton of design decisions are going to happen, by necessity, in responsive design.
There’s just no way around that reality, so it becomes a question of how do you cope, how do you participate in that?
Jared: This does really require that we think about, how do we want to interact with our teams, what are we comfortable with, and how are we going to get the best design out? While it’s always been the case that the way we interact with the developers, the way we interact with other stakeholders.
Has always influenced the outcome of the designs we create, I think that responsive has required us now to rethink, why do we do things the way we do them, and is that the most optimal way to do it going forward?
Jason: Right, absolutely. People should have always been good team members and good collaborators. [laughs] I do think that in the past, people could have these definitive hand-offs, where my work is done and I hand it off, and hey, the developers are going to go implement what we’ve decided.
And if they run into problems, I’ll hear from them, but 9 out of 10 times, they just do their stuff and then it’s in the browser and it looks great and we move on. The reality is that, if 95 percent of design was done before the hand-off to developers in the past.
In responsive designs, 50 percent’s done in terms of design decisions. A whole lot of the design decisions have to happen after you see how it’s responding at different screen sizes.
Jared: Now let’s shift the conversation a little to something else that happens under the covers, which is the performance of things. Traditionally, in design, at least digital design, the actual performance has not been something that people thought about.
I remember, when I first started doing development work back in the ’70’s, we had to think a lot about performance, because we had really slow processors and really slow medium. Hard disks were just coming into play. We had to do a lot of things on floppies.
The simple act of how quickly could we keep up with someone who’s typing, because we have to read the character off the keyboard and figure out which character it is and then figure out which pixels it is and figure out where on the screen those pixels go.
We had to do all that translation ourselves. That was not built into the hardware or to the operating system. We were always focused on performance and the question always was performance, but in the last few years.
I have the sense design’s moved away from performance-related constraints, because everything’s gotten so fast and you just didn’t worry about it.
Jason: Was that your “We walked to school uphill both ways”?
Jared: Yeah, I think that was it. That was definitely it.
Jason: [laughs]
Jared: The kids today, they don’t understand. They don’t understand. They live in such luxurious lives.
Jason: [laughs] Yes. I think that that is absolutely true, and I can relate to a bit of that because, I kid, but my first modem was 300 baud, so I do know how much progress we’ve made.
The reality is that, particularly when we’re talking about mobile devices, issues of CPU and bandwidth and all of these performance considerations are prevalent, are more important there than they’ve been on desktop. Even on desktop, it’s a big, big deal, and organizations see huge impacts.
The things that I find really fascinating from a design perspective about performance is that performance impacts perception in measurable ways. You can have the most beautiful thing in the world, but if the performance is the bad, people will still think that it’s poor.
I mean, let’s even change it. I said beautiful, but I would say that you could have the perfect UX, an application that’s really attuned to what the person is trying to accomplish, and if the performance is bad, they will feel like the application is hard to use.
You can’t get away from these sorts of relationships. It’s one of the number-one things.
Part of what I find really fascinating about the performance side of stuff is that the vast majority of it, the biggest impact comes from things that designers have control over, and things that are shockingly simple for people to do.
Which makes it all the more frustrating that more sites don’t do a good job on performance. Part of what I end up talking about quite a bit and that I’ll talk about in the workshop is a lot of responsive designs are unnecessarily bloated.
They’re basically desktop sites that are reformatted to fit on a small screen, but they still have all the desktop-sized assets and everything else. Taking the extra time to actually do that correctly is what it means to have responsible.
Responsive design, to actually have something that works well for your users, not just looks well for them. I spend quite a bit of time working with companies about how to deliver responsive design. Once you go past the simple pieces of responsive design.
Very quickly you bump up against the problems of, “How do we build something that’s performant? How do we change our internal processes? How do we make sure that the designers are participating when decisions are being made?
How do we deal with more complex responsive-design issues, like tables?” A lot of what I look at is this, and a good portion of it comes back to performance because of the focus and the fact that such a high percentage.
I think Guy Podjarny’s last review of responsive sites found that 92 percent or something, basically, there was very little difference or were the same size as the desktop versions when they viewed them on mobile.
It is a big, big issue. It is what happens when responsive design gets out in the real world, past the theoretical pieces.
Jared: How hard is it to learn this stuff? Are we getting down into having to do a lot of math to calculate things out in the microseconds?
Jason: There is a lot of that, that can be done, and there are businesses that are amazing at that. Etsy does, in their annual reports, they now have a performance section, because performance is such a big part of what they do and such a competitive advantage that they’re reporting out on these things.
And trying to make improvements in performance all the time. I think that there are a bunch of businesses that are really, really smart about this stuff and are looking at it across the whole spectrum of what needs to be done.
One of the things that I find the most interesting is that, inside the performance community, people have gotten down to the point where they’re talking about different types of specific JavaScript instructions and which ones are faster and not as fast and things of that nature.
That’s awesome. I’m glad that they’re doing that. That is not the stuff that I spend my time worrying about or talking to people about, because what I find over and over again is it’s the simple things that aren’t getting done.
What I’m looking at in responsive design is really about, “OK, well, what is the approach that you need to do to make responsive design performant? What are the five things that you really need to keep in mind? Where do you get the most bang for your buck?”
Generally, I think, even if we weren’t talking about responsive design, maybe if we were just talking about Web design in general. There’s just a handful of things. This isn’t something that’s responsive-design-specific.
It’s not something that we end up talking about in the workshop or anything, because it’s not responsive-design-specific. There’s this simple instruction for a server to turn on Gzip, which is a form of compression, and it is in Apache, which is the most popular Web server.
It’s three lines of configuration. It’s not even code. It’s just three lines saying, “Turn this thing on.” It’ll take text files and reduce the size of them 80 percent.
It’s brain-dead simple, right, but I’ll bump into sites all the time that don’t have that on, and then designers that don’t know that that’s a thing. They don’t even know how to check to see whether their back-end developers have done it.
The designer doesn’t have to know those three lines, right? All they have to know is, “Hey, this is something that I should look for,” and there are tools to check to see whether your page is doing this.
They need to know that it is really, really simple, so that they can’t get somebody telling them that it’s more difficult than it is. Just say, “Look, this needs to be turned on. It would make such a big difference for our users, and it would save us money because we don’t have to pay as much for bandwidth.” All this sort of stuff.
The things that I focus on are really at that level. They’re either things that designers should know, particularly when it comes to responsive design, how do you handle images, how do you do mobile-first responsive design, why is this important.
They’re not designed to be like, “OK, let’s go calculate things and let’s go figure out the nitty-gritty of performance.”
There’s something really satisfying about performance, because it’s the one bit of design that you do that you can actually measure results on, so it can get a little addictive. It’s like it’s got its own built-in gamification to it.
If people were to start thinking about it from a responsive-design perspective and then get excited about it and go do other things, that would be awesome.
That’s not what I focus on. I’m just like, “OK, you guys are going to do responsive design. Here’s how to do it well. Here’s, big-picture, what you have to keep in mind. Here are the challenges you’re going to bump into.
Here’s how you do it in a way that works well and is per-formant, and here’s why you should care about performance. Here’s why it’s actually something that, as a designer is actually, impacts your job and you have the power to change it.”
Sorry. That was a little rant. I just think that people get turned off of performance, for some reason that I don’t quite understand, when you don’t have to get into the nitty-gritty to just understand some big stuff that will make huge impacts.
Jared: I think it’s that it feels technical, right? It feels really deep-down, nerdy technical. You don’t want to sound stupid, right?
You don’t want to say something to someone who actually understands this stuff that would make them look at you and go, “Dude, you just said all sorts of jargon and you don’t know what you’re talking about.”
Jason: [laughs]
Jared: I think some of that is that, this feeling that it’s easy to be in a situation where you suddenly feel like you’re just saying the magic words and other people actually know what they mean and you don’t.
But I also wonder if it’s, when you’re working on paper or you’re working through your wife-frames, it’s not top-of-mind. It’s not present. I’m wondering what things people could be thinking about,
Because it feels to me similar to accessibility, where you’re not asking the question, “How would someone with low vision handle this? How would someone who has limited mobility do a swipe?”
You’re not asking those questions, and then you get too far into it, and then you realize you’ve built something, and now it’s really hard to back those things into it. I wonder if performance is sort of the same way.
Jason: I think that there are two pieces to the puzzle.
If we look at responsive design specifically, and we just look across the spectrum of responsive designs that have been released into the public, we can say with certainty that the vast majority of them have significant issues related to their implementations.
Statistically, this is true. There is an approach to building it that is better from a performance perspective, and it’s better from a multi-device perspective. That is mobile-first responsive design.
Learning what it means to do that and where the challenges are, then it is, I think, hard, if you do desktop-first responsive design, at the end of the process, to try to fix it.
I do think that that is foundational. It’s like, “OK, what does it mean to do mobile-first responsive design, what are the implications of that, how do we go about doing it, and how do we start to shift both the approach and our mindset so that we understand what that means?”
I think that that’s a responsive-design-specific challenge, and I hope, I hope, I hope, I hope. That three years from now we won’t really be having this discussion, because everybody who’s doing responsive design will be doing it this way and this will be just the way that it’s done.
On the Web generally, I think that what you’re talking about, in terms of having it at front-of-mind, the organizations that I think do the best with performance are organizations that have a culture of performance.
They’ve got an eye on it all the time. They’ve got things that are measuring how fast pages or screens are loading, how fast interactions are, and are constantly measuring it. When something goes awry, when those metrics change for some reason, it’s basically the batphone’s going off and everybody’s trying to figure out why that is.
I think it’s Google, I can’t remember which. They basically have performance budgets, and they say, “This particular site or application needs to load in whatever amount of time it is.” If you want to add a feature to it.
And it’s going to make the page slower than that, then you have to figure out how to either speed up an existing feature or figure out a feature that you can remove. It’s basically like, “OK, this is your budget. You have to work within this budget.”
I think that when you’re at that level, a lot more of that is happening for the technical side of things than where I really focus. For me, it’s much more about, how do we get the foundations in place so that when people are building this stuff, they’re starting from a good starting point?
Then you can start digging into the details later on. If you’re not doing mobile-first responsive design, then it’s going to be really, really hard to graft on performance later.
It’s going to be really, really hard to graft on progressive enhancement later. You’re basically coming at it from completely the wrong direction.
Jared: Jason, this has been absolutely a treat. I love talking this stuff with you.
Jason: It’s great talking to you as well.
Jared: I’m really excited about your workshop and learning more about designing mobile-first responsive web stuff. It’s going to be great. For those of you who’d like to attend Jason’s workshop, it’s going to be on Wednesday, April 9, in beautiful Denver.
It’s a full-day workshop, and he’s going to just fill up your brain with everything you need to know about designing around responsive code and handling common responsive-design challenges and all of those types of things.
It’s going to be fabulous. Last year, it was sold out and highly rated, and we’re glad to have him back. You can find out more information about the UX Immersion conference.
Which is going to be Denver, Colorado, April 7 through 9, find out about that at uxim.co. Jason, thanks for spending time talking to us today.
Jason: Thank you very much. Thanks for having me, and I’m looking forward to Denver as well.
Jared: Yeah, it’s going to be great. It’s going to be a lot of fun.
I want to thank our audience for listening to us again and, of course, for encouraging our behavior. Talk to you next time. Take care.