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 Karin McGrin.

Ethan:

And I’m the other host Ethern Markhart. [_Ed. Note_: These names, provided by the transcriber, are staying in.]

Karen:

In this week, we’re just about giddy with anticipation to talk to Kevin Ackley and Brian Greene, who are coming to us from Nationwide. Hi guys, welcome.

Brian:

Hello.

Kevin:

Hello.

Karen:

So why don’t we get started. Why don’t each of you introduce yourselves? What is your role at Nationwide and just a little about what you’ve been working on?

Brian:

So my name is Brian Greene. I’m in the user experience group. My title is creative technologist. Nationwide has an almost seventy person user experience department that’s responsible for design and interaction design and visual design across the entire enterprise. We’ve been working on responsive for couple of years now. We’ve several live sites and we’re in the process of doing several more sites currently.

Kevin:

I’m Kevin Ackley. I’m a front-end web developer for Nationwide. I’ve been in the company for 29 years and I’ve been doing development since about 2004. I have a focus on accessibility as well and have been doing responsive web design for about two years now.

Karen:

Well that’s fantastic. So it sounds like you all have a lot of experience with responsive projects. Do you want to tell us about some of the work that you’ve done? Maybe the latest big responsive redesign you just launched?

Brian:

Yeah, so Nationwide is probably best known for insurance, but we are also actually the, if not the largest, one of the largest public sector retirement providers in the country. So public sector meaning, municipalities, counties, cities, and even states have retirement plans similar to 401(k)s. So Nationwide provides that capability to a lot of these different localities. Internally it’s called the RSC. And that launched back in November of 2013. So we’re coming up on close to a year now. And that was a pre-authenticated, so suppose you worked in a county office and you’re setting up a 401(k)–not a 401(k) but your retirement account. You would go to our site, you would read information on how to enroll, and once you are actually enrolled then you login and then you have an entire post-authenticated experience where you could, similar to 401(k)s, you can buy or sell a mutual fund, get loans, and view your account balances.

Ethan:

That’s great. What’s the URL for that site?

Brian:

The main URL is nrsforu.com. We kept trying to change the URL, because it is kind of hard to verbally say, but it’s out there. Anyone can view the pre-authenticated site but you do have to be a member to actually be able to login.

Ethan:

Sure, I’ve got the site up right now.

Brian:

Ok, great.

One of the things that kept coming up was “let’s build an app.” And after researching that a little bit we found that it could be a slippery slope. We had to build it for multiple channels, it’s going to be constantly changing, it could become very costly.

Ethan:

So just curious, when you guys were starting this redesign, how did you actually convince your stakeholders internally that responsive design was going to be important for this? Did any questions or concerns come up, and how did you address them?

Kevin:

Well, we have requests for proposals from these different entities, and one of the things that kept coming up is we need some type of mobile solution. And so it was already in their minds that we had to do something. And one of the things that kept coming up was “let’s build an app.” And after researching that a little bit we found that it could be a slippery slope. We had to build it for multiple channels, it’s going to be constantly changing, it could become very costly. We wanted to try to do something where we could basically write the code once and use it in multiple ways. Through some research and through some conferences we went to, we started to lean towards going responsive versus doing an app or doing a standalone mobile site. So just through discussions and laying out the cost/benefits, everyone’s going to be pretty much on board that responsive was our best solution.

It wasn’t a hard conversation saying, up until now you almost had fifteen to twenty percent of your people coming and we were giving them no support whatsoever, from a testing and accessibility standpoint. It was a relatively easy conversation when they started seeing those numbers.

Karen:

So one of the things that I’ve heard from organizations that are more, I guess B2B-focused, where they’re working with people who are likely to be sitting at their desk when they’re engaging. I’ve heard some people say that they think responsive is great for consumer sites but it’s not really necessary for B2B sites or sites where they think there’s going be a proportionally higher amount of desktop use. Can you talk about how those conversations took place at Nationwide?

Brian:

I think that such a large organization, you know the insurance side of Nationwide wasn’t really a hard conversation. I think that just having some sort of mobile solution, whether that is an app or a responsive site, is pretty much table stakes at this point. But when you look at Nationwide Financial and some of our other business units within the organization, I think that that was sort of the perception, as you said, people don’t necessarily need to access these sites on their mobile devices.

But what we’re seeing is that we have some great metrics being collected every day, enterprise-type metrics. What we’re seeing was a steady, steady climb in the percentage of mobile and tablet users to our websites. So this nrsforu.com site, I think that when we started the project, I want to say the numbers were in the twelve to fifteen percent range of mobile and tablet users, and by the time we launched we were north of twenty percent and I think we’re heading towards thirty percent now at this point. It wasn’t a terribly hard conversation to say our threshold is somewhere in the two to three percent range for support, so the idea is that our site should, if a particular browser or particular device rises above two to three percent of users then we need, that gets added into our support infrastructure, that we need to be able to support. It wasn’t a hard conversation saying, up until now you almost had fifteen to twenty percent of your people coming and we were giving them no support whatsoever, from a testing and accessibility standpoint. It was a relatively easy conversation when they started seeing those numbers.

Ethan:

That’s great. I’d be interested to hear a little bit more about how you guys actually launched this. I mean was it sort of an all-at-once rollout? Was it a little bit more gradual? How did you actually unveil this to the public?

Kevin:

Our approach was to go ahead and do the entire site responsive and launch it all at once. So there was some conversation about rolling out particular pieces, but we felt that we could turn it around quickly enough that it was probably best just to do it all in one fell swoop and then when they go to our site it would be responsive throughout.

It put those fears to rest when we got from participants who were currently using the site, we showed them the new one, and they thought it was great, there was nothing but positive feedback. That really gave the ammunition that we needed to say we can just roll this out all at once and you’re not going to have any negative impact.

Brian:

There was some fear, I think, from business around doing that. The concerns around making such a large-scale change without a gradual rollout. But having such a large user experience group here, we did user test this and multiple—not only here in Columbus, Ohio, but also on locations in a couple of these different sectors where we knew that these participants were participating in these plans. We just heard consistently from the users that they didn’t even really notice a difference. I think that they had used the site before and we were showing them in user testing the responsive site, and I think it’s sort of interesting that it put those fears to rest when we got from participants who were currently using the site, we showed them the new one, and they thought it was great, there was nothing but positive feedback. That really gave the ammunition that we needed to say we can just roll this out all at once and you’re not going to have any negative impact.

One of the early requirements from business was that we cannot touch the desktop. It needs to look exactly as it did prior to the responsive. Through conversations, through user experience testing we were able to convince them that this redesign is okay.

Karen:

Let me follow up on that a little bit. In the course of the conversations we’ve been having with different organizations, it seems like one way that people approach a responsive rollout is that they take what’s on the desktop site and they make it responsive. And another way to handle it is that they do really a complete redesign, and a big part of that redesign is removing un-useful, unnecessary information, really paring down the site and re-prioritizing based on what’s most important. Can you talk about how you handled that? Like did you take basically what you had on the desktop or did you make significant changes to what you showed?

Brian:

We didn’t make really any significant changes. And that was almost one of the requirements, kind of going back to that fear that our business partners had, that we had just gone through a redesign within the last couple years. And that was very costly. It was a complete rebuild of the entire application. So they were very hesitant. One of the early requirements from business was that we cannot touch the desktop. It needs to look exactly as it did prior to the responsive. Through conversations, through user experience testing we were able to convince them that this redesign is okay.

We certainly did go through some content prioritization exercises with—not only users but also with business—around “what is the most important pieces of these pages?”

But, largely, we did not—besides consolidating navigation. What we were able to convince them, when we showed them that we had utility navigation, the upper right hand corner, we had primary navigation across the middle, then left hand navigation, and footer navigation, that there was just no clean way to make that responsive with all these different locations of navigation buckets. So, we did go through, in information architecture, redesign a little bit. And certainly a visual design to bump up the font sizes, make it a lot more crisp.

But, from a functionality standpoint, we really didn’t. Because of responsive, we really had to have all that same functionality across the different devices, so if it was there in desktop today or yesterday, it had to be there today. So, around, especially when you are viewing your balances, you’re moving money around, we need that, all of that needed to remain.

We certainly did go through some content prioritization exercises with—not only users but also with business—around “what is the most important pieces of these pages?”. And one thing that I would say we didn’t get a chance to do because in the scale of the website would be to do a lot of content rewriting. So this site is a single URL, but actually there’s about fifty to sixty white-label versions of this website across the country with these different plans that have white-labeled sites. So, we weren’t able to do a whole lot of content rewriting because that would have meant, that would have had to flow into fifty to sixty additional sites. It just wasn’t in scope.

We’ve been calling it the “content visualization wireframes.” We would put those up on the wall and we would give stickers and allow business partners to come up and we would give them that forced prioritization. You have to do a forced prioritization. We need a number one, number two, number three.

Ethan:

Could you say a little bit more about that, the prioritization exercises you guys did internally. When you’re actually looking at this established desktop site, how do you make the decision about the most critical piece of information on each screen?

Brian:

So, we would typically, not only in front of users in our testing lab but as well with business, we have some types of content… how do I want to say it? We’ve been calling it the “content visualization wireframes.” So, it’s sort of, it’s a little bit different than wireframes, but not quite a visual mockup. We would put those up on the board or up on the wall and we would give stickers and allow business partners to come up and sort of… log-in needs to be number one, so we would give them that forced prioritization. It’s an interesting challenge for some of our business partners because they’re so used to saying “well, contact us and log-in are the same importance.” And we would force them: no, you can not do that. You have to do a forced prioritization. We need a number one, number two, number three. We do a similar exercise, although not quite as formal, with the users to get their feedback as well and make sure that that’s aligned with what business thinks should be the most important.

Kevin:

Things like advertisements, those are the kinds of things that they quickly realize, okay, maybe that doesn’t need to be at the very top of the page, especially on a smaller device. Priority-wise, on desktop it’s fine to have it in the right rail or across the top, but when we get down to a smaller viewport size, they decided, yeah, that can either be moved to the bottom or is completely removed for this particular view.

The key thing was bringing over IT a lot sooner than they ever had before. Before, we had that big chasm between user experience and IT, where everything would just be thrown over the wall. Now we’re all collaborating a lot more. We have IT sitting with user experience.

Karen:

Can you follow up a little bit on the team that collaborates and participates in this process? Who did you have working on this and did the way that your teams work together change at all?

Brian:

I think that we had a pretty significant change in the way that we worked. Having such a large user experience team, we are… I don’t want to say siloed, but we are broken down into sub-disciplines within user experience, being interaction design, visual design, content, and researchers. And what responsive—and especially, not only within our user experience team having those different disciplines, but then how we interacted with IT—changed significantly.

So, traditionally before responsive, we would have our interaction designers create, they’ll use wireframes, socialize those through business. Typically we might even user test with these wireframes, like PDF wireframes. Then those would be handed off to visual designers. The visual designers would do, obviously give page hierarchy based visually, as well as make sure we’re on brand. Then all of that would have to be documented through PDF. We call them visual design specifications, where every single pixel, every single color, padding, font, all of that was all specified in a large document. Then that would be then printed out, basically, and handed over to IT then to recreate that. That was not great, obviously, to begin with, but with responsive obviously that just wasn’t even in the realm of possibility of what would happen.

Within user experience, we redesigned our organization—not formally, I would say, but on a project level—where the interaction designer, the visual designer, and then my role, which is new, is a creative technologist, would work to collaborate in a room and… you’ve heard talk about “designing in the browser.” We’ve experimented with… our visual designers went through HTML training and went through some of the courses to try to get up their HTML skills, but it was to the point where responsive was complicated enough. We really needed a specialty. So that’s where creative technologists come in. So we’re part of the user experience team under the visual designer and we all collaborate together. The key thing was bringing over IT a lot sooner than they ever had before. Before, we had that big chasm between user experience and IT, where everything would just be thrown over the wall, throw it over that gap and then it needed to be consumed. Now we’re all collaborating a lot more. We have IT sitting with user experience as part of the design process and bringing their knowledge, which is a huge change. At an enterprise level, it’s still in its infancy but we are getting traction in that type of model.

This collaboration went so well that it kind of became the new model. It’s kind of interesting because when we go to another project that wants to go responsive, they’re a little bit nervous because they’ve not worked in this model yet. But we have a track record now at least to show that this can be very successful.

Ethan:

Can you tell me a little bit more about how designers and creative technologists are working together currently? What kind of mockups and prototypes are each creating right now? I’d just be interested to hear a little bit more about how that collaboration works in general.

Kevin:

For the project we worked on the last year, like Brian said, it was usually siloed and at some point something would be handed off to the front end developers and they would begin to work off of design specs. This particular effort, I went to sit in the user experience area for a few months, built components, built a prototype that we could send out to the usability lab, bring users in to review it, make changes to it based on their feedback, as well as going out into the field and talking to our actual customers and getting their feedback. From this standpoint, as opposed to waiting until user experience had worked on it for months and then handed it off to me and then I’d have to kind of get up to speed, I was familiar with it throughout the entire process. As we were building these different components, I was able to think: When I go back into the actual code to make these changes, I’ll know what I need to do. I was pretty familiar with everything that was going to happen at that point.

The other big piece is usually UE hands it off and then they go onto another project. In this case, Brian came over into our development shop and he sat with me for a couple months as we converted all the CSS over, all of our code over, into the responsive world. This collaboration went so well that it kind of became the new model. It’s kind of interesting because when we go to another project that wants to go responsive, they’re a little bit nervous because they’ve not worked in this model yet. But we have a track record now at least to show that this can be very successful.

Brian:

I would say, from a mockup standpoint, I think that we are doing a lot more designing in the browser, but some work is still in Photoshop. Particularly where we’ve landed is we have a large desktop view and then the mobile view, and then anything in-between sort of gets figured out in the browser. One of visual designers, I’ll kind of steal his quote, I really like it, is we call the tablet, in-between the desktop and the mobile, we started calling it the “teenage years.” Kind of awkward, we’re not really sure where to put things. That’s really best done in a browser as you’re looking at where is that content going to break as we’re shrinking the browser or growing it, depending on which way we’re designing. How is that going to best fit in those awkward—it’s not quite ready to be stacked but it’s too small to sit side-by-side—how do we handle those?

We kept hearing “How do we make our CMS responsive?” as if it needed to be a plugin or something that had to change in the CMS in order to make responsive work. I think that was an interesting misconception about what it actually takes to do responsive.

Karen:

You mentioned earlier that you had been through a re-platforming a couple years back. One of the things that’s really interesting to me is talking to organizations in financial services or maybe retail or travel to talk about the components that are transactional and then components that are content-focused. Can you say a little bit about the re-platforming? Did you re-platform your CMS? And how does the content publishing work with the more transactional, data-focused, authenticated retirement plan information?

Brian:

We were sort of fortunate in this scenario where we talk about, on this website, the pre-authenticated and the post-authenticated. The pre-authenticated is all content-managed, especially with those various sites. We are updating the content on a pretty regular basis, especially with the advertisements and things like that. We are bringing new sites on all the time, as we acquire new plans, that these sites need to be created on a pretty regular basis. That’s all handled in our content management system that’s been in place for awhile. This isn’t the first time that we’ve used that content management system, but it was the first time that we did it with responsive. It was fortunate enough that while it certainly wasn’t perfect, the content management system handled it pretty well. It was sort of an interesting perception with business and almost even IT as well, is we kept hearing “How do we make our CMS responsive?” as if it needed to be a plugin or something that had to change in the CMS in order to make responsive work. I think that was an interesting misconception about what it actually takes to do responsive.

That’s all the pre-authenticated, just the content pages. After you log in, it’s mostly transactional and that’s all, what we’ll call “dev-managed” through the application. There are some hooks between—like the navigation, there’s some advertisements and some cross-promotional items that appear, and those are pulled in from our content management system. That was an interesting project to take on around how do we… because before, our content management system really doesn’t talk too much to our dev-managed pages. So how do we set up our environments, how do we set up our CSS, so that they flow seamlessly between the two experiences?

Stakeholders were involved throughout the entire process. At the beginning, they were looking at just mocked-up images. They looked at the prototype, they were in the usability lab hearing feedback, we had show-and-tells every couple of weeks.”

Ethan:

That sounds great. I’d be interested to hear a little bit more about the review process that you conducted with your business and your executive stakeholders. Were they primarily looking at prototypes or mockups or a bit of both? How did that change on this project?

Kevin:

They were involved throughout the entire process. At the beginning, they were looking at just mocked-up images. They stayed involved throughout. They looked at the prototype, they were in the usability lab hearing feedback, we had show-and-tells every couple of weeks. So they constantly got to see. The show-and-tells were actual code, so we would build something and we’d say “here it is with actual real, live data.” They were involved throughout the entire process as to what we were doing.

You could just see how excited the business got when they saw it on those devices. So we did our best to not ever project. It just doesn’t really do it justice. Having the latest devices, that they could really see what it would look like, really got a lot of excitement with our business partners.

Brian:

I think bringing those devices to every meeting, the user experience team—and every meeting. It could have been just a status meeting, that really had nothing to do with looking at the site per se. We would bring in those devices and show off the site, show off the progress. That was really instrumental in getting their buy-in. I kind of say “plus one for those Retina devices.” When you see it in the Retina and you see that everything is just so much more crisp than they’re used to seeing and everything just responds so well, it looks like that was obviously meant for that device, and that was the goal. You could just see how excited the business got when they saw it on those devices. So we did our best to not ever project. There would be some scenarios where we’d have to project, but those projections are horrible, you can’t see all the colors and it just doesn’t really do it justice. Having the iPad Mini with Retina display, the latest devices, that they could really see what it would look like, really got a lot of excitement with our business partners.

One thing that we’re trying to overcome that we’ll hear from our IT partners is “Yeah, I know you’re talking in milliseconds, trying to speed up your website in milliseconds, but we’ve got seconds of problems on the back end.”

Ethan:

That’s fantastic. I guess the other thing I’d love to hear a little bit more about is whether or not performance was ever a consideration when you guys were building this new site. Was that something you were tracking during the design process? How did you talk about it internally?

Kevin:

The effort really was to make the site responsive. It wasn’t really to tune any of the performance based on what it was before. Our idea going into it was “Well, however it was performing today, it’s going to perform just as quickly, but now it’s going to be responsive.” Fortunately, we’ve always kind of made sure that our pages aren’t too heavy, that we optimize our images and collapse our CSS and Javascript as much as we can, so that the pages do load really quickly. But yeah, our philosophy going into it was this is really a front end design, we’re not really changing the back end or tuning it. But, like I said, we had already kind of addressed that in the prior year when we did the rewrite.

Brian:

I think what we’ve seen more often than not—not just on this website but in other applications in Nationwide—is our back end systems are so complicated with these policy systems and records, a little bit older, I’ll say, type of back-end systems. One thing that we’re trying to overcome that we’ll hear from our IT partners is “Yeah, I know you’re talking in milliseconds, trying to speed up your website in milliseconds, but we’ve got seconds of problems on the back end.” I think what we’re doing is sort of a grassroots effort just to—while we’re not able to get funding to make the front end faster, just being under the covers, doing along the lines of what Kevin said, aggregating, minifying our CSS and Javascript, and being a lot more deliberate about how the page loads and things like that. Using sprites, using icon fonts, SVGs, things like that. We’re nowhere near where we need to be, but we’re certainly making efforts kind of behind the scenes as IT is sort of focused on back end performance.

There’s a company called DALBAR, they’re a market research firm in the financial industry. They came out with a large document of mobile statistics and in there they used several examples of what Nationwide had done for responsive, to say “This is the correct way to do things.” That was really exciting, to know that we were on the right path.

Karen:

Finally, how does your organization define and measure success? How do you know if this responsive redesign is working for you?

Kevin:

Well, certainly the feedback that we got from customers told us that we were on the right path. Another big hit for us was there’s a company called DALBAR, they’re a market research firm in the financial industry. About three months after we went responsive, they came out with their next quarter’s review of financial websites. We went from—I don’t think we were even ranked before that, to be honest with you—to number one in retirement plans with an Excellent rating and we’re the only company with an Excellent rating right now. When that came out, that was obviously huge.

They came out with a large document of mobile statistics and in there they used several examples of what Nationwide had done for responsive, to say “This is the correct way to do things.” That was really exciting, to know that we were on the right path. We certainly used that as leverage to say moving forward, you know what, we want to do other websites at Nationwide responsive as well because this is obviously connecting well with everybody.

Our business partners are really excited. We are seeing an increase in sales, we’re getting new plans because of this website. That’s pretty exciting for me to see that we are moving the needle, we’re selling more plans, and we’re getting this website into new hands.

Brian:

One thing that kind of resonated with me, and this is sort of an interesting website, it’s almost business-to-business, as you said before. While obviously the participants of these plans are the ultimate users of this website, we are selling to these municipalities through these entities. One thing I keep hearing—which really just kind of puts a smile on my face every time I hear it—we would go and we’d have to pitch for these new businesses, almost like a new business pitch. Prior to this responsive web redesign, we’d hear from our business partners that our website was always the last thing that we wanted to talk about. Hopefully we didn’t get asked any questions about our website. Being a retirement plan, there’s obviously a lot more to go into it other than just a website. But now that this redesign is done and everyone is so excited about it, this is something that we lead with and we want questions about. So our business partners are really excited. We are seeing an increase in sales, we’re getting new plans because of this website. That’s pretty exciting for me to see that we are moving the needle, we’re selling more plans, and we’re getting this website into new hands.

Karen:

Well congratulations on that to both of you. I think you should be proud of what you’ve accomplished and I think Ethan and I look forward to seeing what else you have in store. Thank you so much for taking the time to be on the show today.

Kevin:

Thank you.

Brian:

Thank you.

Karen:

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

Ethan:

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.

Karen:

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.

Ethan:

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