Episode Transcript

Karen:

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 we’re really delighted to have Rob Huddleston and Scott Childs from Capital One come and talk to us. Hi Scott and Rob, how are you?

Rob:

Hey, how are you guys?

Scott:

Good thanks.

Ethan:

So before we hear more from Scott and Rob, I think people might want to hear what our sponsor, Campaign Monitor has been doing with their email newsletters. Because they actually have this new application called Canvas that we’ve been really excited about. It’s an email newsletter builder. They basically told us that it’s based on designing styles rather than templates, which is kind of exciting for me to hear because it means the content can really drive the design, instead of being focused on filling spaces in little boxes in your layout. I know for me, at least, I’ve always been really excited to see what Campaign Monitor has been up to. I mean, the few times I’ve had to design email newsletters, they’ve been an incredible resource for the better part of a decade for me, in designing articles and figuring out how to get email newsletters done. So we’re really excited to have them be part of the show.

Karen:

Why don’t you introduce yourselves and tell us a little bit about what you’ve been working on.

Scott:

Yeah, that’d be great, thanks Karen. I am Scott Childs, I am one of the creative directors here at Capital One. I’m currently responsible for our credit card product vertical and spend a lot of time continuing on the journey we started about a year ago with responsive. We’re starting to work with our lines of business and kind of further them in this mobile first, future friendly mentality, and looking at how we start to flip our entire content strategy and our entire way of thinking away from the desktop and starting at a different point.

Rob:

And I’m Rob Huddleston, I’m also a creative director on our UI and UX team. I focus on primarily on all things capitalone.com, from the platform, the design system, the standards of governance all the way through to delivery. So pretty much anything that goes to production on capitalone.com I’ve got my hands on to some degree. Doesn’t mean I designed it or did the actual work on it, but I at least review it, provide some consultation and some input throughout the process.

Karen:

So it sounds like you guys have a big responsive redesign that you’ve just launched. Can you tell us a little bit about that process in general?

Rob:

Yeah, I’ll give you a quick overview. So our responsive web effort on capitalone.com went live last April 20th of 2013. It was a site wide retrofit, if you will, so we did not redesign our website. To give you some context on scope, there are roughly 2,500 pages or URLs. Each of those pages consists of dynamic content and design based on a lot of logic on the backend that depends on the zip code, where you live in the country, what sort of device you’re coming to the website with, operating system you’re using. We customize and tailor the content to more of a marketing approach, tailor the content to the user. What that means is those 2,500 pages results in roughly 4,000 variances of content and design across the entire website. So rather than redesign all of that, we did a retrofit responsive effort. So we backed into it. We used our portal platform which is a java-based platform and really focused on the design system that we had created when delivering the re-platforming in 2010. So a lot of smart decisions that we made in 2010 led us to a great deal of success with responsive later.

We went from having less than four percent mobile traffic on the dot com last March to over 40 percent, I think we’re at about 44 percent today. We’ve seen a huge amount of lift on the dot com since responsive.

Ethan:

That’s great, so I guess the question that comes to my mind is why did you guys decide to go responsive? I mean obviously this is a pretty big property and you guys had a mobile site, right?

Rob:

We did have a mobile site—an M dot at the time—and we still do for servicing, so for logging in and servicing accounts, but for the marketing space, the dot com that we support. As a design team, it was something that we were very interested in, responsive. We had been learning a lot about it, we had been going to conferences. Doing side-of-the-desk projects, just really digging in and figuring responsive out. Ultimately we knew it was the best thing for our users, and a sideline benefit of that would be obviously brand awareness, so there’s a brand benefit, there’s a business benefit.

But first and foremost for us, it was the users. Some data that we actually found in doing research and really fighting the good fight to sell responsive up the chain to our executive channels here at Capital One, we found out that 96 percent of the traffic that was being driven to our M dot solution was actively leaving. So we had to assume it is more of a content parity issue with our M dot solution at the time. There was just a very limited amount of content for users coming to that M dot experience. Again 96 percent were actively leaving to go to the full site and dealing with a really horrible pinch-and-zoom on their mobile device. So that became our mantra, we were really fighting for that 96 percent and making their lives better by doing so. We knew that we would build upon that. We went from having less than four percent mobile traffic on the dot com last March to over 40 percent, I think we’re at about 44 percent today. We’ve seen a huge amount of lift on the dot com since responsive.

Scott:

It was really great, because it was a win-win-win for everybody involved. It was obviously a huge win for our customers just because it gave them a much better experience on a small screen device. It was also a win for us internally because it started to cut down on stuff like maintenance pertaining to a separate desktop and a separate mobile device. Obviously through search, that was a huge one from our standpoint, because Google likes a responsive site as opposed to multiple sites that are pushed out at the last minute to M dot and things like that. And then obviously it was a great for us as a design team because it was a very intellectually challenging project to undertake.

We deliver business value, we’re not just a production team or production shop where we’re cranking out web pages and static content, designs. We actually are influencers now when it comes to brand strategy and business strategy and business goals based on this one effort. So it’s really done a lot for our team internally.

Rob:

And this was also a project that really started and finished within our design team. So this is a great opportunity for us as the design team to lead an effort that brought in such a huge benefit to the business side of our world. I know we’ll talk about some of the metrics a little later, but we saw such a huge amount of lift from this responsive effort alone that this really brought the design team to a space where we we now have a seat at the table when we talk about business strategy. We deliver business value, we’re not just a production team or production shop where we’re cranking out web pages and static content, designs. We actually are influencers now when it comes to brand strategy and business strategy and business goals based on this one effort. So it’s really done a lot for our team internally.

Karen:

I love everything you’re saying, it’s such a clear-cut case for why going responsive is good for users, it’s good for the business, and it’s good for your team. But I can kind of imagine, before you had all this insight of how successful it was, it wasn’t the easiest sell. Was there a lot you had to do to convince stakeholders and navigate the political landscape?

Scott:

Yes. There was a lot, a lot, a lot to say the least. Because it was a new technique. It was something, our VPs, our executives that ultimately had to sign off on this, it wasn’t something they could go out and readily see. And maybe even, more importantly, at least in our case, it wasn’t something that our competition was doing. Even the great pieces that we could show for them, as far as kind of larger scale, it was pretty small. We were really looking at Starbucks, Microsoft.com, The Boston Globe, Disney.com, to some extent. It was a pretty small group of people that had already kind of taken the plunge into responsive, which really made it a much tougher sell in terms of, to get our executives to buy in. Why should we invest money, why should we invest time, why should we put other things on hold because of this?

I think “why?” was the big question that we kept being asked from every possible angle. There were no data points that we could leverage. The only one that we could leverage that really screamed loud-and-clear why this was important was that 96 percent statement—96 percent of the mobile users are actively leaving the website, so obviously we’re doing something wrong there, and this is an opportunity to fight on their behalf.

Rob:

I think “why?” was the big question that we kept being asked from every possible angle, whether it was executive, or internal line of business, customers. It was really, how can you prove to us this is the right thing to do? None of our competitors are doing it, none of them had done it yet. There were no data points that we could leverage. The only one that we could leverage that really screamed loud-and-clear why this was important was that 96 percent statement—96 percent of the mobile users are actively leaving the website, so obviously we’re doing something wrong there, and this is an opportunity to fight on their behalf. That was the one thing, once we realized that was actually happening, that was the data point we used in every conversation we had. To just really say that only four percent of our mobile population is actually using the M dot and getting what they need out of it. So what could we do to better the experience for the other 96 percent? And that was some data that no one could argue. Regardless of line of business, regardless of executive, whatever angle was being pushed back on us, that was something that no one could argue. That was the flag that we flew for the majority of the project, was really that 96 percent. Of course we saw the benefit cascade out out across all of our users, specifically of course on mobile and tablet, we saw the benefits after we launched. But going in, that was the big statement that we made.

We delivered this project in two months from green light to release.

Ethan:

Well that’s great. So you guys have made this argument internally, and once you actually had the green light to actually start working on a responsive site of this size. You know, 2,500 pages, you guys have not a small amount of traffic. How did you guys decide to scope this? What did you decide to start working on first, basically?

Scott:

Well, yeah the traffic is huge. So just to touch on that real quickly, we get on average 30 to 45 million unique visitors a month to capitalone.com which results in over half a billion page views each month. So yeah, I think in terms of what we chose to work on first, it was really, again to my earlier statement, it was a lot of what made it possible for us to do this and to do it is quickly as we did. We delivered this project in two months from green light to release.

Karen:

Wow.

Ethan:

Wow.

The decisions we made with the [CMS] re-platforming in 2010, in creating a design system that was modularized, it was scalable. That was really the decision that years later led us to this success and to deliver responsiveness at the pace that we did. We already had a design system in place where our platform was componentized.

Rob:

Yeah, with a very small team of nine people, one UI engineer, Brian Dillon, who will talk to you later, he wrote all the presentation layer code by himself. So it was a very small team, we were working very fast. But the decisions we made with the [CMS] re-platforming in 2010, in creating a design system that was modularized, it was scalable. That was really the decision that years later led us to this success and to deliver responsiveness at the pace that we did. We already had a design system in place where our platform was componentized. Very much like what Brad Frost is talking about now with atomic design. We were doing that in 2010. We had multiple content components in a library of assets that could be used to deliver page design and page content or web pages. Each of those components were scalable so they aligned with our grid system, but every component could be matched up against four columns, six columns, twelve, ten, sixteen, however many. So each of these components were already flexible within the grid and within the 960 container that we had defined. So really, our primary focus was on the grid itself and the container, so all of these components and modules were already flexible. They were already scalable. A lot of the work had already been done for us. We didn’t realize it at the time until we really started digging into responsive, but had we extended that methodology when we re-platformed, had we extended the component approach out to the grid and to the container, you know Ethan, we might have been challenging you for being the first to have done this and not even have known it.

Ethan:

Yeah, that’s awesome.

Rob:

And again it wasn’t, I don’t want it to be seen as an accidental win, you know there was a lot of thought put into scalability and componentization and you get a flexibility early on when we re-platformed in 2010 and this was just a benefit. As we’re moving into adaptive and other capabilities on the platform, that single decision has led us to majority of the success we’ve had since.

Scott:

And this is one of those cases where a really stringent content management system was extremely helpful in this effort. I know you want to shake your fist at it because it won’t do that one little thing you want it to do, but when we start to look at these large-scale changes, it would have been almost impossible to do it otherwise.

Even though it’s this massive number of pages, when you look at 2,500 pages over 4,000 page configurations, everything boils down to a couple things really. How many different components do we have total? It’s around twenty components.

Karen:

Can you say a little bit more about that, like what the benefits and challenges were when working with your content management system and how that fit into the responsive process?

Scott:

Yes, so, and obviously Rob feel free to jump in, this is definitely an area where you’ve got a lot more expertise than me, but like Rob said, I think part of it was just the Roman column configuration that we had come up with was inherently very flexible. And just the fact that we do have such stringent guidelines as far as our style guide or what we call our build book. Even though it’s this massive number of pages, when you look at 2,500 pages over 4,000 page configurations, everything boils down to a couple things really. How many different components do we have total? It’s around twenty components.

Scott:

I think at the time, we really had twenty components that could then kind of fit and scale and flex across these 4,000 pages. So when you got down to its core, the way we set the content management system up, we really didn’t have to deal with that many things, but they cascade out into a staggering number of different configurations.

We separated code from content. We built out a new admin tool for our CMS where we’re not using page templates or page types. It’s really all these components and how they align to the configuration or how they’re just assembled into each and every page based on business strategy, based on design strategy, and of course content strategy.

Rob:

And part of what we did, in that re-platforming, another one of the decisions that we made was separating code and content. So our content delivery teams, Scott and I, all of us on the design team who’ve been here more than seven, eight years, started in delivery teams where we were pushing content, new pages out, through different project efforts. And we knew that at the time the content management system really only worked as it was intended to in IE 6 or 7.

So if you opened it up in a browser that was more modern—Firefox or Chrome or what have you—we could inject in-line styles. We could modify the HTML markup. We could really have at it and do whatever we wanted, and ultimately that was causing a ton of problems as we went into the re-platforming exercise. That, by default, the work that we were doing on account of the band-aiding in the backdoor approach that we were doing to make our designs better on the platform or on the website, went into the decision to say “that needs to stop.” It’s not sustainable. It’s not scalable. It’s not something that we can really support from best practices and governance. We started thinking about accessibility and what-not.

So we separated code from content. We built out a new admin tool for our CMS where we’re not using page templates or page types. It’s really all these components and how they align to the configuration or how they’re just assembled into each and every page based on business strategy, based on design strategy, and of course content strategy. These new tools just allow an admin to be able to select pieces of content, apply a component to that piece of content, and then put them in a container element. So dividing a page into essentially rows and then dividing those rows into columns, and each of those column containers has a piece of content and a component injected into it.

And then a number of rules can also be applied to that dynamic piece comes in through the admin tool. You know, if in this zip code, show that piece of the content. If another zip code, change the page design altogether because we’re going to market a completely different product, or what have you. A lot of those tools that we built went into making that CMS even that much stronger, that much better in terms of responsive. I think that admin tool was a big piece of it, as well. Going into what we were able to deliver with a responsive effort.

Even if you run a super-tight ship from your content management standpoint, we still ran into a lot of instances, like you can’t check every page. After we launched responsive there were still a lot of things that were wrong, and it really came down to incorrect content contribution.

Scott:

Yeah, absolutely, and I think that also is going to bring something, at least in my head, kind of a good look-out point for people that are potentially still getting ready or in the process of taking the saw in this. Even if you run a super-tight ship from your content management standpoint, we still ran into a lot of instances, like you can’t check every page. After we launched responsive there were still a lot of things that were wrong, and it really came down to incorrect content contribution.

Rob:

Yeah, that was the big hurdle as we were in flight with this project. We noticed very quickly that on pages… What we did as far as a testing plan, we found the 100 most viewed pages on the site, and it was a good cross-section of content and pages and designs and lines-of-business. And so, we were covering a huge amount of the site with just those 100 pages. I think the 100 ultimately turned into about 120—just making sure that we were being thorough.

But what we recognized very quickly was that content, just through the day-to-day delivery process, was not being contributed correctly or as was intended when we re-platformed and built the system. I’ll give you an example. So banners, we have a banner component. Rather than delivering banners by using that banner component, there were instances where they were using an article template, so just a free-form HTML template where you can put a heading, an image, some body copy. So because of that, the images, because they were not using their appropriate component, we were not able to use the appropriate classes and have the design or the banner images scale. So that was a big issue.

We recognized very quickly that the new content teams were finding their own loopholes, their own backdoors to deliver content faster and maybe more streamlined so that they could do more at a faster pace. But because they were cutting corners, our project was now at risk and we were seeing things not work as we intended them to. So we got a remediation effort. In the midst of all this delivery we had to identify all the different types of content that were being contributed incorrectly, the different pages, find as many of them as we could, especially within this 100, 120 pages that we were going to be testing for our delivery and make sure everything was contributed correctly.

So, that opened a door for a whole new… We recognized at that point there was a need to train our content delivery teams, make sure they understood not only how to deliver the content appropriately, but the impact of not doing so. What sort of impact would that have, especially with this responsive effort. So since then we recognize that there is on-going training, there is regular training cycles, making sure that we’re communicating openly as we deliver a new capability or a new feature, whether it is responsive or adaptive or what have you on our platform, that we’re having the appropriate conversations and training to all the teams who are impacted by that, just to make sure they are up-to-date with all the latest and greatest things. So you know, Scott’s right that was a big issue that we hit that we were not expecting but we were able to react to maneuver around it and get it fixed before we rolled out.

Once we were at a point to be able to demo we realized that okay, it’s not about talking about this anymore, it’s about showing it off. We went far and wide just to show people what we were doing and put devices in front of them. That was what did all the work for us, was actually letting people play with it, letting them see it.

Ethan:

That’s great, I’d be curious to hear a little bit about, I mean you guys are obviously working pretty quickly on a project of pretty impressive scope. How did you guys manage reviews? Within the team, with the stakeholders, how did you guys communicate progress?

Scott:

That’s an interesting question. Well, we are using agile. We would have bi-weekly demos where we would show anything that we were completing and delivering over that two-week cycle. We were demo-ing out to groups that consisted of executives and our business partners, our internal customers.

One of the big requirements that we had—and again this is partially what led us to the retrofit—we were not allowed to modify the desktop experience. That was one of the fundamental requirements of this project is that we would not change the design, we would not modify content. There would be no impact to desktop users. So a lot of what we had to demonstrate was not only, “Hey, this looks great” or “This is a vast improvement on mobile and tablet” but “We are not modifying desktop.” So that brought challenges. As we’re moving more to an em-based design rather than pixels, there would be very incremental shifts. Ten pixels more white space. Three pixels, just talking in pixels, but fonts being slightly larger or one pixel smaller, one point smaller. So we would have defects lodged against us, every day, all day long, over the littlest thing that had no business impact, no design impact, no user impact. But we had a lot of people, a lot of eyes looking at this work, and very detail-oriented eyes looking at this work. So even the slightest couple pixels of additional white space or font sizes increase or decrease, we were having to react to defects being logged against those types of issues.

But to answer your question we demoed often. We realized during the selling of this project that showing people how it worked and what it did, what responsive was in a browser or on a device, was what sold the project for us. We talked about this for three months trying to get it sold, but it was actually showing someone what it was and what we were talking about that did all the selling for us. We picked up on that, so once we were at a point to be able to demo we realized that okay, it’s not about talking about this anymore, it’s about showing it off. We went far and wide just to show people what we were doing and put devices in front of them and show them the difference between the M dot and the responsive, and the current state site versus the responsive future state. That was what did all the work for us, was actually letting people play with it, letting them see it.

We’re going back now and starting to make some larger wholesale changes to the experience and really starting to focus on different sections of the site at a time with that mobile first content strategy. I think that’s gonna really start to go a long way to change attitudes and mentalities, internally, how people approach things. How people review things.

Ethan:

That’s great, I’d be curious to hear, I mean has that emphasis on the pixel perfection and sort of the layout, has that more or less stayed the same since you guys have rolled this out or has that changed since you’re working with a more flexible design just more generally?

Scott:

Yeah, I think it has changed and it hasn’t changed. I think our business partners are still getting used to kind of working on things in a little bit of a different way, so there is still a lot of focus on pixel-perfect design and “just show me what this is gonna look like in every possible state.”

At the same time, depending on the sophistication some of our partners have, people are slowly getting used to a new way of working and starting to see how these things, starting to inherently know how these things will change and respond up or down depending on your device type. I think a big step forward that we’re in the middle of changing with that is—we mentioned several times this was a retrofit—we’re going back now and starting to make some larger wholesale changes to the experience and really starting to focus on different sections of the site at a time with that mobile first content strategy. I think that’s gonna really start to go a long way to change attitudes and mentalities, internally, how people approach things. How people review things. What people expect to have a say in as we start to develop new content for the site.

One thing that it did do was shine a big bright light on the content issues. Overabundance of content, redundant unnecessary content. People started to see their web experience on a smaller device and seeing how just an overabundance of content there was and how unnecessary it was. Finally—it took a year—but we finally have internal customers come to us saying “Okay, you were right, we need to think content first.”

Rob:

One thing that the retrofit—not changing the desktop—one thing that it did do that we knew it was going to do was shine a big bright light on the content issues. Overabundance of content, redundant unnecessary content. People started to see their content strategy or just their web experience on a smaller device, seeing how just an overabundance of content there was and how unnecessary it was. Finally—it took a year—but we finally have internal customers come to us saying “Okay, you were right, we need to think content first. Let’s redesign our site.” And when they say “redesign our site” they’re actually not at the start of it talking about what it looks like. They’re actually coming to us saying “Okay, we need to rethink architecture, we need to rethink content strategy, we need to actually think mobile first.” So, you know, again it took a year, but it’s a really nice conversation to be having rather than still fighting against them on it. So, we’re starting to see it, slowly but surely.

We’re also working on projects right now where different business units are redesigning their entire section of the site. We’re seeing some lines of business go in with page reductions of sixty to seventy percent.

Scott:

Yeah, I think we’re really starting to see some significant gains in that space. And some of it’s just due to the line of business doesn’t want as much. Doesn’t want as many pages to deal with so they can start to manage things easier and get things out faster. We’re looking at stuff right now where we’ve got individual product pages which are actually a total of five pages of content per product, which is way, way too much for the user and it becomes really difficult to manage. We’re working on projects, condensing those five pages down to one page. And that’s not just junking everything together, but that’s getting really thoughtful about what we say on that one page and making it really informative but consumable for the user.

We’re also working on projects right now where different business units are redesigning their entire section of the site. We’re seeing some lines of business go in with page reductions of sixty to seventy percent. People starting to get really thoughtful about how much we’re seeing on the site—and more specific—exactly what are we seeing. How can we get the most value out of content that is streamlined as much as possible?

Ethan:

That’s great. I’m not trying to put words in your mouth but it almost seems like mobile has kind of brought users to the table a little bit earlier in the design process.

Scott:

Yeah it has, that’s one thing within Capital One. We’ve definitely seen a pretty dramatic shift, I’m going to say over the last two years. Very, very, very, user-centric design. Not the typical kind of CCD or UCD process. But even taking it farther back from that. We’re definitely very big subscribers to the design thinking process. So, getting out and talking to users in the product development cycle and really starting to empathize and iteratively going through that cycle numerous times with the product development as well as the product design cycle.

Mobile consumption, so, mobile users coming to the site and actually staying on the site went up five times from what it was before responsive.

Karen:

So, did it work? How do you measure the success of your responsive design?

Rob:

So, one of the great things about the platform we’re using is we test and we track everything. Sometimes the testing, we can get in a whole conversation about incremental testing and how painful it can become. At least from a metrics perspective, we rolled out the responsive work without any fan fare. There was no press release. Obviously there was a risk associated if it didn’t work the way we kept telling people it would. They wanted to be able to roll back and have little impact and have it not be noticed. So no big campaign around this. We didn’t let people know. We just immediately started tracking.

Within twenty-four hours we saw that mobile drop-off had decreased by 15 percent. Huge number. Login, so for the users who were coming to capitalone.com on their mobile phone, for whatever reason they aren’t using the mobile app to login and service an account, make a payment, or transfer money what have you, that went up three fold.

Mobile consumption, so, mobile users coming to the site and actually staying on the site went up five times from what it was before responsive. We were tracking pre-responsive data as well for a few months and we knew that mobile users were staying on our website right around the 45 second mark, less than a minute. Within a few weeks, those same users were staying on the site for over five minutes.

Karen:

Wow.

Repeat mobile visits were up over ten times or ten fold than they were before responsive. Page views by mobile users grows just over 42 percent in a couple of weeks.

Rob:

And the repeat mobile visits were up over ten times or ten fold than they were before responsive. Page views by mobile users grows just over 42 percent in a couple of weeks. And then, the big one for our internal customers and all of our lines of business was conversion. We saw within the first two months an 8 percent increase in product conversion on mobile devices and 17 percent on tablets. So we started thinking about, in our world, the credit card and financial industry, where 1 percent can be millions of dollars. This effort alone brought a huge amount of revenue to our organization across the board in a matter of months. Within 24 hours, we were seeing significant increase in mobile traffic. Within a few weeks to a few months, we started seeing such a significant amount of product conversion and just revenue coming in through mobile users. I think we saw traffic increasing from less then 4 percent to over 40 percent in about 8 months.

So that alone helped us argue against the M dot. We decided—to jump to that quickly—that was one of the arguments we had inside the project. There was obviously a team allocated to delivering the M dot. There was money, there had been time spent, two years or more, on delivering the M dot solution. One of the things we did decide to do, one of the decisions we made, one of the fights we gave up on through delivering responsive, is that we would not declare that the M dot was dead. We of course wanted to kill the M dot with this release, but we decided to let responsive do the work for us and let the metrics that I just threw out really speak loud and clear. They did the trick. Again it took a little bit of time, it took eight, maybe ten months. But the M dot went away. So it is no longer in use for marketing. In fact, within a matter of weeks we were able to deliver a cookie, that if you were a mobile user and you clicked the full site link, you would never go back to the mobile side. So there were a lot of wins for all of our mobile users, and for the business.

Karen:

Those are all fantastic metrics that you have in place. I hope you are justifiably proud of what you’ve been able to accomplish especially with such a small team and in such a short amount of time.

It’s really fun and rewarding for all of us who have been a part of this work, to see how successful it was, this “Little Engine That Could” project. We had a hard time kicking off at first but the entire company has benefited from it, we’ve all seen the value.

Scott:

Yeah absolutely! At first, I’ll admit, when we started seeing 2 percent, 3 percent, we thought, that’s not as big as we thought it’s going to be. But in the grand scheme of things, when you start thinking about 2 to 3 percent of about 30 to 45 million people, that’s a huge number. It’s absolutely a huge number. So when you start talking about 15 percent and 42 percent, it’s huge. So we’re extremely proud. It’s been great. We finally are at a point after a year or two where we’re talking about it, we’re sharing a lot about it. It’s really fun and rewarding for all of us who have been a part of this work, to see how successful it was, this “Little Engine That Could” project. We had a hard time kicking off at first but the entire company has benefited from it, we’ve all seen the value. It’s been really great.

Ethan:

And it’s been really fantastic that you guys came in to talk about it on the show, so thanks for that.

Scott:

Yeah. Of course! Thanks for the invite again.

Rob:

It’s been great.

Ethan:

Just so our listeners know, this is Part One of a two episode series, we are going to be bringing Rob back along with Brian Dillon to talk a bit more about the execution we are talking about in this episode. So Rob and Scott, thank you so much for coming today.

Scott:

Yeah! Thanks a lot. It’s been great. We really appreciate it.

Karen:

I am looking forward to talking more about this.

Rob:

Yeah! Thank you again. Can’t thank you enough, it’s nice to be able to get the word out on the work we’ve done, hopefully influence some other people, help them get it done in their worlds.

Ethan:

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

Karen:

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’re also planning to offer these workshops to the public, so please go to responsivewebdesign.com and let us know that you’re interested.

Ethan:

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.

Karen:

Thanks again to our sponsor, Campaign Monitor, and we’ll be back next week.