Episode Transcript

Ethan:

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

Karen:

And I’m your other host, Karen McGrane.

Ethan:

This week we are impossibly excited, we are vibrating with joy, in fact, to bring you both Chris Balt and Trent Walton, who are going to talk to us about the Microsoft.com responsive homepage. Chris, Trent thanks so much for coming. We really appreciate you guys coming here.

Chris:

Thanks for having us!

Karen:

Before we dive into our conversation, I want to tell you about some exciting news from our sponsor, Campaign Monitor. Did you know that more than half of emails are opened on a mobile device? Making emails look and work great on all the different devices and email clients is one of the hardest problems in responsive design. And that’s where Campaign Monitor comes in. They have an easy to use email builder called Canvas, that creates emails that look great everywhere. In just minutes, you can drag and drop your way to a beautiful email that just works, with images and typography that will scale correctly on every device. Want to try it out? You can see how it works, and you don’t even need a Campaign Monitor account. Just go to campaignmonitor.com/templates and see for yourself just how easy it is. I know, because I use it myself, and I love it.

Ethan:

Why don’t you guys introduce yourselves and tell us a little bit about what you’re working on, and how responsive design impacted the Microsoft project. Chris, why don’t you go first.

Chris:

Absolutely. First of all, thank you guys. My official title is product manager on the Microsoft.com team. That means different things depending on the day. But, with regards to this project, what it means is that I worked with the other members of the product management team and a team of designers and a team of developers and the great guys at Paravel on the responsive redesign of the Microsoft.com homepage.

That was about two years ago. Since then I’ve overseen some tasks to take that work and expand it across the company. We started with the homepage and my work as of late has been evangelizing that to other web properties. I’m sure we’ll get into how that organizational web has spiraled and what impact we’ve had. That’s the role that I’ve played as of late.

Trent:

I’m Trent Walton. I work with two of my best friends I’ve actually known since growing up in high school, Dave Rupert and Reagan Ray, at a web shop in the Austin area called Paravel. We lucked into getting hired to help Microsoft build the 17th version of their homepage in 2012 and it was going to be responsive and everything. We’re happy to be involved in that. It’s been a lot of fun to watch the site evolve over the years.

It didn’t take a whole lot of convincing, it didn’t take a whole lot of pressing. It was really all about building and solidifying some of the relationships that were already in place with the team here and some of the extended team at Microsoft.

Ethan:

That’s fantastic! One thing I like in particular is a good origin story. When everyone saw the responsive homepage go up, there was this like, it was amazing, it was beautifully done. We talk to a lot of organizations and companies when they’re thinking about a transitional responsive strategy, like carving off a small part of the site to go responsive and learn from it. The homepage isn’t usually the first one they go for. I’d love to hear about, Chris, how that conversation started internally. How did you actually convince your stakeholders that responsive design was the right approach?

Chris:

That’s a great question. I’ll caveat by saying I entered the homepage project, this particular project, about halfway through. But I am acutely aware of the process that led up to this, at least on our side of the fence. It was really—I think Trent will echo this from his side of things—it was being in the right place at the right time. It was our team having the right relationships with other folks at the company, who had relationships with guys like Trent and Dave and Reagan, and had been exposed to this newfangled responsive web design and had read your book, Ethan, and had been chatting about this for quite some time.

Surprisingly, it didn’t take a whole lot of convincing, it didn’t take a whole lot of pressing. It was really all about building and solidifying some of the relationships that were already in place with the team here and some of the extended team at Microsoft. To connect with the guys at Paravel, to use this as a launching ground for something that really has taken the entire company by storm.

Our attempt to do it first with the homepage was a good choice. It led to significant visibility within the company and even outside the company that I don’t think we would have had, had we chosen some off corner.

The choice to have the homepage be the first to do that was certainly not deliberate, it just happened to be a single property—albeit, a visible property—within our control that we wanted to test it on. We’re very happy we did it that way.

I think other sites have taken different approaches and either gone from the bottom up or just tested with some random corner of the site. Our attempt to do it first with the homepage—and beautifully so, if I say so myself—was a good choice. It led to significant visibility within the company and even outside the company that I don’t think we would have had, had we chosen some off corner or some second-level support site or something like that. So even though the experience for a user may have suffered somewhat—they are one click away from a non-responsive experience—the visibility that obtained us politically, organizationally, both inside and outside the company was a great choice. I am very glad that we did it that way.

We were in the middle of trying to shift our organization’s thinking to no longer draw a line between the unique needs of a mobile user versus a desktop user, but rather recognize that their needs are, more often than not, quite the same.

Karen:

Can you talk about how you describe the needs of the mobile user versus the desktop user at Microsoft? So we’ve talked to lots of different organizations that have very different, I would almost say organizational constructs around how they conceive of what the “mobile user” wants. And many times that rolls back up to an organizational constraint that they have a mobile team, or that the development teams are organized in such a way as to have them divided into mobile and desktop. Can you talk about, how do you describe that and how does that play out in the way Microsoft is structured?

Chris:

Yeah, that’s a interesting question. Funny enough, right in the middle of this project, our team brought on a mobile product manager. It’s a small team we have. We have four or five product managers on our product team with Microsoft.com, and one fifth of that team or one quarter of that team at the time was focused on mobile specifically. Not that that was, it wasn’t counter to what we are doing necessarily. It was odd. I say it was odd because we were in the middle of trying to shift our organization’s thinking to no longer draw a line between the unique needs of a mobile user versus a desktop user, but rather recognize that their needs are, more often than not, quite the same, or that they at least have the high potential to be the same.

Our data shows us quite plainly and clearly that the behavior of those on our mobile devices and the small screens is really not all that different than the behavior of those on the desktop.

So, I’ll go back to the mobile PM. She is no longer the mobile PM, she is focused on other areas that I think are more aligned with our team strategy and focus. But that quick shift showed that as an organization we needed to think about the two separately.

Our data shows us quite plainly and clearly that the behavior of those on our mobile devices and the small screens is really not all that different than the behavior of those on the desktop. And the things they are seeking to do and the tasks they are seeking to accomplish are really quite the same. As the front door to Microsoft.com, the homepage sees it all really, so we have a really great litmus as to what people are seeking to do on our network. Seeing those two device types or form factors doing the same thing was very, very telling. So, increasing and even through the project that we worked on with Trent, Dave, and Reagan at Paravel, I think we tried to really eliminate that line. Trent, maybe you can speak to whether or not that was actually the case, but it seems like it was and it certainly rings true today.

Trent:

For us, I mean our experience working with the team was, before we met anyone, we were overwhelmed and scared. Just the stakes seemed to be really high and we had a lot of assumptions based upon that. But I’ll never forget the first day we walked into the office and started talking shop, just about ideas, and immediately knew that we were surrounded by enthusiastic peers, that had the same priorities for what a website could and should be. The whole time we are working on the job, we felt somewhat insulated from some of the internal churn that was going on around us.

Ethan:

I’d like to hear a little bit, Trent, about how you guys thought about scoping the project initially. Like how do you try to get your arms around how to structure an engagement like redesigning a homepage responsively?

Trent:

We just did it in month chunks, and we figured it would take from the spring to the fall. They knew their launch date and they knew that they would need us around to help, and so once we just got engaged and in the office, and started working with them on kick off, we just planned it accordingly then. So the launch date especially, drove everything. There was a beta soft launch in July. And then all of our time from then forward to October was really kind of testing and preparing things. The July launch was basically a static version and then everything had to be pulled into the CMS and tested and built up for all the locales that it would be traveling to. Once we knew the launch date, everything kind of happened after that.

And everything we say and do, we did not do really for this job. Because it was so new. The process was very opposite to what we do now.

Ethan:

That’s awesome. I’d be curious to hear a little bit like, this went live in 2012, right? So, you guys have been doing some lovely responsive work for years. As you guys have been doing more multi-device work, has how you structure your projects changed a lot? Or, how do you think about laying these projects out basically?

Trent:

We do talks sometimes and write posts. And everything we say and do, we did not do really for this job. Because it was so new. It’s really nice to talk about this today, realizing that this was one of our first. We had done a few responsive sites before this, but on this kind of a scale, we’d never come anywhere near it. We really, at that point, early on, gravitated to just what we knew. The process was very opposite to what we do now. We did a lot more Photoshopping than we did and we did a lot more desktop first type of layouts.

Maybe selfishly for me, this idea that all of these beliefs that I had about responsive web design and the possibilities for what it could really achieve, I got to experience.

I think if I went back, we would do it the exact same way, because everyone was in such a new boat. We had no idea what process should look like. A lot of the posts and talks and things that have been written and said about how to do this, they may have been eking out at the very beginning, but they definitely weren’t something that was comprehensive that we could get into. It took everyone on the Paravel side, and obviously for sure the Microsoft side, to be okay with a messy, piece-by-piece process. But, everything we learned there, I’m sure Chris can speak for this, it’s probably refined their process and workflow a lot. It taught us a whole bunch about launching and building a responsive site.

It’s scale. And then more than anything, my favorite thing, is that it was—and this goes back to the homepage—it’s lucky that that was the page that happened to be tackled and launched. And then, maybe selfishly for me, this idea that all of these beliefs that I had about responsive web design and the possibilities for what it could really achieve, I got to experience. It was almost like a roller coaster ride, I got to experience first hand this few month journey of seeing it prove out right before my very eyes. I probably seemed pretty confident, but there were times when I really hoped that everything we’re saying happens, and it did! So, it taught us a lot and I think it also demonstrated to us a lot about what the possibilities were going to be.

We had the opportunity to go on this roadshow of sorts to share all the ins and outs of the things that responsive design exposes in your team and in your organization and in your workflows and your production methods.

Chris:

What’s really interesting, to that note, is that my role at the time was that I was in charge of this thing called template components. It was a program at the company, on Microsoft.com, that was intended to create these reusable frameworks and templates and components—hence the name—to share with the company at large. My job was so easy after the launch of this new homepage in late 2012. In early 2013, I came back from Christmas and New Years and my inbox started getting flooded with people across the company just saying “tell us what you did, how you did it, teach us responsive design.” It kind of became a marketing push for these efforts to bring some consistency across our web properties.

We still have a long way to go, but going back to my point about the homepage being a great first chance to do this. It really was fantastic. We had the opportunity to bring the Paravel guys in for some calls with different teams across the company, to go on this roadshow of sorts to share, not only from a technical standpoint, how we accomplished it, but organizationally and from a team standpoint, and all the ins and outs of the things that responsive design exposes in your team and in your organization and in your workflows and your production methods and all that stuff. We walked through that for several months with Trent and his team. It was invaluable to other teams at the company, for us to share that experience. And it was a lot of fun.

The amazing thing was that a lot of stuff just sort of seemed to line up at the time. They were all kind of happy to compromise. It seemed like there was very little friction.

Karen:

Can you talk a little bit about how you went through the decisions around what to prioritize? What to keep, what to get rid of, what goes where, what’s more important? I’ve talked to a lot of companies that really seem to struggle with how they take all of the stuff that they have on their desktop pages and squish it down so it works at smaller sizes. How did you do that? How did you do that with the rest of the organization?

Chris:

For the homepage specifically, I’ll really look to Trent to answer that question. The reason I say that is because we did some groundwork and laid the foundation to really have our team and our relationship with the Paravel guys really direct these efforts for the homepage. I think with a lot of due respect, these guys drove us through this process and solved some of those problems. So, Trent maybe you can speak to specifically what you guys recommended there.

Trent:

This brings back memories. This is maybe one of the first times I got a spreadsheet that was mapped, every link on the page was mapped to a certain department. There were meetings, and everything that was on the page was there, not by somebody just choosing that, it was the product of lots and lots of work.

The amazing thing was that a lot of stuff just sort of seemed to line up at the time. The Windows 8 aesthetic was, at the time, known as Metro. It was a typography-forward, more minimal vibe. Actually, everyone in Redmond seemed to catch that. They were all kind of happy to compromise. It seemed like a lot of the things that we were trying to do as far as pulling back the amount of content or links or even redundancy in content or links. It was actually, from my perspective and I wasn’t doing it directly, but it seemed like there was very little friction. There’s a lot of content and links to all the stuff that Microsoft does on this homepage. There was a lot more in version 16, the last one, the one before we touched it.

I do also think that the existence of the m-dot, that played to our advantage. There are some dropdown menus on the homepage and there’s quite a few links on there. If you were to visit it on a mobile device, you would have fewer. We made a few compromises and did what we could but overall, realistically speaking, the spirit of the team and everyone on the outer layers that probably were fighting to get links on and getting their own initiatives on the homepage. We experienced, it was pretty delightful to see that it was scaled back from what it was at the time.

This goal of getting, within a couple of months, a version of the homepage up for a test. We got to code very, very quickly. We did that in about a month. Because we had this launch, it got us on the right track.

Ethan:

I’d love to hear a little bit, Trent, about what things were being shown to Microsoft at this time? Were you using mockups, prototypes? How did you actually talk about the responsive design with the client?

Trent:

We would have done way worse had this not been the case with this soft launch. We had to get something into code quickly. I would like to say that we knew that’s how to work in 2012, but we weren’t really quite there yet. Because, for us, at the time, this was overwhelming. Microsoft homepage! So Reagan and Dave and I reverted to what we knew best. We went to JPEG wireframes of wide views. I think it was good because we showed up for a kickoff and we had some ideas. Very quickly these discussions immediately turned to us discussing, it’s maybe backwards to do this, but we started with the desktop layout and we were immediately saying “this is not the thing we should be fixated upon.” Let’s get all of our content in a bucket and deal with it there.

I think we lucked out that way. Had we not, we might have debated about JPEGs until the eleventh hour, and then built something and realized “wow, the real problems are here now and it’s too late.”

My backup plan was to do a bulleted list. And we do that a lot. Let’s list everything before we start thinking about layout. But, given the state of web design at the time, and where the team was and where we were, it was nice for the first couple of weeks to kick back and forth wide views. I think that’s a credit to maybe us, but especially the designers and the developers at Microsoft, and the product team. That they were able to immediately embrace this idea of a JPEG not really being able to fully capture what a responsive fluid media-queried layout can be. So kind of quickly, the team took the red pill, or whichever pill it was in the Matrix, and we were all fine.

I think had we not had this goal of getting, within a couple of months, a version of the homepage up for a test. We got to code very, very quickly. We did that in about a month. Because we had this launch, it got us on the right track. Much more akin to the way we work now, where, to me, a prototype is currency and everything we do is try to get it in the browser as quickly as we possibly can to assess feel, to assess space. Every discussion becomes a practical one instead of a theoretical one about “how is this going to change or shift or move?” You can see it real time.

So the necessity of us having that done, framed the pace and cadence of the project. It really paid off and I think we lucked out that way. Had we not, we might have been, and I think this has happened in other jobs we’ve done, debated about JPEGs until the eleventh hour, and then built something and realized “wow, the real problems are here now and it’s too late.” That fortunately did not happen.

It’s one thing to talk about the process and the people involved and how they’re providing content for the site, but the technical challenges of integrating with the CMS are huge.

Chris:

One thing I thought was really helpful, that I observed in the process working with the Paravel was that—I don’t know if this was by design or not, but we didn’t really concern ourselves and I don’t believe, Trent, you guys concerned yourselves with how all of this would play in, at least in the first stage of the project, with our CMS. The preview that was launched, which we launched to a sliver of our audience in June or July, several months before the full launch of the homepage. It was just static html, CSS, and JavaScript. It had absolutely no tie-in with our CMS. I think that allowed us through the project to truly test this design without having spent a tremendous amount of time and effort integrating with CMS, only to find that “oh, shoot, this test didn’t perform well.” Luckily it performed very well.

That CMS integration work continued on and carried on for the next couple of months. That was tremendously helpful. Our ability to do that is something that we’ve leveraged several times since then. It’s one thing to talk about the process and the people involved and how they’re providing content for the site, but the technical challenges of integrating with the CMS are huge when it’s not even tested yet.

We learned a lot from them about what it means to build for a system of this size. Instead of looking at a page, it really helped us evolve our thinking about responsive web design and the idea that it’s not a page but a network of content. It very truly is that at Microsoft.

Trent:

We were made aware of it. But, looking back and hearing you talk about it I actually now realize, had that been a problem from the beginning or something we had to focus on from the beginning, I don’t think we would have been able to focus on the part of the job that we were hired to do in the same way. We were focused on every little awkward moment of the layout and fine tuning that every break point and every media query, to make everything flow and fit a variety of content in a variety of languages in a variety of seasons. We were focused on that one problem for the first half of the job. I think, for us, it eased us into everything. We were calm after that first launch. We felt confident about it. We were able to bite off the templates and components type of work and getting this into the CMS.

One thing that I should say is that the team, a couple people in particular that come to mind, Greg Bader, Tyson Matanich, Benson Chan. They did a lot of teaching for us, and we learned a lot from them about what it means to build for a system of this size. Instead of looking at a page, it really helped us evolve our thinking about responsive web design and the idea that it’s not a page but a network of content. It very truly is that at Microsoft. It’s not a nav necessarily. It’s a nav component that could be displayed all over the site. If there’s a bunch of features, those are a list of links essentially with images attached to them. And all of these kinds of things, they really taught us a lot more than we… we thought we knew a decent amount, but we really got an education about component-level thinking. Having that come almost in the second of the two waves, it really instilled that sense of: we got to do the thing that we knew we were good at.

Dave Rupert always talks about this idea of why we’re coding and developing. Before things get really serious and we get really heavy into the system, there needs to be this piece where coding and design and development; there’s a bit of play there where we have a little bit of time and not everything is hitting all at once. That’s when I thought the creativity happened, the problems were solved, and all of this kind of stuff. This period of a few weeks of, able to just take this layout and get to know it inside and out and test it against all things, probably set the initial July test up for success. But also I think it really made us confident in the work that we were doing. Had we been logging into a pretty intensive CMS and working within a pretty heavy system, we would have been able to do the job and it would have been fine, but it wasn’t quite the same because we were able to ease in. Especially as outside contractors, they would have been totally fine. But, for us, it really gave us some time to ease in, get our heads in the game, on all those levels.

After this launch of the responsive homepage, what was more impactful was how we helped other teams at the company address their organizational challenges that are always exposed—or seem to always be exposed—when a site goes through a responsive redesign.

Ethan:

That’s great. One thing I’d like to hear a little bit more about Chris, something you mentioned in the beginning, was that you guys have built this design framework that was ostensibly for the Microsoft homepage. Have you been taking that and it’s been sort of propagating its way through other parts of the organization. What’s that process look like?

Chris:

Yes and no.

Ethan:

Okay.

Chris:

I think that where we still have a lot to learn is technically how to actually create and build. This is something we still want to do and need to do. And that’s build a truly reusable front end framework, set of components and design elements that could be shared across multiple teams of the company. In absence of that, that truly technical piece, at least right after this launch of the responsive homepage, what was more impactful was—I think most would say, a greater challenge—is how we helped other teams at the company address their organizational challenges that are always exposed—or seem to always be exposed—when a site goes through a responsive redesign.

Our team spent a lot of time, particularly with sites like microsoftstore.com, who we work very closely with. You’ll see a lot of design influence there. But, it’s not just the design influence and technical assuring we did. It’s the assuring we did with them as to how design works together with development, and how those teams need to work closer with the production teams, because it has impacts on the types of assets that are generated for each product.

Those types of things were where our team was able to really share a great amount with the rest of the company and only now, in a slower moving, larger limit organization, only now are we starting to say “okay, we’ve got the soft things shared as much as we can.” There’s much more to do, but now let’s get some of this technical, truly front end framework stuff put together so that we can—now that we’re organizationally thinking as one mind—start to technically look and feel and operate with those efficiencies in mind. That’s what we’re currently working on.

It shouldn’t spark a political battle, it shouldn’t spark a competitive nature in teams, but rather it should bring them together. If you center and focus around the user, the person who’s interacting with your creation, that becomes a lot more easy.

Karen:

One of the threads that runs through basically every conversation that Ethan and I have about responsive web design is that it’s much more of an organizational challenge than it is a design end development problem. Do you guys, both of you, have any advice for other firms, other sites, that are going through this transition themselves? What can they do to make this go more smoothly, or make more sense to their organization?

Chris:

I’ll jump in there first in that I’m preaching to myself when I say this because it rears its head all the time. And that’s that responsive design and these new design techniques and development techniques are really intended to focus on the user. They really, squarely and plainly, put the focus on the person who is using your site, without regard to which device they’re on. It makes them very important.

My advice to other organizations, particularly of a size and slothfulness at times, that our organization can be, is to keep that in mind. Remember that it’s not, it shouldn’t spark a political battle, it shouldn’t spark a competitive nature in teams, but rather it should bring them together. If you center and focus around the user, the person who’s interacting with your creation, that becomes a lot more easy. It’s so easy. Our tendency is to forget about the user and forget about the person who’s actually using your product. And to think well, this is the way our team does things and you need to work with us this way. That’s just the wrong way to look at it. Centering around the user can make this process a whole lot easier.

Working together as one team, rather than separate teams throwing things over fences, has made our job tremendously easier and we’re still learning more about that everyday.

The practical advice of prototypes, there’s a personnel, organizational benefit there. It really changes the tone of the work. Then you’re maybe forced to collaborate sooner within a process that may have been something more like a waterfall thing.

Trent:

Right in line with that, I’d say that our big thing is prototypes now. I think if you can focus on that and if things that you’re building are something that the entire team and all disciplines are contributing to—like Chris just mentioned throwing things over the fence—it’s “our thing” as opposed to “my thing” that I’m passing off to you to build.

The practical advice of prototypes, being that it might be quicker and more realistic and it makes things easier to assess earlier, there’s a personnel, organizational benefit there. It really changes the tone of the work. Then you’re maybe forced to collaborate sooner within a process that may have been something more like a waterfall thing.

I think that just by itself, the mechanism of, maybe going so far as to say something along the lines of, “we’re only going to have meetings about prototypes. Don’t bring a comp.” Maybe that’s too dramatic. But I like the idea of, yeah, get with some people on the team and build something together. It can be very, very rough, but it will provide the right tone and approach. It’s really easy to think… The more image based comps are in meetings, the more the meeting goes towards this theoretical discussion of “where’s this going to go at this view?” Instead of being able to just squish something and see where something might go to that view.

Going in, we were like wow, the design and the development, that’s the really hard stuff. We get to do the hard stuff. And that was wrong! The most important thing was the organizational shift and change and buy-in that was achieved before.

I’d say that. Then for us specifically, the Microsoft job is really, really special for Paravel and the way that we looked at it going in to it is much different than the way we see it now. And going in, we were like wow, we feel really honored to be a part of this team and like we’re going to do this important job of helping the team design and build the responsive site. The design and the development, that’s the really hard stuff. We get to do the hard stuff. And that was wrong! Once the site launched, looking back and hearing stories about how things happened and our experience over the years, the most important thing was the organizational shift and change and buy-in that was achieved before.

Without all that organizational stuff, nothing would have happened. Nothing would have launched. At the time I had no idea. Looking back, it’s been truly miraculous, how many stars aligned to get the site out.

People who were involved in getting the project set up and planned for and accepted and signed off, however all this works. Keep in mind, I wasn’t there when all of this happened. But, looking back and the stories I’ve heard, it’s this thing of… The organization was set up to really accept us and welcome us and utilize us and we plugged in really well. I thought maybe that’s because we’re nice guys and we have decent personalities and we’re smart enough to help. Maybe part of that’s true. But more than anything, by and large, it’s the attitudes of the large organization that hired us and their willingness to trust and change and adapt their workflows. It was a lot of hard work and I’m sure it’s a lot of meetings.

Without all that organizational stuff, nothing would have happened. Nothing would have launched. There’s many, many moments along the course of the project that things, had they not been so well-prepared at Microsoft and so well-organized around this idea of trying something that hasn’t been done at that scale before, I don’t think it would have worked. At the time I had no idea. I just thought we’re building a website and it’s pretty straightforward actually. But, there was a lot going on. It’s almost like we were on the tip of this iceberg and only after the site had launched had I realized how much had gone into preparing teams across all of the locales and preparing higher-ups to understand and accept what was going on. To me, it’s completely miraculous. Looking back, it’s been truly miraculous, the work that had gone on and how many stars aligned to get the site out.

Ethan:

Trent, Chris, I just want to say thanks so much for taking a few minutes to chat with Karen and I. This has been really wonderful and I can’t wait to see where Microsoft and Paravel will go next.

Trent:

Thanks.

Chris:

Thank you guys, it was a pleasure.

Karen:

Thanks to everyone for listening to this episode of a responsive web design podcast.

Ethan and I are really excited to announce that we’re offering workshops on responsive design to the public. One will taking place on March 06 in Boston, and the other will be in New York City on April 2-3. If you’re interested in attending, visit responsivewebdesign.com and register for a ticket today!

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. If you’re interested in bringing us to your company, please go to responsivewebdesign.com and let us know that you’re interested.

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 again to our sponsor, Campaign Monitor. Be sure to visit campaignmonitor.com and check out their email editor, Canvas. Thanks for listening, and we’ll be back next week.