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 personally have whipped myself into soft frothy peaks, I am so excited that we have America’s Test Kitchen here! We’re here today with Kate Tetreault and Michal Skrzypek. Welcome.

Michal:

Hey, nice to be here.

Kate:

Hi guys!

Karen:

We’re so happy to have you!

Ethan:

But before we dive in, a few words about our sponsor. I couldn’t be happier to have Gather Content back as a sponsor on the podcast. You see, Gather Content is a content collaboration platform. It helps teams plan, organize, and produce all their web content in one place. They provide structured templates and simple workflows to make collaboration and production easy without the shuffling around of Word documents and unnecessary emails. Centralizing the editorial process will make approval of content easy, so everyone knows what they’re responsible for and when they’re responsible for it. And what’s more, Gather Content has recently published a free online guide to Content Strategy for Website Projects, which they’ve written for all the people who want to make smarter, content-led decisions on their designs. So every responsive design, I believe, benefits from a content-first approach. But as Gather Content’s guide says, that doesn’t mean waiting until all the content is written. Instead, it means considering and thinking about content at every single stage of your project. And Gather Content’s guide can help you do just that. So whether you’re working in an agency on client websites or maybe you’re working on an in-house team, Gather Content’s guide should help you more effectively contribute to your digital projects. You can read it online for free at gathercontent.com/RWD, or check out Gather Content’s products at gathercontent.com.

Karen:

So, I would love to first just have you introduce yourselves and please tell us a little bit about your role at America’s Test Kitchen. Kate, do you want to go first?

Kate:

Yeah, sure. So, Mike and I make up the UX team at America’s Test Kitchen, which is the most watched cooking show on public television and it’s also a parent company for a whole bunch of other great cooking-related brands, including Cook’s Illustrated and Cook’s Country, and America’s Test Kitchen Cooking School, and then also more recently, Cook’s Science. And basically what happens at ATK is we have three dozen full-time cooks who are spending a bajillion hours researching and testing a whole bunch of different combinations of ingredients and techniques and equipment basically just to develop really easy foolproof recipes for everybody’s favorite foods. So what we do is we’re sort of part of the digital team, we’ve been hard at work basically helping the company go responsive sort of slowly but surely, redesigning each one of our digital properties, and Mike and I have really been at the heart of a lot of that work. And recently we launched the responsive redesign of americastestkitchen.com, really sort of aiming to highlight the TV show’s mission, providing aspiring home cooks with everything that they need to be successful in the kitchen basically, no matter where they’re starting, if they’re a beginner or if they’re sort of already a little bit of a pro.

Karen:

And Michal, how about you?

Michal:

Yeah, so I’m the second half of the UX team here at America’s Test Kitchen. And like Kate was saying, basically we tag team on a lot, if not the majority, of the projects that we have going on here, and really strive to kind of just inject UX into everything that we do and make sure that everything we’re doing, we’re thinking of the people that are actually going to be using the products that we’re making, and kind of thinking of their stories and what it is that they do with our products, and making sure that we just ground ourselves in all of that as we go forth and redesign our whole suite of digital properties. So yeah, we’ve been working around January or so on the new americastestkitchen.com and working to just make it a much more modern and responsive site and really go ahead and tell the story of the test kitchen and just highlight the TV show’s mission of providing aspiring home cooks with absolutely anything and everything they’d need to be successful in the kitchen.

Karen:

Those are all my favorite things, like right there all in one little package.

Kate:

[laughs]

Michal:

[laughs]

One of the things that we both love in particular about this team and this company is that the experimental and try, try, try again nature of the actual test kitchen is definitely something that I think extends out into other departments of the company.

Karen:

So, I’d be curious to hear you tell a little of the origin story around your decision to go responsive. So, were there any questions or concerns from the rest of the organization about responsive as a methodology?

Michal:

Thankfully there weren’t any real issues convincing stakeholders that responsive is the way to go, which we’re super fortunate because we know that’s often a battle that lots of other people have to fight and that’s something that both of us have kind of grappled with before. So, it was nice to not have to go through that process with this project.

That said, there definitely was some getting used to working responsively. A lot of our team was new with this project, and the whole digital team in general is only about two years old or so, so a lot of it was still just kind of figuring out how to work together. And coming off of previous projects where there were things that could’ve been better, we were really trying to find the best way to work together. That being said, a lot of what we dealt with was, while we took a mobile-first approach to designing the site, not everyone was super used to starting from the mobile perspective. A lot of it came down to having to really show the stakeholders the entire experience, like across mobile, tablet, and desktop, and really give them a holistic view of what it is that we were doing to get everyone on board and make sure everyone is understanding everything that’s happening.

Anything you want to add to that, Kate?

Kate:

No, I think that’s definitely a good assessment of it. I think a lot of it ended up being mobile-first for us, but that meant we sort of had to socialize a lot of it. I think there was a little more context that we had to sort of seed with the rest of the team. And I think totally right to that, coming hot on the heels of a previous responsive redesign, cooksillustrated.com, it was a lot of really great learnings from that project that carried over to this project. I think one of the things that we both love in particular about this team and this company is that the experimental and try, try, try again nature of the actual test kitchen is definitely something that I think extends out into other departments of the company. So we were really lucky that we could say, “Hey, we tried this thing last time. What if we tried something new this time?” and pretty much everybody is always like, “Alright cool, let’s give it a go.” So there were a lot of different process things that we tried with this project that were varied from things we’ve done in the past.

Michal:

Yeah, and I think neither of us have been in a situation before where the thing the company does is so reflective of the design process in general. So, a lot of it was just looking towards what everyone in the kitchen is doing and how they’re approaching developing recipes and researching equipment and ingredients and stuff, and really trying to apply that same kind of mentality to our design process in order to make the site responsive and have the team work together as effectively and efficiently as possible.

Karen:

Let me just do a quick follow-up and ask a little bit about how you conceive of mobile users or mobile tasks. And I ask that explicitly because I do a lot of cooking and I often have a really multi-device strategy for looking up recipes on my desktop, and then I actually have a kitchen iPad mounted to the wall…

Kate:

Nice! [laughs]

What we’ve really seen from past research and the kinds of things we hear from our customers on social and via feedback is that people will use the products that we have and the content that we create anywhere they can, on any device, in any situation.

Karen:

Yeah, it’s pretty great. But you know, sometimes I have my phone in the kitchen too because I set a timer on it. So, I’d be interested to know how you thought about whether people conducted different tasks or have different scenarios of use for mobile or desktop.

Michal:

Yeah, so basically we’ve done a bunch of research before this project even started, and a lot of what we saw is that, for one, people have a lot of different and very unique setups for how they approach cooking in the kitchen, ranging from just printing out anything and everything they can find and filing it away in their own intricate filing system, to referencing things on their phone, to bringing their tablet into the kitchen, to just using their desktop or laptop directly. So, what we’ve really seen from past research and the kinds of things we hear from our customers on social and via feedback is that people will use the products that we have and the content that we create anywhere they can, on any device, in any situation.

Kate:

Yeah. And I think something that is interesting too, and probably really just a testament to the quality of the content that we’re working with, is just that despite americastestkitchen.com not having been a responsive site in the past, still more than almost fifty percent of the traffic that we had to the site was coming from a phone or a tablet. So despite the fact that it was a big site miniaturized, people were still working within those unfortunate constraints to get to the content. We’re lucky in that we have a very driven, passionate audience, and we just really wanted to make sure that all of the same things that they were looking for would be more easily accessible to them.

Ethan:

You both mentioned that you’ve taken a number of different sites responsive now at this point. Could you tell me a little bit about the design process specifically for America’s Test Kitchen? I’m just curious to know if it managed to changed when you were actually setting up this new site. Tell me a little bit about how you started the work.

Michal:

Oh yeah, so the design process most certainly changed. So, basically the way it worked is I started about a year ago or so and kind of came in halfway through of the responsive design of one of our other sites, cooksillustrated.com, and then Kate, you came in at the start of this year, correct?

Kate:

Yeah, I started basically right when this project started in January.

One of the big things that came up when we talked to people in interviews was just, “Let’s try to minimize surprises.” That really sort of formed a lot of our process moving forward.

Michal:

Yeah, so I came in on the tail end of our last project, and the process there was significantly different. The digital team in general was even newer at that point, it was pretty much less than a year old, so we were really kind of still trying to grapple with how should we work together, what are some best practices we should follow; we were still making sure we had all the right people on our team. And so coming at this responsive redesign, we kind of had a good inkling of things that worked really great last time and things that just could’ve been a lot better. So, Kate and I really spent a lot of time trying to make the process of working together a lot better and a lot smoother for everyone involved on the team, and that involved just a lot of collaboration. And a lot of it came down to communication, making sure that everyone on the team was aware of what was happening, why it was happening, when it was going to happen, and just making sure that the right people were in the loop and that no one was left in the dark.

Kate:

Yeah, and we basically started by trying to do a little meta UX. So, we just sort of went around and we did stakeholder interviews for everybody who was involved in the previous project who were continuing to be involved in the new project, and did kind of a tiny little retrospective about what worked, what didn’t work, what we can do better, and then sort of compiled all of that research into a document that we shared at the kickoff of the new project. So, it was sort of a really nice way to make sure that everybody was not only aligned on the key goals but also socialized a lot of that. So engineering could maybe hear something that marketing had raised as a requirement, and they could be like, “Oh whoa, hey, that’s not what I expected. Let’s pair and figure out how we can resolve whatever this flag is.”

And we also introduced this idea—at least new to our team—of having these much more collaborative workshops where we had key stakeholders from each different group, whether that was engineering or marketing or web editorial, and having everybody get together and sort of doing a little bit of like a retrospective/prospective, basically saying that a small part of the project, whether that was a certain user flow or a certain goal that we wanted to meet, how could we break that down for what are things that are requirements that we need to do now. What are things that we want to do for the vision state, and what are things that we never, under any circumstances, want to do at all, whether that’s for the way the product’s shaped up or whether that’s for our actual process that we use to get there. That was really nice for helping us figure out what are we totally aligned on, what are flags that we’re glad that we’re discovering now rather than in the future. I think one of the big things that came up when we talked to people in interviews was just, “Let’s try to minimize surprises.” [laughs] That really sort of formed a lot of our process moving forward.

Michal:

Yeah, and a lot of it also came down to—our team isn’t tiny, but it is relatively small when you look at the amount of things that we have going on on a daily basis and the amount of projects that we have going on. And so a lot of it came down to making sure that no one was assuming that one person knew about something that was talked about in another meeting, and making sure that everyone was aligned as to what it is that we’re doing and how we’re going to do it and what our vision state is going forward. And again, making sure that we were communicating both what we were doing and what we were hearing from everyone else to the whole team just so everyone’s on the same page, everyone’s on board, and like Kate said, minimize surprises as much as possible.

Ethan:

I think that’s great. I really love that idea of these workshops bringing different parts of the organization together. Tell me a little bit more about how you got up to that point. Specifically, what were you actually looking at when you were creating the design internally? Do you have a fairly mock-up driven process or are you doing a lot of prototyping internally? How are you conducting reviews as a digital team?

Michal:

So, that process also changed substantially with this redesign. With our previous project, we were relying a lot on fully designed comps that were then discussed with the engineering team, and then stakeholders would flag any issues that they thought might prevent us from releasing the site on time.

With this project, we took a completely different approach in that we really started as low fidelity as possible, and I mean that in as true of the sense as possible, because we were relying heavily on paper prototypes and just really DIY guerrilla whiteboard sketches, to the point where we were able to iterate super quickly and get our ideas down and document them and share them with the rest of the team, and make sure that if there was an issue that came up and if we heard from the engineering team that, “Due to whatever constraints we’re dealing with, something like this isn’t going to be possible within our allotted timeframe”… Hearing that, we were able to quickly go back to the drawing board and work, the two of us and also our design team and our engineers and marketing and product and everyone else, to make sure that we could come up with an alternate solution that simultaneously satisfied all the requirements that we had to fulfill.

We didn’t have to spend as much time in these elaborate review meetings, and there was a lot less socialization because more of it was baked into the process of creating the thing.

Kate:

Yeah, basically we looked at a lot of the UX deliverables more as workshop facilitation tools. So in addition to after we had the big stakeholder requirement defining, issue flagging workshop, there was a smaller team workshop just with a representative of development, UX team, and visual design team, where we basically just took one flow or a set of screens and whiteboarded that out. So what was really nice about that was we were really easily able to—again, in the spirit of avoiding surprises—have development come in and say, “Hey, actually, we know you want to do this swirly carousel thing. That’s going to hurt performance. Let’s just limit to showing three images in this particular group.” A lot of those things were able to happen really quickly, and it also meant that we didn’t have to spend as much time in these elaborate review meetings, and there was a lot less socialization because more of it was baked into the process of creating the thing.

Michal:

Yeah, and on top of that, instead of spending a lot of time working on intricate wireframes that go into really fine detail that may or may not end up in the actual final product, we were able to spend a lot of our time just being with our team and discussing issues that came up with them, and discussing goals and how we were going to fulfill those goals.

We really started with I think it was just grey boxes and mapping out, “This template type will have this content here, below it will have this type of content, and you’d have a sidebar with this content,” and we would present these main core templates to our engineering team and go over it with them as well as members of the visual design team and product and make sure that everyone was on board with how the pages were structured.

Only then did we kind of dive in a level deeper and were like, “Okay, so this grey box is going to be kind of the core recipe detail section, so we’re going to have an ingredients column here, we’re going to have steps over on this side,” and while we were still kind of in that very low-fi phase, we sketched out how those boxes would transform across different breakpoints. And starting at such a baseline, low fidelity level really helped us figure out how things were actually going to flow between breakpoints and not have to worry about, “Well, is this line going to extend X amount of pixels?” or, “What is going to happen to this very intricate element?” We could just figure out, “This is how this content is going to flow and this is how it’s going to be structured,” and then not until much further into the process did we start really focusing on actual UI elements and working with our visual design team to come up with real live prototypes.

A lot of it came down to just looking at the way our content was structured in our CMS and in the back-end.

Karen:

Let me follow up on that and ask how this responsive process might have changed the editorial direction or changed the content that you were creating. So, we talk to some organizations that a responsive redesign is really just a design process, it’s about making a site that works on all devices. We talk to other organizations where it actually changes the substance or the composition or the makeup of the editorial direction. I don’t necessarily mean the substance of the recipes themselves, but rather the rest of the editorial strategy for the site. Can you talk about how that might’ve worked for you all?

Kate:

Yeah, for sure. I think one of the goals going into the project was be able to set the stage for a lot more different kinds of fresh content on the site, and the sort of general scope of this part of the project, at least this phase of it, was taking existing content and improving the experience around it. But what we really wanted to do, knowing that web editorial has all of these great ideas for different kinds of content that they want to put out there, even if we weren’t able to create all of that and then launch with that for this particular launch, UX basically had to think about let’s make sure that we design a system that can accommodate that. I guess this was sort of a loose interpretation of…

Michal:

Atomic design, yes. Brad Frost.

Kate:

Yes. So, we sort of started with a loose interpretation of atomic design, and part of that was making sure, what are the different ways we have to tell stories, both small and large? We really wanted to make sure that we had all of these pieces so that we were able to move into the phase of the project where we’re bringing a lot more content onto the site, and different sort of ways of curating that content, that we had the tools to be able to do it, and the expectation is set with the user that they know that, “This is the place that you look for new content; this is the place that you look for these kinds of stories,” even if we’re not actually able to deliver on those specific things in their final form just yet.

Michal:

Yeah, and a lot of it came down to just looking at the way our content was structured in our CMS and in the back-end. It wasn’t in a beautiful state of pristine organization when we started unfortunately, but we took a look at it and took a look at the relationships between content and tried to really straighten out how things are organized, and the hierarchy of content, and what’s prioritized, and making sure that we weren’t relying on any kind of hacky workarounds to really showcase our content. And so a lot of it, like Kate said, came down to laying the groundwork and the foundation for a lot of exciting things that are going to be happening down the line.

Another aspect of it was really moving the site towards the direction of it being less of a place to store content and an actual story and an actual experience. Because our show and all of our content and all of our brands have so much to share and there is such a deep story that flows throughout all of them, and listening to our customers and hearing what they have to say, it’s much more than just a cooking site, it’s much more than just a TV show. It really influences their entire life, and we wanted to take some of that and start to inject it throughout the site and thread together the story of the test kitchen bit by bit and really move the site towards, again, less of a content storage area and more of an actual cooking resource that people can use to learn how to cook and have really great experiences.

The schedule was structured basically to allow us two-plus weeks at the end just for QA. Other projects that I’ve worked on in other places, QA is the thing that happens if you have time at the end.

Ethan:

I’d love to hear a little bit more about your device support strategy for the new America’s Test Kitchen site. This is a big challenge for a lot of organizations; when they start moving beyond the desktop, it’s like, “Oh wait, we have all these phones and tablets and all of these other terrible things to now get our site and services on to?” How do you get a strategy in place for doing QA and testing across all these devices? How do you figure out which browsers are actually going to be able to access the site? Tell me a little bit about that.

Michal:

So, we relied heavily on just looking at our analytics data and seeing how people are accessing the site, and kind of right from the get-go we had a good understanding that the primary devices that our audience was using were iOS devices. So, people were using a lot of iPhones, specifically iPhone 5’s and a decent amount of iPhone 6’s, and then some older iPads. So, we knew that we could spend a lot of our time and energy making sure that the experience was really polished on this devices.

And regarding the actual QA process, it was very much a team effort, and towards the last few weeks of the project, our QA lead kind of spearheaded the QA process, and everyone got on board and just tested the site across various devices and breakpoints and OS’s, and really filed bugs pretty much nonstop for weeks to make sure that the experience was really as polished as it could possibly be for our core devices.

Kate:

Yeah. And I think one thing to note there too in terms of process is just the way the schedule was structured was basically to allow us two-plus weeks at the end just for QA. I feel like other projects that I’ve worked on in other places, QA is the thing that happens if you have time at the end. [laughs] So, it was really great to sort of say, “Hey, here’s going to be our ‘pencils down’ date and then we’re just going to focus on making sure that everything about that core experience is working great on the devices that we’re focusing on.” So, it was nice to not have a sort of frenzied mad rush at the end.

Michal:

Yeah, and also to that point, I think it was those last few weeks where we really got a sense of what it is that we created and how this experience feels, and so a lot of it was comparing it to our initial vision and being like, “Does this feel the way that we intended it to? If not, what are tweaks that we can make now while we still have some time before launch to push it more towards that direction? And what should we start focusing on post-launch to make sure that the site is really moving towards that vision state?”

Karen:

Let’s talk about, more broadly, how you measured the success of this responsive redesign. What kind of research or data or ongoing checks do you look at to know if the website is doing its job for you?

Michal:

Yeah, so at the start of the project when we were doing our stakeholder interviews, we identified some key metrics that we were hoping to improve by the time that our site had been live for a few weeks. And so, we spent a lot of our time post-launch looking at analytics data, and looking at those metrics, and seeing what the trends were week over week and month over month and how we were doing. The site has only been live for, what, like two, two and a half, three weeks, something like that? But we’ve already started to see a lot of positive trends and a lot of gradual improvements that are really going towards the direction that we were hoping to head in. On top of that, when we launched the site, we randomly surveyed fifteen percent of all site visitors, is that right?

Kate:

Yes.

Michal:

Yeah, and so we had a little survey that popped up in the middle of their experience to quickly gauge, “How does this experience compare to the one that you were previously used to? What was your goal when you came here and were you able to accomplish that?” And so, we started to see a lot of positive things from that and we were hearing that the vast majority of people, at the very least, thought that the site hadn’t gotten worse in any way, which is always wonderful to hear…

Kate:

[laughs]

Michal:

But a significant amount also commented that the site was either slightly or significantly better than before. So, it was nice to get that validation that the work that we’ve been doing is going towards the right direction. Kate, do you want to talk about the second half of that, the feedback survey?

Kate:

Yeah, sure. For launch, we sort of had that interruptive pop-up, which, no surprise, people do not like being interrupted. [laughs]

Michal:

No, they do not.

Kate:

So we sort of integrated less disruptive feedback survey placement on-site as well, and we have a whole bunch of feedback in there as well, which has been really helpful. Mike has been in there every day, going through, parsing stuff, putting together trends. And obviously a lot of the things that we’re hearing are things that we sort of already know, but it’s really great to have validation on those and to help us discover some new things that we may have missed.

Another really valuable tool for us has also been Hotjar. Right after launch, setting up a whole bunch of heatmaps and being able to go in and see, hey, what are people engaging with? What are they not engaging with? How far are they scrolling? Let’s go in and look at some sessions to actually see if somebody comes into search, what do they do next? Those kind of real time, how people are actually using the site, insights are always really, really great to have and such a nice companion to some of the more survey-related data as well.

Michal:

Yeah, and a lot of it came down to the fact that our timeline for this project was significantly shorter than that of our previous project. So for our last redesign, I think we had somewhere around nine months or so, or nine to twelve months. Whereas for this project, it was I believe six months that we had to get the new site live, and that was just because of a whole bunch of other things that were happening in the company at the same time. So, we were really kind of pressed on time, and so the amount of time that we were able to devote to just user research and talking with customers and really getting a deep understanding of what it is that they wanted from the site… We didn’t have quite as much time as we wanted to during the process…

Kate:

That’s always the case, isn’t it? There’s never enough time. [laughs]

Michal:

Yeah, there’s never enough time, but we made do with what we had by doing some internal testing as well as some guerrilla testing in the cafe across the street and stuff, which was a fun time. But getting this real live feedback pouring in, it really helped open everyone’s eyes to, “This is how our users are experiencing the site, this is how they’re feeling, this is the stuff that is really resonating with them, and this is the stuff that we can focus on going forward to really make sure that the experience is as great as it possibly can be for them.”

Ethan:

Well Kate, Mike, this has been a fantastic chat and I’ve learned a lot and I’m sure our listeners have, too. Before we let you go though, I’d love to hear if you have maybe one piece of advice for our listeners. Anybody who’s out there who’s about to start a responsive redesign, what’s one or two things that they should keep in mind that you’ve learned in redesigning America’s Test Kitchen?

Michal:

I think the biggest thing that we’ve learned from this project is just how valuable it is to work collaboratively as a team and make sure that you are constantly communicating with everyone throughout the entire process. This has been a pretty significant change from some of our previous workflows. And just seeing how much happier everyone is working together and being able to come together at more challenging times and address difficult problems and complex situations, it’s been significantly easier and much more rewarding working together as a group. And our final product, or the first iteration of our new site, feels a lot better than what we’ve done in the past, and I think we’re really starting to see that in some of the feedback that we’ve been getting and the metrics that we’ve been looking at.

Kate:

I feel like mine is sort of along the same lines, maybe with a more specific focus on thinking about the meta UX of your deliverables. Because I think so much of what was really beneficial for us about working in really low-fidelity deliverables in the beginning—allowed us to move really, really fast; it was great for people who were in the workshops. But then I think there was a little bit of a struggle in translating some of that to people that weren’t in the workshops. So, it’s easy obviously for us to just dump a whole bunch of photos of whiteboard sketches into a folder on a drive and share it out on Slack, but people are super busy, they’re not always going to have the time to look through each one of those. And to be totally honest too, a lot of times it’s one of those things in the moment where you look at the sketch when you’re in front of it and after you’ve had a conversation, you’re like, “Oh yeah, of course,” but for somebody who maybe wasn’t there, sometimes those things can be a little bit harder to read.

A big takeaway for us is that if you’re going to do low fidelity at the beginning—which I think we’ll continue to do for future projects—you need to put a little bit more thought into how you do eventually socialize that for people that weren’t immediately in the room. Whether that’s just a text list of, “Five things you should know coming out of the workshops, and here’s images if you want to look at them or not,” but just sort of being aware of the fact that our deliverables are helpful to us, but they really need to be readable to other people as well.

Michal:

We are so ingrained in everything that is happening with the project, and sometimes we just need to take a step back and realize that not everyone is sitting right there in our heads with us the whole time, and so not everything is going to make sense right away. So, we have to understand that everyone else has a lot of other stuff going on, and making sure that the stuff that we show them is super clear and that it’s super easy to understand what it is that we’re doing, why we did it, and basically the implications of all that.

Karen:

Well Kate, Mike, America’s Test Kitchen is one of my very favorite brands and one of my very favorite websites, and this conversation today I hope makes it clear to everybody why that’s true. Thank you so much for coming on the show.

Michal:

Thank you for having us.

Kate:

Yeah, thank you so much. We’re such big fans!

Ethan:

Thanks to everyone for listening to this episode of a Responsive Web Design podcast. And thanks also to our sponsor, GatherContent. Go to gathercontent.com and take control of your content production process today.

If your company wants to go responsive but you need a little help getting started, Karen and I offer a two-day onsite workshop to help you make your responsive design happen. Visit responsivewebdesign.com/workshop to drop us a line—we’d love to hear from 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 episode at responsivewebdesign.com.

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