Episode Transcript

Karen:

Hi, this is a responsive web design podcast, where we interview the people who make responsive designs happen. I’m your host, Karen McGrane.

Ethan:

And I’m your other host, Ethan Marcotte.

Karen:

And this week I am shimmering like a New York sidewalk in August. We have Eoin Comerford and Steve Anders from Moosejaw joining us today. Welcome!

Eoin:

Thanks for having us.

Steve:

Nice to be here.

Ethan:

But before we dive in, I’d like to take a moment to mention our sponsor, Harvest. I’ve actually been using Harvest for years, so I was incredibly excited when they approached us about sponsoring the podcast. Harvest bills itself as a beautiful business tool for tracking time spent on client projects. I’ve worked with a number of teams who love it. They love how easy it is to track hours across projects, how beautiful and well-designed their reporting tools are, and I’ve heard from a lot of folks that I’ve worked with that Harvest really helps them stay on time and keeps their project under budget. Now, personally, just speaking for myself, I love its invoicing and expense management. I can update my projects in Harvest with my web browser, with my mobile device, and regardless of the size of the screen I have closest to me, it’s a real joy to use. So if you’re interested, you can check out Harvest at getharvest.com today. What’s more, after the free thirty-day trial, you can enter coupon code RESPONSIVE at checkout and save fifty percent off your first month.

Karen:

Eoin, Steve, I’d love it if you would both just introduce yourselves, let us know a little bit about what you do at Moosejaw. Eoin, you want to start us off?

Eoin

Sure. I am the CEO of Moosejaw. I’ve been with Moosejaw since 2008, I joined as the VP of marketing and then also took on the IT role a couple of years later, and then I’ve been in the CEO role for about three years now. So, I definitely come from more of that marketing and IT side of things.

Karen:

Fantastic. Steve?

Steve:

I’m a front-end developer at Moosejaw. I’m the primary contact for this new responsive design site on the front-end. I’ve been with Moosejaw for about two years and it’s a pretty awesome place to be.

In 2011 responsive wasn’t even much of a thing—at least amongst ecommerce sites—and as far as we know, nobody in the top-500 internet retailer sites was using responsive. So, it’s not like we read an article and said, “We should go responsive.”

Karen:

Well, I was really excited to talk to you guys because I think you have a fantastic story. It sounds like you previously did a responsive redesign back in 2011 that was a retrofit of your desktop site, and then this most recent relaunch is a complete bottom-up responsive redesign. Can you talk a little bit about how responsive has worked out for you over the last few years and what led you to relaunch the site today?

Eoin:

Sure. So, Moosejaw has always been pretty much at the leading edge of mobile commerce. We actually launched our first mobile site back in 2006 for a WAP phone, pretty rudimentary stuff. And then we had more of a smartphone version in 2009, so we’ve been kind of at this for a while. And then really in 2011 responsive wasn’t even much of a thing—at least amongst ecommerce sites—and as far as we know, nobody in the top-500 internet retailer sites was using responsive. So, it’s not like we read an article and said, “We should go responsive.”

We’re seeing conversion rates on mobile increase fifty percent since we relaunched with the bottom-up approach.

It was actually just a solution to a problem that we had. We had this mobile site, and then we would hand off to our main site for checkout, and it was a really awkward experience from the consumer’s perspective, going from a mobile optimized experience to that desktop experience. So we started down the path of, “Well, how do we optimize that handoff so that the cart looks like it’s mobile optimized?” And so that was the start of the process, and then eventually from there, within a few months, we made it totally responsive.

The challenge then became, in the retrofit obviously we were rather limited because it was placed on top of an existing site, limited in what we could do. Steve can talk more to the technical details of it, but with the new site, from a ground-up perspective, it’s much more optimized and we’re seeing conversion rates on mobile increase fifty percent since we relaunched with the bottom-up approach.

We’re committed to mobile simply because that’s where our customer is going. We’re seeing mobile traffic increase anywhere from seventy to one hundred percent year over year.

Karen:

Let me follow up on that and ask how you see the difference between what mobile users and what desktop users might need. One of the reasons that I ask that is that when you survey the industry data around how people use their smartphones, one of the things that kind of sticks out is that conversion rates on mobile tend to be very low. Like, I’ve seen data that says one percent or less than one percent, compared to eight to ten percent or even higher on tablet and desktop. Can you talk about why you’re so committed to mobile, and do you think smartphone or mobile users need something different from desktop users?

Eoin:

We’re committed to mobile simply because that’s where our customer is going. We’re seeing mobile traffic increase anywhere from seventy to one hundred percent year over year. More and more customers are going to mobile and so we need to make sure that that is an optimized experience for that customer. And our conversion rates since launching, they’re indexing to our desktop at about fifty percent, which from talking to other folks in the industry, that’s pretty high. Most people are in the maybe thirty to forty percent conversion compared to desktop. So, that’s definitely moving in the right direction.

You can’t just accept that mobile conversion is poorer than desktop conversion and then just that’s the way it is; you really do have to continually optimize for it.

I was just at a retreat on this and one of the questions that people asked was, “Well, you know, will mobile conversion ever really approach desktop conversion? If our mobile conversion kind of stinks, should we really be that worried about it? Is it just the nature of the beast?” What I would argue is, no, you can’t just accept that mobile conversion is poorer than desktop conversion and then just that’s the way it is; you really do have to continually optimize for it. Customers are, more and more, using their mobile device as they would a desktop device. We’re long past the days where consumers are really concerned about buying on mobile. I think the limiting factors on mobile now are speed and what we can do with that, and then being able to present all the information that the customer needs to make their decision. So those are I think two of the big aspects to getting mobile conversion to a good place.

I don’t think we’ll ever fully approach desktop conversion rates on mobile, but I still think there’s quite a bit of the gap that we can make up through faster, better experiences.

The other piece is that there is a certain percentage of customers who have a lower purchase intent on mobile. So what I mean by that is on a desktop you’re more directed in terms of somebody is getting onto your site and they’re actually looking to buy something right that minute and it’s a matter of whether you’re going to be the right solution for them or not. Whereas quite a bit of the time maybe on mobile, those people are really never intending to actually make a purchase in that session. They’re just researching, they’re out with friends, they’re just looking things up. So, I don’t think we’ll ever fully approach desktop conversion rates on mobile, but I still think there’s quite a bit of the gap that we can make up through faster, better experiences.

What we did was we actually took every single element on the page and we said, “Okay, is this piece absolutely necessary?”

Ethan:

That’s brilliant, Eoin. I’d like to follow up just on one of those key points that you made, which is obviously performance as a key part of designing for the web, but the other thing you mentioned was presenting the user with the relative information that’s critical to them at that point of sale. As you translated from this responsive retrofit to this full-on responsive redesign, how did you make decisions about the information to present to users on those smaller screens? What kind of information did you keep, what did you get rid of, and what was the process for digging into that?

Eoin:

Well, so for us it really actually started with an overall site redesign. It was interesting, we had somebody that we just hired who’s more on the user experience side, and in the interview process we asked him to give his critique of our product display page. And the way he described it was “Very cluttered and busy. It looks like scope creep.” It was an interesting view because he was absolutely right. The site basically had evolved a lot, but it was over an eight-year period, and so things get added and you just don’t take things away; every new piece seems like a good idea at the time but it all comes together and there’s a lot there and it’s not necessarily that cohesive.

So, what we did was we actually took every single element on the page and we said, “Okay, is this piece absolutely necessary?” Is it necessary at this point in the page—top, middle, below-the-fold, etc.? Is there a more elegant way to say it? Can we replace it with an icon? If we’re saying “sign-in here,” do we really need the “here”? Every word, every letter, what can we do without?

The conversation was not, “What do we take away?” but more “How do we present that information where it’s accessible without distracting and overtaking the page?”

And then visually, from a visual hierarchy perspective, what are the key things? Even if you have to have all thirty elements here on this product display page, what are the top three items that really should have a visual hierarchy than the other three? That process really led to what we feel is a much cleaner design.

And then within mobile, we didn’t want to take stuff away from the mobile user because I think that’s not what the mobile user wants. The mobile user today expects to have everything they can get on the main site, they just need that information optimized in a way that makes it easy to get to the stuff they need right away and then the other elements are further down the page or can be accessed through menus and through other pieces that are rolled up. So really that was more of, the conversation was not, “What do we take away?” but more “How do we present that information where it’s accessible without distracting and overtaking the page?”

Karen:

My ears kind of perked up when you mentioned scope for this project. Can you talk about how you plan and budget for a large-scale initiative like this—especially having done a retrofit in the past, maybe you can speak to how the scoping and the budgeting for this might have compared with previous efforts?

Eoin:

Well, since this was a full-on redesign really—I mean, while it was part of a migration from IBM WebSphere Commerce V6 to V7, we really did use very little of the code from the prior version. Steve, was there a percentage that we used, or was it really zero percent?

It was a good three months of requirements gathering and creating user stories, and wireframes, and a lot of planning went into it.

Steve:

We tried to use as much as we possibly could, but there was probably around twenty-five percent that we were able to keep. There were some compatibility issues from V6 to V7, and there was a lot of noise in the code, to be honest, just from past projects and there was a lot of stuff that we cleaned up as a result of this project.

Eoin:

For all intents and purposes, it was a new site build, and so the scoping was much, much more in-depth, and even the design piece of it was. We started the project in, I want to say July of last year, and really the coding didn’t start until months later after all of the requirements definition; there were a lot of back-end pieces that were done and new environments being set up, and some of the piping, so to speak. But the real coding didn’t start until, what Steve, probably three months after, at least?

Steve:

Yeah, it was a good three months of requirements gathering and creating user stories, and wireframes, and a lot of planning went into it.

We basically built the entire site in a prototype that you could interact with, and that was really helpful for business users and just from an IT perspective.

Ethan:

Steve, maybe you could tell me a little bit more about when the work actually started from your standpoint. Like, how did you collaborate with the rest of the team? Were you sort of producing off of PSDs or comps, or were you just doing more prototyping? Just tell me a little bit more about how the site actually came into being.

Steve:

So we started out with a wireframing tool called EngageUX, and that was a really useful tool because we basically built the entire site in a prototype that you could interact with, and that was really helpful for business users and just from an IT perspective because we kind of got a base layer of what we were really doing and how we could improve some of the layouts and make sure that we had relevant information in certain spots. And then after the wireframing, which was a good month or two, we moved into PSDs and we worked directly off of the PSDs, kind of making it accurate and making sure that we were doing the high fidelity comparison, making sure that everything measured up right. We did some user testing, we tried to open it up to as many people as possible, and we got feedback throughout the entire project.

Moosejaw, we have an internal team. We’re kind of a small, really agile team, so that really helped us a lot because we were able to incorporate a lot of feedback right away, and we leave our development environment open to the rest of the company so that people can see progress as we are moving forward. A lot of people were able to give feedback and see exactly what we were doing in realtime, which was a cool way of doing this development.

We did a few 180s, like things where we really thought we wanted to go down this road and then, through looking at analytics and through looking at user feedback, we decided that that wasn’t the way to go.

Karen:

Can you say a little bit more about how that collaboration process worked? So, when people are commenting on prototypes or giving feedback at different breakpoints, did it change the way that you had to integrate their comments with the work in progress?

Steve:

I mean, I think any feedback affects the way that you code something. We had a comment section in the EngageUX tool and we would work with that, and people would suggest changes, and we would kind of go through a committee where would they would decide what was important, what was relevant, and what actually needed changing. We had some UI experts look at things. We did a few 180s, like things where we really thought we wanted to go down this road and then, through looking at analytics and through looking at user feedback, we decided that that wasn’t the way to go. And that did cause some major changes to the way that we approach things, specifically on the PDP, some things with the product images or placement of elements that were third-party integration things, like true fit and things like that; moving them around and making sure that they were in the best position so the user found them easy to use but also it didn’t overtake the page with messaging that wasn’t exactly what we were looking for in that section.

One of the things that helped us be successful here was we do have a good internal team here and the design was driven actually more internally.

Eoin:

Right, and I think one of the things that helped us be successful here was we do have a good internal team here and the design was driven actually more internally. So, there wasn’t an outside web design agency that was hired. But I think one of the helpful pieces in the process was we go it to a certain level where we thought we had basically mockups of all the key pages, and these were in Photoshop at this point, and then we went out to a heuristic expert and we just had him basically, offline, walk through the paper version of the site. Just having that outside view was really very helpful just in terms of, “Hey, have you thought of this? Have you thought of this? Here’s what I expect happens as we move from one to the other. That doesn’t seem to hang together.”

I think some of the key things that we added—like we added color swatching on the… well, we were going to have color swatches but they weren’t going to be real swatches, they were just going to be like, “Here’s a standard green color, a standard red color, etc.” And then we came back with actual color thumbnails, and I think that’s had a big impact for the conversion of that search page because people can really see what our color range is. But those sorts of thoughts I think really helped to move the overall design along. And then once we had more of a full working prototype, we brought that group back in again to take another look to see if it delivered on the expectations that we had set with them.

With any web project, you have to make the call as to what percent complete is enough to really get this thing live because you could spend months and years on the last 100 items.

Ethan:

I realize you guys have just launched this new site, so this might be a little early to ask, but I’m always curious to know if that feedback and review process happens after the site is actually live. Have there been any elements of the responsive design that you’ve had to rework since launch? And if so, why?

Eoin:

There’s some elements that we haven’t gotten in yet. So, for example, on our product page we have these really beautiful images, they’re probably seventy percent bigger than they were before, and you can scroll between alternate views and colors, so it’s a big content play. In tablet and phone, you should be able to swipe those, and that’s not something that we could get in for launch, but that’s definitely a part of the plan. And so, I think there’s a number of things like that.

With any web project, you have to make the call as to what percent complete is enough to really get this thing live because you could spend months and years on the last 100 items, because there will always be 100 items that still need to be done. So for us, those are things where we said, “Okay, we need to get this thing live now,” which was the end of June, so that we have bake-in time before the critical fourth quarter to really make sure that this thing works. So, I think there’s definitely more stuff to be done from a responsive perspective. I don’t know Steve, was there anything that we changed dramatically since launch?

We’ve been mostly focused on performance and making sure things are working optimally.

Steve:

We haven’t really done a lot of dramatic changes since launch. We’ve been mostly focused on performance and making sure things are working optimally. IT is very busy right now; we have a lot of open assignments, new features that we want to add in. I think the best thing about working on a website like this is that it’s never really done, there’s always more that we can do to improve it and there’s always more that we can test. We’ve been testing a lot of user engagement things with A/B testing, seeing kind of what works, and some of those tests will be coded into the main site soon because they’ve been proven to be effective. Yeah, we haven’t really done any major overhauls of design, but we’re tweaking the design constantly.

That has really helped us to cut our load time significantly in mobile, about thirty percent, and that I think is a big driver of some of those conversion gains.

Eoin:

And the other key success factor with our mobile site, and I think something that shouldn’t be overlooked, is the speed aspect. When we first started down the responsive track four years ago, I think that was probably the biggest challenge, was that, yes, it’s great that we have this responsive site that is optimized for the mobile user and lets people get to the page that they want in the right way, but the challenge was it was slow because even though we’re maybe showing you a smaller image or not all of the content or what have you, all that stuff is still loading in the background. And so we actually work with a company called Yottaa that actually helps to really optimize how the pages are loaded across different devices, and not only how they’re loaded but the order in which the items are loaded. And then if the items aren’t needed, for example in the mobile experience, they don’t get loaded. So, that has really helped us to cut our load time significantly in mobile, about thirty percent, and that I think is a big driver of some of those conversion gains.

Really, there was just a ton of content that the people were asking for.

Karen:

Can I ask a quick question about how you might have changed the way you merchandize your products? Did you have to rewrite product descriptions or change the taxonomy or the categories with which people filter so that it would work well at smaller screen sizes?

Eoin:

It wasn’t so much about the different screen sizes. One of the things that we did is we got into this project about a year ago—we do surveys of our customers three times a year, and so I think one of the best questions we ever asked our customers was, “If you came to Moosejaw.com intending to buy from us and didn’t, why?” You could check the boxes of whatever the options were, but then there was a “tell us more” open text field, and there were just so many good insights. It was probably 16,000 answers that we got to that question. A lot of them started to coalesce around certain things—and certainly the mobile experience and speed was one of the challenges—but another one was content.

You need to have all the content for that consumer to be able to make their purchase decision on that product page without going to research elsewhere (or on your competition.)

We sell technical hiking gear, camping gear, climbing, high-end technical jackets, so people really wanted specs. And we sell a lot of clothing and people didn’t just want to see the front of the jacket, they wanted to see all sides of the jacket and they wanted to see it on a model, not just on some mannequin or flat. Really, there was just a ton of content that the people were asking for. We had, up to a point, said “Well, Moosejaw is about the fun and the experience and what have you. And the content thing—there are maybe other sites that are better at that.” We just realized, you know what, that’s a cop-out. You need to have all the content for that consumer to be able to make their purchase decision on that product page without going to research elsewhere (or on your competition.)

Improving our search faceting experience, that’s been a big driver and that’s actually helping us to decrease the number of searches per session.

That’s really what we looked to do, and part of that also was improving our search faceting experience. So in the past on the prior site, basically whether you were looking at a jacket or a tent, your filtering options on the search page were basically the same. It was category, brand, price, size, color, etc.—so pretty generic stuff. And now on the new site, all of the facets or the filters for different categories, you have different things. So for a jacket, “Do I want it to have a hood or not? Do I need it to be waterproof? Do I want it to be insulated or not? Do I want it to have pit zips?” Whereas with a tent, I’m filtering by how many people does it need to fit, what sort of floor area, “Do I need it for three seasons or four seasons?” And so I think that’s been a big driver and that’s actually helping us to decrease the number of searches per session. People are finding what they need faster without having to go through the rest of the navigation or search on one thing and then go back and search again. I think that’s been a big help for us. But that’s also been a ton of work, just in terms of getting all of that content, all of those specifications, all of that data when we have 25,000 products and over 100,000 SKUs, it’s quite an undertaking to get all of that stuff together.

We define support as one percent of users coming to the site have that device or browser, so that’s obviously a lot of devices.

Ethan:

It’s been really exciting to hear just how much of a focus performance is for you guys at Moosejaw. The thing I like about that is it takes into account not just the aesthetics of the layout but just how the device actually feels when the user is actually working with it. I guess the other part of that that a lot of organizations struggle with is browser support. How do you actually define what constitutes a good experience on all the different devices and browsers we’re actually working with?

So Steve, I guess I’d like to hear a little bit from you in terms of producing it and building this responsive design. Has your QA process changed? How are you conducting device testing? Is that something that is an area of interest for you?

Steve:

It’s an area of a lot of interest and concern from our perspective. We define support as one percent of users coming to the site have that device or browser, so that’s obviously a lot of devices. We have changed QA processes a lot. In the past, we used a mixture of emulation and sizing software to kind of test what it would be like, but one of the big pushes we did for this newest migration was we got a ton of devices. Our QA person has, like, twenty devices on his desk right now and he just goes through each one and we make sure that they’re optimized at every breakpoint that we possibly can.

The best thing about responsive is that between the breakpoints, if you make it correctly, it should work regardless of what device you’re using. But that doesn’t mean we shouldn’t test on those.

The best thing about responsive is that between the breakpoints, if you make it correctly, it should work regardless of what device you’re using. But that doesn’t mean we shouldn’t test on those. So we have some automated software that we run, kind of testing whether or not elements are usable and visible at certain breakpoints, and then we also manually test them on specific devices. So that was a big change for us rather than using emulation because it involved a lot more getting your hands dirty and going through—we do a week or so where each developer would take a different browser for that day and go through the entire process—the navigation, add to cart, checkout—and make sure that everything was optimized, and that was obviously a lot of work. It’s really rewarding work though because we have that peace of mind that we’re going to be solid at almost any breakpoint. Yeah, one percent is kind of an aggressive goal for that, but I think it’s one that’s going to help us out in the future a lot because we really are working hard to make our site as responsive as possible and be usable for as many users as possible.

There’s trade-offs, right? We weren’t going to invest the hundreds of hours to make it perfect in IE9.

Eoin:

When we launched, we actually ended up having some issues with IE9 because it had been sort of on the bubble of the one percent and we hadn’t really tested it. Lo and behold, we have some problems. When we really started to dig into it, we realized to actually make the site work perfectly in IE9 would have been a major undertaking. So, there’s trade-offs, right? At the end of the day, with that, we said, “Well, the site should at least be functional.” So there’s the difference between having the site work perfectly and beautifully in every single device/browser combination vs. “Here’s a browser that’s obviously on its way out in terms of usage, but we still have customers so they at least need to be able to check out.” But we weren’t going to invest the hundreds of hours to make it perfect in IE9.

I really do think that responsive is the correct approach. You need to have really one web experience that’s just optimized for different users.

Karen:

This has been so interesting listening to you. I think you have amazing perspective on what it takes to do responsive right, especially having done it for so many years. I’d love to hear from both of you: do you have any advice for other people out there, perhaps other retailers that are considering embarking on a responsive redesign?

Eoin:

Yes. First of all, I really do think that responsive is the correct approach and that was why we did it four years ago. Back then, consumers many times would get an email and that email would be designed for desktop, and more and more were opening them on their phones, but then when they’d click through on a coupon or a promotion which on the desktop would have taken them to a product page, or a search page, or a landing page, on the mobile site they just got dumped on the home page. And oh, by the way, the home page wasn’t being updated. And then even if they could get to the part that they wanted, the coupon code that was included in the desktop version didn’t work on the mobile site because it hadn’t been updated either. So, it was just a horrible experience and that was really what drove us to say responsive was where you need to be, because you need to have really one web experience that’s just optimized for different users.

You kind of have to do it from the ground up. It’s very hard to do well when you’re doing it retroactively with an existing site.

So my first piece of advice would be do it; do responsive design. But my second piece of advice would be: you kind of have to do it from the ground up. You know, we were early when we did it in 2011, but we were then left behind by sites that did it from the ground up. It’s very hard to do well when you’re doing it retroactively with an existing site; with all of the table structures that you have in place, it’s tough. We’d have conversations with Steve about how we’d want something to be and he’d be tearing his hair out because he wasn’t set up for success. So I think if you’re going to embrace responsive, you have to pretty much embrace more of a ground-up approach if you really want to see success.

Don’t be afraid to throw out designs. If you look at the very first design that we had available and where the site is right now, they’re very different, and I think that our site is a lot better because of it.

Steve:

I 100% agree with Eoin, a ground-up approach, just from working with both code bases. Adding things to an existing site, while it can work, it’s like Frankenstein’s website. It gets really complicated really quick because there’s all sorts of things that you don’t account for when you’re initially making it, and then new things come up and you’ve got to add them. I think a ground-up approach is the best way to go.

I also would say don’t rush the development for it. We’ve been very lucky with our business user team. We came to them a few times and we were like, “We really want to make sure this is right and we want to make sure we’re putting out a quality product and we really need some more time to work on this,” and they’ve been great with that. Making sure that quality was the top concern with what we were putting out and what we were putting our name on I think is really important.

I would also say don’t be afraid to throw out designs. If you look at the very first design that we had available and where the site is right now, they’re very different, and I think that our site is a lot better because of it. You get attached to things, you think they’re really cool, and then through user testing or through user stories and the way that people use the site it just isn’t exactly what you thought it was. I think it’s really important to have that flexibility to be able to say, “This thing is important, and we really like this thing, but something else is more important and something else would be better for the user,” to make sure that, at the end of the day, we’re really giving our users exactly what they need to have a really high quality experience on our site.

Uncluttered clean design works really well on desktop as it does on mobile. Mobile just forces you to maybe take it that one step further to be optimized to a small screen size.

Eoin:

Right. I think the other thing is that you do have to… doing responsive well really does require that you have to have a clean design. Some people talk about, “Well, I design for mobile first then work on the desktop.” I’m not sure I fully agree with that. I think for most people still, a vast majority of the revenue is from the desktop. But it does talk to a certain degree of discipline around making sure that your design is clean, that you’ve removed as much clutter as possible, because quite frankly, uncluttered clean design works really well on desktop as it does on mobile. Mobile just forces you to maybe take it that one step further to be optimized to a small screen size, but a lot of the same principles apply in terms of making just for good overall web design.

Ethan:

I could not have said it better myself. Eoin, Steve, this has been a wonderful, wonderful episode. Thank you so much for sitting down with Karen and I. We can’t wait to see what you guys produce next.

Eoin:

Thanks for having us.

Steve:

Thanks. It’s been a pleasure.

Karen:

Thanks to everyone for listening to this episode of a responsive web design podcast. Thanks also to our sponsor, Harvest. Go to getharvest.com and start tracking your time painlessly.

If your company wants to go responsive but you need help getting started, we offer a two-day onsite workshop to help you make it happen. We also offer these workshops to the public, so please go to responsivewebdesign.com and see when we’ll be in a city near you.

If you want even more from us, you can sign up for our newsletter, subscribe to this podcast, and read full transcripts of every podcast episode at responsivewebdesign.com.

Thanks for listening, and we’ll be back next week.